Should I merge the dev branch into my user story branch?

Question

We have a relatively simple version control process: master branch, dev (otherwise known as integration) branch, and our individual branches for every user story.

We check out from dev, branch at the beginning of a new user story to a new branch and once we finish, we merge again to the dev branch.

There is the opinion that while developing a story on a new branch, we should not pull down latest changes from dev branch and then merge those changes into the branch for the user story.

Why is that bad? If once you pull down latest changes from dev into your branch, you then merge your branch back to dev once you are completely finished with your story?

Answer 1

we should not pull down latest changes from dev branch and then merge those changes into the branch for the user story

This is likely the result of one of three situations:

• "Lazy" developers who don't want to reconcile potential merge conflicts more than once
• Developers who don't understand how to do git merges
• A codebase that is so poorly modularized that no one can work without touching code that others are actively working on

For the first, which seems likely, it's a matter of laziness. If you have an active dev branch you will have to pull multiple times on a feature and potentially multiple times per day. The solution is recognizing that resolving small merge conflicts frequently is much easier than a massive merge at the end.

If the developers are afraid of git merges, for whatever reason, it might be they just do something horribly hacky. Full disclosure: my first experiences with git I had no idea what I was doing (now I do) and for merges, I normally did a "manual" merge without even resolving the merge diffs. If your team is similarly naive about how git works, they might be doing this out of desperation.

And last, if your codebase is the root cause, you might be out of luck. In this sort of situation it is hard to keep your local updated because you are constantly getting breaking changes to your code. Refactoring may be the only way.

Ultimately though, figure out why your devs want to do that. It will make your easier life generally speaking to make a practice of doing this.

Answer 2

My rule is that you don't merge any branch into the dev branch if there are any merge conflicts. The logical consequence is that you need to merge the dev branch into your feature branch before you merge the feature branch into dev.

From a practical point of view: Whether you merge dev into branch or branch into dev, the result will be exactly the same. If you merge dev into branch first, then merging branch into dev will be trivial, so this is zero extra effort. But what if something goes wrong? The merge may be conflict free but cause problems. Much better if this happens only in your branch and doesn't affect everyone. Or there are conflicts. Better you resolve the conflicts, and then solve any problems that may have been caused, then everyone having to deal with this.

So the result of merging dev into branch first is that you can be sure (if you use all due care) that merging into dev will go smoothly and with a good result.

Answer 3

Putting the history angle aside (especially since our team doesn't use Bitbucket, so I cannot speak to that point), there may be a QA/Testing angle to consider.

In our company, under normal circumstances, QA does their initial testing of the feature in the feature branch, before it is merged back to develop. They perform the "everything plays nicely in the sandbox together" validation via some automated regression and RC regression. We thought this was the best approach, to enable them to test in isolation. If other devs have checked in code to develop and impacts the behavior of your code and is merged to your feature branch, it may impact this 'isolation'.

It's not perfect and probably says something about our organization/breakdown/planning of user stories or features, but I digress :)

That being said, if we notice there are merge conflicts in the pull request between our feature branch and the source branch before we give it to QA, we will go ahead and resolve those conflicts (by merging the source branch into the feature branch), to avoid having QA test the work multiple times (in those particularly nasty conflict scenarios).