Git Command List & Usage

Mastering the Git Command Line Interface

Git is the most widely used version control system in the world, powering everything from personal hobby projects to the Linux kernel itself. While there are many graphical interfaces available, understanding the command line interface gives you the deepest level of control and understanding of what Git is actually doing with your code. This comprehensive guide covers not just what each command does, but when and why you would use it in real-world development scenarios.

The commands listed above represent the most commonly used Git operations, organized by their primary purpose. However, Git has over 150 commands in total, and each command typically has dozens of flags and options that modify its behavior. This reference focuses on the patterns you will actually use day-to-day, with the most practical flag combinations.

Understanding Git's Architecture

To truly master Git commands, you need to understand Git's three-tree architecture. The first tree is the Working Directory, which contains your actual files as you see them in your file explorer. The second tree is the Staging Area (also called the Index), which holds a snapshot of changes you want to commit. The third tree is the Repository (the .git directory), which contains your complete history of commits.

Every Git command operates on one or more of these trees. When you run git add, you are moving changes from the Working Directory to the Staging Area. When you run git commit, you are moving changes from the Staging Area to the Repository. When you run git checkout, you are moving changes from the Repository back to the Working Directory. Understanding this flow is the key to never being confused about what Git is doing.

The Daily Workflow Commands

Most developers use only about 10-15 Git commands on a daily basis. The core loop is: git status to see what has changed, git add to stage changes, git commit to save them, and git push to share them. This simple cycle handles 80% of your Git usage.

The git status command is your best friend. Run it constantly. It tells you which branch you are on, which files have been modified, which changes are staged, and whether you are ahead or behind the remote repository. If you are ever confused about the state of your repository, git status is the first command to run.

Commit messages are more important than most developers realize. A good commit message explains not just what you changed, but why you changed it. The conventional format is a short summary line (50 characters or less), followed by a blank line and then a longer explanation if needed. Many teams adopt conventions like Conventional Commits (feat:, fix:, docs:, etc.) to standardize their commit history.

Branching Strategies

Git's branching model is one of its most powerful features. Unlike older version control systems where branches were expensive copies of the entire codebase, Git branches are lightweight pointers to commits. This means you can create hundreds of branches without any performance penalty.

The most common branching strategy is Git Flow, which uses a main branch for production code, a develop branch for integration, and feature branches for individual changes. However, many teams now prefer Trunk-Based Development, where developers work directly on the main branch with short-lived feature branches and feature flags for incomplete features.

When merging branches, you have two options: git merge creates a merge commit that preserves the branch history, while git rebase replays your commits on top of the target branch for a linear history. Both approaches have their advocates. Merging is safer for beginners and preserves the true history, while rebasing creates a cleaner log but requires more care to avoid rewriting shared history.

Undoing Changes

One of the most common Git scenarios is needing to undo something. The appropriate command depends on what you want to undo and how far along the change has progressed. If you have modified a file but not staged it, git checkout -- filename will discard your changes. If you have staged a file but not committed it, git reset HEAD filename will unstage it.

For changes that have already been committed, you have several options. git revert creates a new commit that undoes the changes from a previous commit, which is safe because it does not modify history. git reset can move the branch pointer backward, effectively "uncommitting" changes, but this rewrites history and should only be used on commits that have not been pushed.

The git stash command is invaluable when you need to quickly switch contexts. If you are in the middle of a change but need to work on something else, git stash saves your work-in-progress without committing it. Later, git stash pop brings it back.

Collaboration and Remote Repositories

Git is designed for distributed development, and understanding remote operations is essential for team collaboration. The git remote command manages your connections to remote repositories. Most developers have a single remote called "origin" that points to their primary repository on GitHub, GitLab, or Bitbucket.

The difference between git fetch and git pull confuses many beginners. git fetch downloads new commits from the remote but does not integrate them into your local branch—it is a safe operation that lets you review changes before merging. git pull is essentially git fetch followed by git merge, which immediately integrates the remote changes.

When pushing changes, you may encounter rejection if someone else has pushed commits in the meantime. The safe solution is to pull first, resolve any conflicts, and then push again. Never use git push --force on shared branches, as this overwrites remote history and can cause teammates to lose work.

Advanced Troubleshooting

The git bisect command is an underutilized gem for finding bugs. It performs a binary search through your commit history to find exactly which commit introduced a regression. You mark commits as "good" or "bad" and Git automatically narrows down the culprit with logarithmic efficiency.

git blame shows who last modified each line of a file, which is invaluable for understanding why code was written a certain way. Despite its accusatory name, it is usually used to find the person who can explain a piece of code, not to assign fault.

The git reflog is your safety net. It records every change to the HEAD pointer, even ones that git log does not show. If you accidentally delete a branch or reset too far, git reflog shows the commit hash you need to recover your work.

Best Practices for Teams

Consistent commit hygiene makes collaboration smoother. Keep commits atomic—each commit should represent a single logical change that could be reverted independently. Run tests before pushing. Write clear pull request descriptions that explain the context and approach.

Configure your Git environment for success. Set up a global .gitignore to exclude IDE files and OS-specific files like .DS_Store. Use SSH keys instead of passwords for authentication. Consider signing your commits with GPG for verified authorship.

Finally, invest time in learning Git's configuration options. The git config command lets you customize aliases, default branch names, diff tools, merge strategies, and dozens of other behaviors. A well-configured Git environment can save hours of repetitive typing over the course of a project.