Almost everyone has a hard time when they first encounter Git, and the problem usually isn’t with understanding the concepts. Most of the time, the struggle has to do with the fact that almost all of the tutorials begin with commands. Before any commands, here is the problem.
What is Version Control?
Without it, “saving your work” on coding projects usually means duplicating folders (project-final, project-final-v2, project-actually-final), which breaks as soon as multiple individuals are participating, as well as breaking the moment you attempt to undo a change three days previously while retaining everything you did since. Git solves this by tracking each separate change you make to a project as a recorded snapshot. Thus, one is free to travel through the history of a project, see what and when the changes occurred, and remove specific changes without changing the other history.
All the rest of the concepts (branches, commits, pull requests) are just extensions meant to make this core idea work smoothly when multiple people attempt to work on the same project.
Essential Git commands for early beginners
Though learning Git in depth is useful, enough commands for early use can be learned in a few minutes. The commands that will be used most are git init, which starts tracking a project, git add, which saves changes, git commit, which saves and logs those changes, and git push, which pushes those changes to a remote repository.
It is important to commit changes frequently in logical, smaller chunks. Committing logically makes the changes easier to be understood later on, while huge commit in one go is difficult to interpret. For example, “Added login form validation” is much easier to understand than “Fixed stuff” and provides much more context.
The more frequently changes are committed, the easier it is to find the exact point at which a bug was introduced.
Branches: working without altering the main version
A branch is like a copy of your project where you can work and make changes without affecting the main project. Branches do, in fact, have a lot more importance. If you are working to implement a new feature and it turns out to be unsuccessful, you can remove the branch and continue working on the main project. The main project will not be affected. You are expected to follow the process of creating a new branch for each new feature and each change, performing all work to implement the feature in the new branch, and then merging the branch to the main branch, usually labeled as main, when the feature is ready.
It is more important to create branches when working with other people since two or more people are able to implement differing features in the project without being affected by one another.
Merge conflicts: the misnomer
At one point, Git will tell you there is a conflict. This is more than likely to be the case when two different people edit the same part of the same file in different ways. This is not because of an error in the system. Git will actually mark the conflicting changes within the file. Resolving this type of conflict is done by choosing one of the changes and keeping that one, or by combining the two, and then committing the result. The first time this is done is the most confusing. After the first time there is little interruption done.
A usable workflow for daily use
For most beginner or small-team projects, just following this basic approach works great the vast majority of the time: make a new branch for what you’re doing, keep doing small, logically-cohesive commits throughout, push the branch, and finally merge it to main once you’ve tested it. You don’t need to know or use tons of advanced Git tools to be productive. All you need is to internalize this workflow. The rest of Git will come naturally as you actually encounter more complex work situations that require you to use them.