问题
Me and my friend commited, then I pushed my changes, he tried push as well, but GitLab refused, and that is good,
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.
回答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.)
回答2:
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.
来源：https://stackoverflow.com/questions/61460843/is-it-a-way-to-avoid-branch-out-branch-in-when-git-pull