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 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.
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.
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
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, you can read more things there.
Top comments (4)
Just don't use Git - all conflicts solved. 😏
sarcasm 101 :)
From my perspective, it is! ;-)
That's wrong, because there is still open source (e.g. mine) in Mercurial, Darcs, Subversion, ... :-)