CODEWITHSUNDEEP
gitproject-managementgit-mergegit-rebasegitlab
Senthil Kumar
Senthil Kumar

Reputation: 10295

Git squash merge or git force push?

We're using gitlab. Master branch is protected and only project owners can commit/accept merge requests to the master. Other developers send a merge request to get their code into master.

When we send for merge requests (from a feature branch to master), one of the developers review the code. If there are any suggestions/comments, the developer updates his code and the merge request shows the new commits also.

Then QA starts testing on the branch, developer fixes bugs in the same branch. When all is done and good to go, QA adds a comment in the merge request saying it is tested.

Since there are lots of commits but the feature is one, to make it easy to manage, we would like to just push it as a single commit.

Here is where the project owner and I contradict. I ask the project owner to do a git merge --squash but he asks me to rebase my branch by squashing everything into the last commit and do a force push. Since the branch will die after this, his argument is, it is not likely to cause any trouble.

So, which is the best way to follow here?

P.S. There are is no GUI option to do a squash merge in gitlab and only option available is to merge all commits as they are.

Upvotes: 2

Views: 3507

Answers (1)

Vicente Quintans
Vicente Quintans

Reputation: 1416

The outcome of both operations is quite similar, a commit on top of master and a feature branch that will eventually die.

The merge --squash forces the project owner to take care of conflicts that could arise. To avoid that problem you would have to merge origin/master in your feature branch just before the merge.

After that the only difference in the final result is where the feature branch points after the operations:

  1. After the merge origin/master, merge --squash: feature branch will point to a moribund branch that will eventually die but will be somewhat confusing: is it merged already?
  2. After the rebase, force push, merge --ff the feature branch will point to the squashed commit.

You have to decide:

  • a process that forces you to "remove" feature branches, making it an explicit choice to keep feature branch history (by creating a new ref before the rebase and pushing it - maybe with an updated name: featureA_merged)
  • a process that keeps all feature branches but forces you to remember/manage wich branches have been merged.

IMHO the rebase and force push is a cleaner solution after all. You take care of potential conflicts and you move the reference out of the moribund branch that could cause trouble and/or confusion in the future. Even doing something that looks as wrong now, the force push.

Upvotes: 4

Related Questions