3 simple rules for less or no git conflicts
Tags: git, coding, opensource, tips
Published: 2018-10-13 11:26:46

---
title: "3 simple rules for less or no git conflicts"
published: true
description: "Do you write at least 10 lines of code a day in any programming language? Do you work in a team? If your answer is yes to both questions, you need to learn git."
tags: 
- git
- coding
- opensource
- tips
---

Do you write at least 10 lines of code a day in any programming language? Do you work in a team? If your answer is yes to both questions, you need to learn `git` even if you work alone in a project.
[Git](https://git-scm.com/) is the most popular versions control system and it has become a must-have software engineer skill.

I have seen teams fall into this trap of git conflicts when they start using git and some type of
[gitflow](http://geshan.com.np/blog/2014/12/do-you-git-your-code-follow-this-simplified-gitflow-model/).
Merging branches to the main branch becomes a pain when there are git conflicts.
In this post, I am going to reveal 3 simple rules to avoid git conflicts.

![3 simple rules for less or no git conflicts](https://geshan.com.np/images/3-rules-git-conflict/git-conflict.png "3 simple rules for less or no git conflicts")

<!-- more -->

## Assumption

You have some working knowledge of git. You follow a git branching model like gitflow or simplified gitflow.

## Rule 1: Keep your changes small

This is the golden rule to avoid git conflicts in teams. Conflicts occur when 2 team members make changes
around the same line of code. Like John changes like 5-10 in readme.md. Jack changes like 7-15 in the same
readme.md file on a different branch. Have a rule of thumb that each pull request can have at most 20 files
changed with 200 line addition. If changes are less there are fewer chances of having things overlapped. As a
side effect, it will make deploying and testing changes easy too.

## Rule 2: Rebase with your main branch (generally master) when it changes

When your main branch changes, rebase the branch you are working on with it. Usually `master` is the
main branch so it will be best if you rebase with master at least once a day. This saves you from bringing
in lots of changes done by other team members late. Its the same concept as above, get small changes, step by
step many times than getting it all at once. At the end of the day always do the following, given
you are on your working branch

```
git checkout master
git fetch
git pull --rebase origin master
git checkout -
git rebase master
```
You get the latest master. Then you go back to your previous branch and rebase your branch with the latest master.

## Rule 3: Review pull requests faster and merge them to the main branch

As I have stated earlier "An open pull request (PR) is a liability in at least 2 ways. 1 it’s a feature/fix not
shipped to customers. 2 it will invite code conflicts soon." Have a rule, pull requests need action by 3 days of
opening them. You can review code, if the code is ok deploy and merge or review code, fix issues then deploy and merge.
This will help the team ship things faster as well as not have pull requests open unattended for weeks.

### Useful Tip

You followed the above rules, still landed in a git conflict situation? Use `git cherry-pick`. If you have more
than one commit in your working branch first [squash](http://geshan.com.np/blog/2014/07/4-git-tips-beyond-basics/)
it to one commit. Then create a new branch out of master/your main branch and do `git cherry-pick <sha-of-your-squashed-commit>`.  
Given you have only 1 commit on your working branch `feature11` and you are on `feature11` right now, do the following:

```
git checkout master; git fetch && git pull --rebase origin master
git checkout -b feature-11-new
git cherry-pick 249bd9b150fdb1e6fc9e58af9823f70cc52579a3
```
In the above example `249bd9b150fdb1e6fc9e58af9823f70cc52579a3` is used for demo only. You can know your SHA hash with `git log -1`
being on branch `feature11`

## Conclusion

There is no silver bullet to avoid git conflicts all the time. You will face it now and then.
If you run into git conflicts every day the process and system need to change.
Be logical, if you have a PR with 50 files changed and 700 new lines you will face conflicts.

> I hope you encounter fewer git conflicts or even completely avoid them.

---
Originally published at [Geshan.com.np](https://geshan.com.np), you can read more things there.