Common Git Confusions

Last modified: December 27, 2017

This article is written in: 🇺🇸

Git is a powerful tool, but its complexity often puzzles newcomers. Let’s break down some typical areas where users get tripped up in simpler terms:

When you hear the term commit, think of it as capturing a snapshot of your work at a particular moment in time. Each commit records the changes you've made and includes a message that describes what you did, providing a history of your project's development. This allows you to revisit previous versions of your project if needed.
A branch is best understood as an independent line of development, similar to a parallel universe for your project. In this isolated environment, you can experiment and make changes without impacting the main line of development, which is typically referred to as 'master' or 'main'. This way, you can work on new features or fix bugs separately from the stable version of your project.
The process of merging involves combining changes from different branches into one unified version. Think of it like blending ideas from various team members into a single, coherent plan. Merging ensures that all the different contributions and improvements are integrated into the main project, allowing for collaborative development.
A pull request is a feature used to notify your team members about the changes you've pushed to a repository on GitHub. It's similar to requesting feedback or approval to merge your changes into the main branch. When you create a pull request, you provide a description of your changes and why they should be included, facilitating code review and discussion before the integration.

The term merge conflicts refers to a situation where two branches contain conflicting changes, and Git is unable to automatically combine them. This requires manual intervention to resolve the conflicts, much like you would reconcile differences in a document that multiple people have edited. For instance, if two team members modify the same line of code in different ways, Git will flag this as a conflict, and you will need to decide which change to keep or how to integrate both changes effectively.
Following best practices can significantly reduce the occurrence of merge conflicts and streamline the development process. One such practice is to regularly pull changes from the main branch into your feature branch. This ensures that your branch is up to date with the latest changes and minimizes the differences that need to be resolved later. Additionally, committing smaller, logical changes rather than large, sweeping updates can make it easier to track and manage modifications. These incremental commits provide clearer context and make it simpler to pinpoint and resolve issues, ultimately leading to a smoother merging process.

The learning curve for Git can be steep, especially because it relies heavily on command-line instructions. For users who are more familiar with graphical interfaces, this can initially seem daunting. However, investing time in learning these commands can be highly beneficial. Mastering the command line provides powerful control and flexibility over your Git operations, enabling you to perform tasks more efficiently and automate repetitive actions.
While mastering the command line is advantageous, there are also numerous graphical tools available for Git. These GUI tools offer a more visual and intuitive way to handle Git operations, making it easier for those who prefer not to use the command line. Tools like GitHub Desktop, Sourcetree, and GitKraken provide user-friendly interfaces that simplify tasks such as committing changes, branching, and merging, thereby catering to a wider range of users with different preferences and skill levels.

The revert command is a safe and non-destructive way to undo changes made by a previous commit. When you revert a commit, Git creates a new commit that negates the changes introduced by the specified commit. This means the project history remains intact, preserving the record of all changes while effectively undoing the specific modifications. This method is particularly useful in a shared repository where preserving the history is crucial.
In contrast, the reset command is more powerful and potentially destructive, as it can alter the project history. Using reset, you can move the current branch back to a previous state, effectively discarding any commits made after that point. This can be useful for undoing mistakes, but it should be used with caution, especially in a shared repository, as it can remove changes that other collaborators might rely on. There are different types of resets, such as soft, mixed, and hard, each offering varying levels of impact on your working directory and staging area.

When using Git, it’s crucial to exercise caution with commands like git reset --hard and git push --force as they can irreversibly change your project's history. Understanding their consequences is essential to avoid unintended data loss or complications.
The command git reset --hard will reset your current branch to a specific commit, and it will also change the index and working directory to match that commit. This means that any uncommitted changes in the working directory or the index will be lost. While this can be useful for discarding all local changes, it should be used with extreme caution because it can result in the loss of valuable work.
Another powerful command, git push --force, can overwrite changes in a remote repository. This command forcefully updates the remote branch to match your local branch, discarding any changes that others might have pushed in the meantime. While it can be helpful in certain situations, such as correcting mistakes in the commit history, it can also cause significant issues for team members who are working on the same branch. Therefore, it's important to use this command sparingly and ensure that all team members are aware of the changes being made.

To understand the detached HEAD state, imagine that when you check out a commit instead of a branch, you enter a temporary situation where changes you make are not attached to any branch. This means any new commits you create will not be associated with a branch and can be lost if you switch to another branch.
To resolve the detached HEAD state, you can create a new branch from the current state. This way, you preserve your changes and commit history. After creating this new branch, you can switch back to a main development branch, ensuring that your work is not lost and remains part of the project's history.