Quantcast
Channel: User Schwern - Stack Overflow
Viewing all articles
Browse latest Browse all 581

Answer by Schwern for Prevent pushing a merge of the remote main branch into a local main branch in gitlab

$
0
0

You have two problems.

  1. fetch + merge creates an "update merge" that clutters history.
  2. You're not using merge requests so you have little control over what gets merged.

The solution is...

  1. Encourage fetch + rebase: git pull --rebase or set pull.rebase true.
  2. Use merge requests with the "Merge commit with semi-linear history" merge method in your merge requests.

For people who are still partying like it's 1999 and want to do everything on the command line, there's a glab command line tool. But unless you have a very specific reason you want to do everything on the command line, I suggest letting go of this requirement. Merge requests are just too useful; they're a standard, documented, and featureful way to accept, review, and test contributions.

Solution Part 1: Encourage fetch + rebase

You could add a pre-receive hook to prevent pushes with this sort of merge, but then your contributors have to know how to undo their merges. It's relatively simple, rebase their branch, but a lot of people don't know that. They'll either bother you about it, or give up and not contribute.

# pushing was disallowed leaving us in this state after git pull mergedA - B - E - U [main]     \     /      C - D [origin/main]# The user knows how to solve this by rebasing.$ git rebase origin/mainA - B - C - D [origin/main]             \              E1 [main]# Now the push succeeds.$ git pushA - B - C - D - E1 [origin/main][main]

This illustrates another problem: if the local branch has just one commit you won't get the feature bubble you want. However, you can force a merge commit if you use merge requests! This will be a theme.

You can simplify this by having git pull do a fetch + rebase. git pull --rebase or setting git config pull.rebase true.

# Branch is out of dateoriginA - B - C - D [main]localA - B [origin/main]     \      E [main]# Branch is up to date$ git pull --rebaseoriginA - B - C - D [main]localA - B - C - D [origin/main]             \              E1 [main]

Because this can rewrite history, pushes should be done with git push --force-with-lease.

You can't force people to do this, but you can encourage it.

You can't merge into a remote branch

I want to disallow this and allow only the merge in the other direction, local branch merged into origin remote tracking branch.

You can't merge into a remote tracking branch. Their purpose is to track the state of the repository. If you merge into the remote tracking branch it no longer tracks the remote. Git won't even let you switch to a remote branch.

> git switch origin/masterfatal: a branch is expected, got remote branch 'origin/master'

Solution Part 2: Merge commit with semi-linear history

I know that you can prevent this situation disallowing all pushes and work with merge requests.

You should do exactly that, at least for the main branch, for a myriad of reasons! Making git log come out as you'd like is the least of them.

Set your merge method to be Merge commit with semi-linear history. This will prevent merges unless the branch can be fast-forwarded, which is good because it means the code you test in the merge request is the code you will merge. And it offers a simple rebase button for your contributors to update their branches via rebase.


Viewing all articles
Browse latest Browse all 581

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>