Git Methodologies, managing your git process (Branch vs Commit)

Git can be your best friend or your worst enemy at times. Navigating through the treacherous waters can be sometimes nerve racking for even long time users at times.

Not all git processes are the same. With using git more than 10 years now, I have seen several different processes within companies. Our of these, main practices I have noted are these:

• Git Branch Methodology
• Git Commit Methodology

I will break down each of these with pros and cons and show you the series of git commands that works best for each. To make it easier to understand, I will use a book analogy, with chapters being the branches and commits being the pages.

Git Branch Methodology

Using branches I have found to be the most common practice. It usually conisists of these commands.

• To start: git clone {repo}
• You’re currently on master
• Creating your branch git branch -b '{Branch-Name}'
• Then you edit your code and make your changes you would like
• Next, lets add them locally git add -A
• Then lets add a commit with message git commit -m '{message}'
• Then ideally, we would just push our branch, but before that, we should check to make sure we’re up-to-date with master to avoid any potential conflicts. In a branch methodology, we will run git pull origin master.
• If there is a conflict, we can address them in the code, many editors will show you.
• Then lastly, we can push our branch up using git push origin '{Branch-Name}' and then make a pull request using the UI from git administration (Github/BitBucket).

Pros:

• Creates easy marker points for when a branch was merged, and rollback becomes easier as it’s more like chapters of a book.
• The flow is a lot easier to manage through git commands, requires less commands.

Cons

• Conflicts can be large, if branch work is a lot, say even a version different than currently on repo.

Git Commit Methodology

This methodology is more grainular and think of it as pages in a book, your branches contain commits, but when using this methodology, we will align all commits onto master, essentially creating one long stream of commits and commit history vs creating a branch merge history.

Let’s start with the process:

• To start: git clone {repo}
• You’re currently on master
• Creating your branch git branch -b '{Branch-Name}'
• Then you edit your code and make your changes you would like
• Next, lets add them locally git add -A
• Then lets add a commit with message git commit -m '{message}'
• — Up to this point, it’s been relatively the same as “Branch Methodology”, but now we need to run git fetch, this will pull down all remote branches from the git repo.
• Once we have run git fetch, we need to rebase our commit chain onto master by running git rebase origin/master. In the book analogy, this would be like placing all of the pages in a book, one by one in order from the last page that was on master. Giving no chapter markers, but one steady stream of commits (book pages).
• The tedious and more difficult part arises here, when we face conflicts, it’s not a go fix all and then push back up, it’s a go commit by commit and fix the conflicts that each commit might have presented. Definitely makes you rethink when you want to create a commit, where as a commit might have been just a typo in the Branch methodology, that type fix commit, now might give you 20 mins of conflicts to fix for that page to fit correctly in the book. if you have conflicts, git will let you know much like it does with branches, except you will enter a “Rebase session”. Your conflicted files will be listed, and once they’re fixed.
• You run git add {file name}.
• Then you run git rebase --continue
• Then once you have done this for all commits with conflicts (each page in our book). You will need to push your branch up, git push origin '{branch name}' if you have previously pushed your branch, it will be important you add the --force. (ex: git push origin '{branch name}' --force If you have to do a force push, you will see some message like this.

Pros

• You have one stream of commits, and you can identify when code was changed at a granular level (page).

Cons

• No clear merge or change points to extra an entire branch.
• No clear rollback points based on branches
• Much more work to handle conflicts.
• Changes for conflicts is higher since it’s at page level (book analogy)
• Conflicts might have to be fixed more than once as you go through your rebase session.
• Git conflicts sometimes are not accurate in rebase session.

Summary

In summary, I have found both methodologies to be common practices at multiple tech companies. They offer pros and cons, I tend to lean more towards the “Branch Methodology”. I prefer the chapters, even if it’s harder at times to identify when a commit happened. I rather have conflicts easier to handle. One thing that can help with git conflicts when using “Commit Methodology” is to squash your commits.

Overall, I hope this has helped you understand some common practices with git, and that there is not one absolute way to manage your git process.