3

There are two branches master and feature.

The development goes in feature branch and there multiple commits done in that branch, but in between them there were several merges with master branch, so the log for feature branch is for example something like:

  • feature commit 1

  • master commit 1

  • feature commit 2

  • master commit 2

  • feature commit 3

Is it safe to squash all these commits into one feature commit 1 ?

Are there any problems that I could come across when merging feature branch into master ?

SherylHohman
  • 16,580
  • 17
  • 88
  • 94
marknorkin
  • 3,904
  • 10
  • 46
  • 82

3 Answers3

1

Is it safe to squash all these commits into one feature commit 1 ?

No, it's not safe to do so

Are there any problems that I could come across when merging feature branch into master ?

As I understand the problem, in that case you are changing the master branch history and basically breaking it for everyone.

When you squash your feature branch for the commits starting from your first one to your last one, you will also squash all master commits, in addition to your two feature commits - even master commits that changed files you did not touch.

So your squashed commit will have a lot of changed files that you didn't change at all. When merging back to master branch, even though the content of those files didn't change, the commit hash has changed, so people that are working with you in this repo will have all kinds of conflicts later on.

SherylHohman
  • 16,580
  • 17
  • 88
  • 94
marknorkin
  • 3,904
  • 10
  • 46
  • 82
0

Any change on any file on the master branch would result in merge conflict (or even worse, unwanted silent override), so anyone else commiting their work to master would give you problems making collaboration more difficult.

On another note, if your feature branch history looks like that because you need changes from master during your feature development, why not just rebase your feature branch on top of master when you need updates?

Basically, what it will do is make you feature look like it was branched from master just prior to your merge.

So during feature development, if you use merge to get master updates:

  • feature commit 1
  • master commit 1
  • feature commit 2
  • master commit 2
  • feature commit 3

But if you use rebase to get master updates:

  • master commit 1
  • master commit 2
  • feature commit 1
  • feature commit 2
  • feature commit 3

So when you want to merge your feature back to master, the merge will basically be a fast-forward merge putting your feature commits on top of master branch.

Of course, there are situations when merging is more suitable, like if you want to keep your history, but that is up to you and your workflow.

Some more resource that will explain merge/rebase difference better:

https://www.atlassian.com/git/tutorials/merging-vs-rebasing

https://git-scm.com/docs/git-rebase

Tadija Bagarić
  • 2,495
  • 2
  • 31
  • 48
0

When you finish working on your feature branch, you will need to merge it to the master branch. While doing this, you might encounter merge conflicts, if both the feature and master branches contain changes at the same places. Since the merge occurs on your local repository, it is safe, you can take your time making sure all the changes you do will be correct. However, when you push your changes and they will be available to the team, then any mistakes that you do could escalate.

For this very purpose it is recommendable in many cases to merge master into feature branch, fix the possible merge conflicts in your feature branch, then merge it back to master. I know this involves an extra beaurocratic step, but it is worth it, since you have the option of pushing your merge without any risk and in the case there is someone who can answer your open questions or a tester to try things out, you are in a much safer situation.

Pushing to master is not always super risky. The risk level depends on the distance in steps between pushing to master and getting the pushed code live. If anything pushed to master gets instantly live, then it is extremely risky, while if master is a staging, then the risk is reduced, but still, I think it is more polite to solve any possible merge problems in your feature branch, and when everything is ok, then merge it back to master.

If master has no changes since it was merged into feature for the last time, then you can just merge your feature branch into master.

Theoretically, merging each commits separately is safer, but only if those commits are well tested, but in practice no one will do that, without a very specific reason, like some changes done by someone else which could be incompatible with your changes. But this is only needed when the merge of the heads fails for some reasons and you need to determine where the incompatibility comes from.

Lajos Arpad
  • 64,414
  • 37
  • 100
  • 175