0

Me and my friend commited, then I pushed my changes, he tried push as well, but GitLab refused, and that is good,

enter image description here

but he then pulled changes and a "branch out" and "branch in" is displayed in the graph. Is it a way to avoid this phenomenon and force him to rebase his changes?

dev-3 is protected in GitLab.

enter image description here

enter image description here

János
  • 32,867
  • 38
  • 193
  • 353
  • 1
    Those merge commits are an artifact of your workflow. To avoid them, you must only allow fast-forward merges to master, but that implies that branches need to be rebased on top of master before merging them (which can imply force-pushes to feature branches, which has its own drawbacks). It seems that [Bitbucket supports the "Rebase, fast-forward" strategy](https://confluence.atlassian.com/bitbucketserver/pull-request-merge-strategies-844499235.html) which seems to do what you want. – Joachim Sauer Apr 27 '20 at 14:15
  • Does this answer your question? [How to make Git pull use rebase by default for all my repositories?](https://stackoverflow.com/questions/13846300/how-to-make-git-pull-use-rebase-by-default-for-all-my-repositories) – LeGEC Apr 27 '20 at 14:25
  • Does this answer your question? [How to resolve git error: "Updates were rejected because the tip of your current branch is behind"](https://stackoverflow.com/questions/22532943/how-to-resolve-git-error-updates-were-rejected-because-the-tip-of-your-current) – phd Apr 27 '20 at 15:24
  • https://stackoverflow.com/search?q=%5Bgit%5D+Updates+were+rejected+because+the+tip+of+your+current+branch+is+behind – phd Apr 27 '20 at 15:24

2 Answers2

1

There are a couple different questions there...

If you want your long-term history to look "linear" (i.e. no branches/merges), then as you note, you would use rebase. In this case, if you are pulling in order to be able to push, you need the pull to rebase instead of merging the changes. You can do that with git pull -r. (It's also possible to configure your local repo to do this by default, but please refer to the git config docs if you want to consider that; it is considered a potentially risky configuration.)

You also asked if you can "force" the other devs to rebase their changes. As a general rule I would rethink the mindset of "forcing" one behavior or another, but in any case if a team wants to enforce rebase-only, it can be done at the remote repo. With git in general you would use a pre-receive hook, which would reject pushes that don't "follow the rules". For hosted repos (github, gitlab, etc.) you may not have direct access to server-side hooks, so you'd have to refer to those services' documentation.

(Note that "when the dev tries to push" is a pretty late time to catch the problem, as the dev may have accidentally broken the rule and based a bunch of work on the mistake. To mitigate that, the local repo can be configured with a pre-commit hook that enforces the same rule at commit time. But client-side hook configuration can't be "enforced", which is why you start with the server-side hook.)

An additional consideration is whether this is really the right priority. There are costs to rebasing. Many people/teams do decide that the more linear history is the more important concern, but it's at least something a team should be thinking about. (The biggest cost is, if you routinely rebae work, unless you reest every commit after the rebase, you can't assume that every commit is tested / passing.)

Mark Adelsberger
  • 42,148
  • 4
  • 35
  • 52
1

I documented before in May 2015 with "Can “git pull” automatically stash and pop pending changes?" how to configure locally your Git in order for a git pull to rebase:

git config --global pull.rebase true
git config --global rebase.autoStash true

That means it is a local configuration on the client side, not a GitLab settings on the server side.

That would replay (with a simple git pull) their own #123 commit on top of origin/dev3.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250