#9 Three Mistakes Not to Make While Merging Code

#9 Three Mistakes Not to Make While Merging Code

<< Previous Edition: Asynchronous Communication: 5 Key Patterns

Once upon a time, I was consulting at a large bank and was kind of leading a small team. Consultants always kind of lead a team rather than really leading. Anyways, Since I apparently understood the application most I thought I would be the best person to merge code changes. Those days were far before GitOps and the atomicity of changes completely depended upon developer discipline. Initially, it was easy to resolve differences and merge changes but the complexity increased with time. Very soon, I was in the hot water and all guns were pointed at me for failing the merges. I forgot the pottery barn rule "If you break it, you own it".

I learned hard way how dangerous merges can be if not executed skillfully. The quickest way to get fired is to be a merge hero. Do not be that guy/gal.

Do not overjudge your ability to resolve code conflicts. It's not a question of your smartness but human ability to handle too many moving parts which also have a tendency to get stuck in each other. Following the following steps and you will achieve merge nirvana.

#1. Merge only your changes.

Charity begins at home so only take care of your own changes.

GitOps has made it far easier to merge changes than ever before. Do the following three things and you never have to worry about being charitable in the wrong place:

  1. Use Git and be the master of your repo universe. This is the best way to isolate your changes. Now a majority of modern application repositories are git-based so most likely this requirement is already met.
  2. Clearly define the task you are working on so that there is the least overlap with others' code.
  3. Help others as much as needed but don't merge their change.

#2. Merge changes proactively.

The best way to avoid merge complexity is to merge proactively.

Follow the following 3 rules to merge changes proactively:

  1. commit changes as early as possible in your local repo.
  2. commit changes as frequently as possible.
  3. Use EaaS software like Roost.ai to collaborate and test changes so that you merge with confidence.

#3. Treat the main repo as a sacred place.

While it is important to proactively commit and resolve changes in the local repository, the rubber meets the road in the main repository. Take the following steps to make sure your main repository is ready for production:

  1. create ephemeral branches for all relevant changes.
  2. Always follow the Pull Request mechanism to manage changes.
  3. Automate pull request merge with advanced tools like roost.ai

>> Next Edition: 2 Mistakes to Avoid While Operationalizing a Pull Request

Dipanshu Mansingka

Engineering Specialist / NITI's AIM/ATL Mentor

1 年

journey from vss, cvs, .. to git. writing assert at the start and end of each method/function to writing unit and integration tests. in code reviews make sure there are no extra space or multiple space instead of tab, it will keep the main repo sacred. for more than 2 decades company had kept the source code in good quality which had wrappers over sdk api calls for both windows and mac. those days when such tools were not available, they would do two level of code review.

回复
Lana Russell

Senior Director Enterprise Accounts ?? ??????????????????????.??????

2 年

Rishi, thanks for sharing!

回复

要查看或添加评论,请登录

Rishi Yadav的更多文章

社区洞察

其他会员也浏览了