Git is the standard tool for tracking changes in code and collaborating across teams. Mastering a handful of basic commands will boost your confidence and keep your projects organized.
This guide walks through the core commands you can use every day, backed by a quick reference table and practical guidance for common workflows.
| Command | Purpose | Typical Use Case | Example |
|---|---|---|---|
| git init | Create a new local repository | Starting a project or converting an existing folder | git init |
| git clone | Copy an existing remote repository | Joining a team project or forking an open source repo | git clone https://github.com/user/repo.git |
| git status | Show current branch and changed files | Quick check before committing or pushing | git status |
| git add | Stage changes for commit | Selecting specific files or patterns | git add file.py |
| git commit | Save staged changes with a message | Capturing a logical unit of work | git commit -m "Add login form" |
| git log | View commit history | Understanding recent changes and debugging | git log --oneline |
| git branch | List and manage branches | Organizing features and fixes | git branch -a |
| git checkout | Switch branches or restore files | Moving between work contexts | git checkout feature-x |
| git pull | Fetch and merge changes from remote | Staying up to date with team work | git pull origin main |
| git push | Upload commits to remote | Sharing your work with others | git push origin main |
Getting Started with Git Commands
The first commands you learn shape how you interact with repositories. git init and git clone define where your code lives locally, while git status and git add prepare changes for recording. Practicing these early makes later workflows smoother.
Managing Local Repositories
Local repositories are the foundation of your daily work. You create them, open them, and query their state before making any public changes.
Initialize and verify
Use git init in an empty project folder to start version control. Run git status immediately after to confirm the repository is active and see which files are untracked.
Working with Remote Repositories
Most teams share code on platforms such as GitHub, GitLab, or Bitbucket. Cloning brings a remote repository to your machine, while pull and push keep your local and remote branches in sync.
Clone and collaborate
git clone creates a working copy you can edit. After you commit locally, git push sends your changes upstream, and git pull integrates updates from teammates.
Branching and Commit Practices
Branches let you experiment and ship features independently. Clear commits document why changes were made, making history easier to follow.
Branches and history
git branch shows all local and remote branches, while git checkout switches context. Commit often with descriptive messages so git log provides a readable trail of progress.
Core Workflow and Collaboration
Consistent habits reduce merge conflicts and make collaboration predictable. Review, branch, commit, and push with clear intent to keep the project healthy.
- Initialize or clone a repository before making changes
- Check status and diff frequently to understand context
- Stage changes deliberately with git add
- Write descriptive commit messages for traceability
- Use branches for features and fixes
- Pull often to stay in sync with the team
- Push completed work for code review and backup
- Coordinate force pushes and rebases with your team
FAQ
Reader questions
How do I undo an accidental commit before pushing?
Use git reset --soft HEAD~1 to move HEAD back one commit while keeping changes staged, or git reset HEAD~1 to unstage and keep changes in your working directory.
What should I do if git status shows modified files I did not intend to change?
Run git diff to review changes, then use git checkout -- to discard unwanted modifications in the working directory.
How can I see what changed between two commits?
Use git log to find the commit hashes, then run git diff to view the exact line-level differences.
Is it safe to force push after rewriting history with git rebase?
Only force push when you are certain no one else is working from the same branch, as it rewrites history and can overwrite commits on collaborators.