Make a backup

Whenever in doubt, make a backup. Any way will do:

 git branch backup git tag backup git reflog 

Save the story!

If you reboot the feature branch to master before merge, I strongly recommend that you use merge --no-ff , i.e. force the creation of a merge commit. Without this, fast-forward and completely linear history will be obtained.

Merge commits will show the history of work on the project, in particular the moment of the merge feature-branch and the author of merge (who missed the code in the master). Starting with version 2.6.0, git can cancel (revert) merge commits . Without a merge commit, you will have to specify the exact set of commits for cancellation, which will not be easy with a linear history.

When it is impossible

• You cannot rebuild anything in stable branches ( master , stable , production , release-1.0 , etc.).
• When you started a commit to a remote repository (shared) and someone used it:
  • Branched off from him
  • Made a cherry-pick to another branch
  • I went to another branch
  • Linked to this commit (GitLab & GitHub in this case create a comment on the commit page with reference to the link)
• You can never rebuild someone else's commits. If you do this, Linus will come to you at night and make a hand re-draw on your hips .

Carefully

When you rebuy a branch from more than one commit and performance is important to you in intermediate commits, check each post rebuy. Rebeyz rewrites the contents of each intermediate commit, so if you have previously compiled a specific commit code or passed the tests, it’s not a fact that it will pass after the rebuy.

If there are a lot of commits in your branch and there are conflicts, you will have to resolve them many times (precisely because the contents of each commit are being rewritten). For comparison, with the usual merge, you resolve them once, in merge commit itself.

When can

• When you have a local branch that is not in the remote repository
• Or when there is a branch in the remote repository, but no one has used it exactly.

When should

• If in your team it is customary to rebuy to master before merge and / or the opening of merge-requisition.
• If your team decided to merge (flatten, squash) commits into one before merge and / or the opening of merge-request.

The above reasons work if there is also a rule in the team not to use other people's commits that are not locked to the master. If any of the conditions from the section “When it is impossible” is fulfilled - it is impossible to re-raise

Testing before merge

Rebeyz gives some advantage in testing. Suppose there are master and feature branches. Automatic and manual tests, auto code checks, profilers, etc. show a positive result on both branches. Will this result remain after merge? In general, it is unknown. Even if it is merg without conflicts, the code may not compile at all after merge.

Therefore, there is a reason to rebuild master before final testing. Then the head commit feature will be identical to the future merge commit. But this method is ineffective for the reasons already described:

1. Requires extra work on conflict resolution
2. Breaks the contents of intermediate commits

If there is a need to resolve conflicts and conduct a full test of the result of merge, but so far not merge in master, it is better to apply the reverse merge technique: master merzhitsya in feature . Accordingly, merge commit appears in the feature branch.

The resulting merge commit can be tested locally, it can be launched into a remote origin/feature branch to update the merge request, run tests, CI, deploy to a test environment, etc. When all checks are passed, make a "direct" merge - feature in the master .

You do not need to merge master into your branch just in the process of working on features, this leads to a story in the form of a Moscow metro map. If you can do without master merge in feature - be sure to get along.