Hey all. Been away for a while. So, I wanted to get something off my head that's been an itch at my current workplace. So, I've finally moved away from a startup environment into a bigger organization to finally get some much needed work-life balance. So, at startups I had full autonomy as long as the job was done. However, this is not the same in bigger organizations. The time taken on completing processes are simply too tiring. One of the processes that I have wasted most of my time in is their merge strategy.

The current merge strategy:

At the moment, the entire org uses rebase as the merge strategy. While rebase is great to keep your git graph clean, it becomes a nightmare when working with multiple teams. Especially when these teams are based out of different locations.

Let me explain why this becomes an issue when working with remote teams. When we rebase our PR with the main branch of a repo, we are rewriting the history of the repo. During the process of a rebase, all the commits that you made to your feature/bugfix branch are put on top of the head of the main branch you are rebasing to. That sounds pretty simple right? How is that even rewriting the history?

Well, when your commits are put on top of the head of the main branch, you are pretty much altering the history of the repo. It isn't normal for all your changes to be committed in a sequential order. Especially, when you are working in a team. There will always be others who would be working parallelly to you and would also have made several commits of their own.

When you do a rebase, the actual order of these commits are messed up and this is kind of not great to know the entire chronology of events that happened. While this might not be that big of an issue and I can pretty much live with it. However, what makes rebase a real kicker for larger teams is the conflicts that it creates amongst developers.

You might be thinking that conflicts are something that we would all need to resolve while working on projects with others involved. Yes! We all would have had to deal with conflicts. That's also the reason why most of us developers would love to have our PR merged at the earliest(So, that we don't have to deal with conflicts). However, conflicts with rebase are a completely different ball game.

For the sake of simplicity, let's just assume that we have a main branch and we have 3 developers out of which 2 working on 2 different features at the same time and the third developer is taking care of bugfixes at the same time. The typical way to do things in this case would that all of us would take the latest pull from the main branch and then branch out to our respective feature/bugfix branch and once we are done with development, we would raise a pull request to get our branches merged with the main branch.

As of now, all of us have branched out from the same head of the main branch. Since 2 of the developers are working on features, they would take a longer time to make their commits and the developer working on bug fixes would be able to raise PRs and get them merged at a quicker rate. Once the dev working on bugfixes gets a few of his PR merged with the rebase strategy, the head of the main branch would now be moved to the latest commit that they made.

This is a problem for both the other developers for who the head of the main branch still points to the previous commit. Now they would also need to do a rebase to be updated with the latest main branch. When they do this, if there was some change in the same file between one of the two devs and the dev who fixed the bugs, then there would be a conflict that would need to be resolved manually. This is why, in my current org, everyone is expected to rebase on a daily basis and resolve the conflicts.

Now lets say that both the devs resolved conflicts in one of their commits, and both these conflicts were from the same file, now the dev who would get his PR merged first would be okay whereas the one who raised his PR last, would need to rebase once again and resolve the conflicts in his commits and only then will the branch be ready to get merged.

This might sound like not that big of a deal. However, when the team consists of 50+ developers in different timezones, the number of times you would need to rebase and resolve conflicts manually go up drastically. In my case, I ended up resolving conflicts for a week because every time I resolved conflicts, the PR approvals would get revoked and by the time I could get it approved again, I would have had to dealt with another round of conflict resolution.

What gets to my nerves is that all this could have been avoided with a merge strategy instead of a rebase.

How exactly does the merge strategy save the day?

Well, it's not like with git merge, you won't get conflicts. However, with git merge, you don't have to deal with conflicts that can be auto resolved by git. That is unless the conflict in on the same line of code, you normally would not even see it appear as a conflict. Additionally, with git merge, you can choose to resolve all conflicts right before you want to get your PR merged. However, with rebase, it gets very confusing as the conflicts show up against each and every one of your commits. So, the odds of you making a mistake in this case are much higher.

This is something everyone on my team has faced. However, none of them seem to have raised an issue for it. So, how do they resolve it then? They resolve such rebase conflicts in the worst way possible! They copy their changes onto a fresh branch that they got from the latest main branch. Yes! you heard me right! even with SVC in place, we use the ancient copy paste way to resolve complex conflicts.

Me being me, raised this as a major concern in our team. So, I was made to go talk to one of the managers of the build team which is the team that pretty much sets the merge strategies across the entire org.

The Meeting:

To be honest, I thought that the merge strategies were set by the managers or one of the seniors on the team. However, when I got to know that this was set by an external team, I thought to myself that the problem here is that these strategies are set by someone who barely uses it or uses git with just a few peers.

In this meeting, the person who I spoke to asked me what the problem was with git for which I asked why we were using rebase as a merge strategy when merge does a much better job. To this question, his response was "Rebase is the best merge strategy out there". This single statement made by this person infuriated me. I had gone into this meeting thinking that it would have a good outcome and I would get to know if I am doing something wrong or is it how this is. However, this single statement made me realize that the person I am having the meeting with has not used GIT in his lifetime or has used one of the older SVC life TFS or something.

I was also pretty sure that someone just told rebase is the best and everyone just followed without anyone questioning it. To his statement, I asked him why he thinks rebase is the best. For which he showed me the single line graph that rebase creates. He further added that this helps in audits.

This is completely wrong! You are altering git history with rebase. If anything, this helps in creating incorrect audits that don't tell the truth about when a bug was even introduced.

After I told this person the current issues that we are facing with rebase, he asked me to squash all commits into a single commit and merge to avoid the complex rebase conflicts. However, he did not say squash the commits. He asked me to push entire feature as a single commit. Who on earth does that. Let's say I want to revert one small change in my PR, my options are to revert my whole PR or manually undo a particular change. This is simply ridiculous!

I realized that this meeting was going to be pretty much useless and decided to agree to everything and save my time. The issue here is I am a new developer for the org and I've been around for 2 months. The folks calling shots at such crucial processes are the ones who are there for 10+ years.

The Battle Continues:

There is no point for me to continue arguing with these so called "experienced" folks who get offended whenever someone suggests something better. Like, I've been asked not to refactor any existing code even if it helps in performance or makes the code more readable. I was asked to edit the dependencies inside package.json which was laughable. It's clear to me that they just want to assert certain dominance especially when someone can make their existing code better. The battle for the merge strategy is going to be a long one. I know it is no where close to the battle between EMACS and VIMs but it is a battle none the less. For now I have assumed defeat and moved on. However, I will build up my rapport to the point where I can at least influence some of these calls in the future. Let me know if you guys have also faced similar issues and how you went about it at your workplace.