Version Control with Git

How to use Git branches for collaboration

This is a guide for learning how to use Git in a responsible way with multiple users. It will show how having different branches can help to simplify merge conflicts.

Lim Xing Zhi

Apr 6, 2020 — 3 min read

This post will not cover the basics of Git or version control. Instead, it will serve as a guide for learning how to use Git in a responsible way with multiple users. It will show how having different branches can help to simplify merge conflicts.

Preface

This post will assume that everyone is collaborating from the dev branch as per common practice.

Before merging/rebasing back into the dev every developer is expected to pull and fix any merge conflict before pushing her code to dev. This is general coding ethics and in-line with good practices.

With these in mind, every commit in dev will always be working. The build on dev should not fail under normal circumstances.

Now, let us start.

Personal Branch

Each developer should work on their personal branch. Only merging or rebasing with a centralized shared branch whenever a feature is completed. Although this concept is widely used, there doesn't seem to be an official term for it. Thus, thou shalt name it the "Single Responsible Branch Principle". This principle mirrors the Single Responsibility Principle [1] in software engineering. This principle can come in multiple forms:

Feature Branch is a strategy where every task will be assigned an ID. Then, the developer will branch out from dev, naming the new branch with the task ID. Merging or rebasing back to dev only after completing the task. This accomplishes the following:

Each branch will only be worked by one developer, limiting the merge conflicts to only the dev branch
There will not be developers who are working on repeated tasks (ok, this is not really a git issue but it helps)
Before merging/rebasing, each feature branch can be squashed into a single commit, thus making the history of dev branch cleaner. Since the dev branch will only have commits that are whole features.

Alternatively, we do not have to branch out every time we work on a new feature. Each developer can have their own branch and should only work on a task at a time. Only when their task is completed, then they merge/rebase with the dev branch. The idea is similar with feature branches, except we do not branch out every time we work on a new task. We just pull from dev before we start and push to dev after we are done.

By the way, these Git use cases are not made up by me. Developers have been using it for nearly a decade[2][3].

Image for single responsibility branch principle — Single Responsible Branch Principle in action

Responsible Commits

Regardless of what features individual developers are working on, each commit on dev must be working and functional. This ensures every developer who branches out from dev will have functioning code to work with.

What happens if I have unstaged changes, but I still want to push my current commit?

There exist a feature in git called stashing. Stashing allows you to temporary save your uncommitted changes and hide them away. This way, you can run your build, run tests (if any), and fix for errors before pushing your local commits. When you are done, you can pop the stash back and resume working. It takes less than 30 seconds to do all these and it checks for any errors. Catching errors on your own is more productive and professional than letting your teammates/colleagues encounter the error before asking you change.

Basically, before you push to the git server, do this:

Stash your local uncommitted changes
Build your program / run any local tests
fix any problems that surfaced + amend your local commit
Push your local commit to the server
Pop your local changes and continue working

TL;DR

Each task should begin with a commit from the collaboration branch and end with a merge/rebase into the collaboration branch
Always work on your own branch and merge/rebase back to the collaboration branch after completing a task
The collaboration branch should always have working code