2

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?

  • 2
    "There is an opinion [...]" And whose opinion is that? Why do you think it is bad? – Vincent Savard Mar 22 '17 at 13:13
  • 1
    Have you asked them why that's their opinion? Or if/why they think it's good? – jonrsharpe Mar 22 '17 at 13:33
  • Hi @VincentSavard and jonrsharpe, thank you both for your comments. It is some developers opinion that merging dev into your branch is a bad practise. I personally don't think is a bad practise, if you merge your branch to dev after you have concluded your story but I wanted to ask a trusted community to get more opinions on the matter. The reason why some devs don't want to merge dev branch with a "user-story" branch, is because it will look like a "circle" in the representation of merges on bitbucket and that once you merge dev in your branch, your branch then becomes the source of truth. – Antigoni Mar 22 '17 at 15:02
6

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.

  • Hi enderland, thank you very much for your answer. The reason why some devs don't want to merge the dev branch with a "user-story" branch, is because it will look like a "circle" in the representation of merges on bitbucket and also that once you merge dev into your branch, your branch becomes then the source of truth. I have kindly disagreed with both. – Antigoni Mar 22 '17 at 14:51
  • 1
    @Antigoni then tell them to rebase their changes prior to merging or making a pull request? – enderland Mar 22 '17 at 15:25
  • Or create a new branch and squash the commits from your topic branch just for the purposes of a pull request. It's a little kludgey, but it does make for a clean history. Or, when merging into dev, squash the commits there. – Greg Burghardt Mar 22 '17 at 15:46
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.

0

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).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.