The Tao of Git: A Guide to Mastering Git

What is the Tao of Git?

The tao or “the path” of git is a set of guiding principles that will help you understand the complex nature of git and how to use it properly. It’s what separates a git user from a git master. Follow the tao and you will in time achieve great things, through your knowledge of git.

What is Git ?

Git is a version control system, much like time is ever flowing, your code is ever changing. Git is a tool that allows you to keep track of all the changes that were and all the changes that shall be. Understanding git is understanding the nature of time and the nature of change. Git is the path to enlightenment.

You can not change the past, unless you use git. Then you totally can

• Dayvi Schuster

Of Paths and Branches

Much like in terminator there are multiple timelines happening at the same time with multiple different versions of the same events. In git there are multiple branches keeping track of different versions of the same code. This is what allows a student of git to work on multiple features at the same time without them polluting each other. You will only have to manually merge the changes when the same file is changed in both branches. Do not try to merge branches that have nothing to do with each other, this will only lead to pain and suffering.

In this most students of git agreed upon a holy trinity of branches, the main branch, the develop branch and the staging branch. There’s also the hotfix and feature branches but we’ll get to those later.

The Main Branch

The main branch is the branch that must always stay stable, no work shall be done on the main branch, the only changes permitted in the main branch should happen via a pull request from staging to main. The main branch will be automatically deployed to production for all to see and marvel at. The main branch is the most sacred of all branches, it is the branch that must never be broken.

The Staging Branch

The staging branch is the branch which will be available as a staging ground for future changes/features this branch should always strive to be stable, but it’s okay if it’s not. The features which developers merge from dev to staging should be tested by the QA team before they are merged to main. The staging branch is the branch that will be deployed to a staging environment for testing. Only upon approval of the QA team will a pull request be permitted to pass from staging to main.

Do not skip this step, for it is the most important step in the process. If you skip this step you will be cursed with a thousand years of bad luck. And also it’ll be a serious pain to fix later. Like weekend work and stuff. You don’t want that.

The Develop Branch

The chaotic branch or the branch of change also called the dev or development NEVER develop branch, seriously who calls it the develop branch, either abbreviate it fully to dev or don’t. Anyhow upon this branch all development work shall be done and merged into. This branch should be decorated with as many unit tests, integration tests and e2e tests as possible. The dev branch is the branch that will be deployed to a development environment for testing. If the automated tests pass then the spirits have given you permission to merge to staging. But also like tag your team lead or co-worker in your pull-request so they can review it. The spirits can’t do all the work.

The Hotfix and Feature Branches

These are the branches that developers shall create upon recieving a task or bug report from their product owner or team lead. Upon recieving your sacred task you shall create a branch with the name of the task or bug report. This branch shall be created from the dev branch. Upon completion of the task or bug fix you shall merge your branch into dev and then staging and then main. If you are a good student of git you will also delete your branch after merging it into main. If you are a bad student of git you will leave your branch hanging around for all eternity. This of course will anger the spirits and your team lead or co-worker will have to delete it for you, which may really annoy them. So don’t do that.

Of Commits and Commit Messages

Every developer must in time commit and they must do so often, upon committing they are tasked with providing a commit message. The commit message is the most important part of the commit, it is the message that the developer wishes to convey with their work, it is a short sentance that explains their hours, days or at times weeks of hard labour and effort. The commit message should be written in the imperative mood, it should be short and to the point. It should be written in the present tense and it should be written in the active voice. The commit message should be written in the following format:

<type>(<scope>): <subject>

The type of the commit should be one of the following: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert. The scope of the commit should be the name of the file or folder that was changed. The subject of the commit should be a short description of the changes made.

For example:

feat(data/posts): add new post about the tao of git

If the labour of the developer spanned multiple suns and moons then they should provide a longer description of their work in the body of the commit message. to do so they should invoke the following command git commit -m "feat(data/posts): short description" -m "long description". The long description should be written well and understandable by fellow developers. This is an act of kindness and will be greately appreciated by your fellow developers, especially your team lead or whoever is responsible for documentation.

Of Merges and Merge Conflicts

Merges are the most sacred of all git rituals, they are the most important part of the git tao. Merges are the way in which developers can apply the changes they have done to the codebase in one branch to another branch. Through this ritual the developer can apply the changes they have made to the dev branch to the staging branch and then to the main branch. But sometimes the fates are not kind and merge conflicts may arise. Upon spotting a merge conflict the developer himself or herself is responsible for resolving the merge conflict of their Pull Request, only upon resolution of the merge conflict will the pull request be allowed to pass.

Of Pull Requests and Reviews

When a developer is confident that their labour/task has been acomplished they may request a pull of their work into another branch or a pull request. Upon creating a pull request the developer must request a review from their team lead or co-worker. The team lead or co-worker is responsible for reviewing the pull request and ensuring that the developer has done their work properly. If the team lead or co-worker is not satisfied with the work of the developer they may request changes to the pull request. The developer is responsible for applying the requested changes to the pull request. Only upon approval of the team lead or co-worker will the pull request be allowed to pass.

Be careful when doing a code-review, to do a good code-review one must separate themselves from their ego. Remember it’s not about you there is only the code. You or your company may have certain rules or guidelines in place for deciding what consistutes as clean, readable and maintainable code. Make sure that you judge only the code and not the developer who submitted the code. They are not up for judgement, a code review is a place of learning and growth. If you find yourself judging the developer then you are doing it wrong.

Make sure you allow the reviewee to explain their thought process and reserve judgement, sometimes even a master can learn from a student. Their thought process or how they tackle a problem may surprise you and give you a new perspective. If you fundamentally disagree and know that their code could be improved then explain it in a kind and informative manner and provide a suggestion for improvement, together you may find a solution that is better than either of you could have come up with on your own. This is the way of the code-review.

Of Lesser Known Commands

Much like a painter does not know all the colours in the world, a developer does not know all the commands in git. I will not claim I can teach you all of them for that would be impossible. But I can teach you some of them. Here’s a list of some lesser known commands that you may find useful as I do:

Worktree

git worktree add <path> <branch>

A worktree is a way to have multiple branches checked out at the same time. This is useful if you want to work on multiple branches at the same time. For example if you want to work on a feature branch and a bugfix branch at the same time. You can do so by creating a worktree for each branch.

Cherry Pick

git cherry-pick <commit>

Much like you would pick only the best looking cherries from a tree of cherries, you may cherry pick a single commit from another branch and apply it to your current branch.

NOTE This will create a new commit with the same commit message as the cherry picked commit. If you want to change the commit message you can do so by using the --no-commit flag and then using the git commit --amend command.

Git Stash

git stash

Sometimes a student of git may get distracted or sidetracked but does not wish to use a worktree, in this case they may use the git stash command. This command will save your current work and allow you to switch between branches without losing your work. You can then apply your work to another branch by using the git stash apply command.

Git diff and Git diff —staged

git diff

git diff --staged

These commands are useful for seeing the changes you have made to your codebase. The git diff command will show you the changes you have made to your codebase that have not been staged. The git diff --staged command will show you the changes you have made to your codebase that have been staged.

Git blame

git blame <file>

Sometimes as a developer you may not recognize a piece of code as your own, this is okay do not be alarmed, you have git blame at your disposal. Invoke this command and it will tell you where the line of code in front of you came from and who created it. This is useful for when you are trying to figure out why a piece of code is the way it is. Or when you’re really lost and need guidance from the author of the code.

Git log

git log

Invoke this command if you wish to have the history of your current branch presented to you, upon invoking this command a list of commits will be presented to you from those that came before to those that came after. Basically look you get a list of commits, what more do you want from me?

Conclusion

I hope you have enjoyed this journey into the tao of git. I hope you have learned something new and that you will be able to apply it to your own work. I hope you will be able to use this knowledge to become a better developer and a better person.