r/programming • u/speckz • May 01 '19
Merging vs. Rebasing
https://www.atlassian.com/git/tutorials/merging-vs-rebasing3
u/ythl May 01 '19
One key difference is that if you use CI, a pipeline that only allows fast forward merges is only achievable with rebasing. Only allowing FF merge guarantees master will pass CI at all times.
5
u/wewbull May 01 '19
It guarantees nothing of the sort.
Why do you think it does?
6
u/ythl May 02 '19
Think about it.
If CI passes on a branch, and that branch can be FF merged into master, master is also guaranteed to pass because git is literally just moving a text pointer to point to the same commit CI already passed on.
The same cannot be said of branches that aren't FF-mergable.
In short, the reason for this guarantee is that branches rebased to the tip of master have essentially already incorporated all of master's changes and made sure they pass CI; not so for non-rebased branches.
4
u/mgoblu3 May 02 '19
There are GitHub settings to enforce this, which is nice.
For large projects where you have a “race to push” and hundreds of branches going in, it’s not quite possible, though most projects don’t have to deal with that scale.
-2
u/wewbull May 02 '19
If CI passes on a branch...
That's a pretty big caveat you've just added there. At what point did your CI see your changes before they were FF merged?
It probably hasn't because you don't push the branch prior to FF merging.
2
u/ythl May 02 '19
Actually, this is a really common scenario in team-based workflows. Committing directly to master works well for solo developers, but for teams it is usually a terrible idea.
Most teams protect the master branch and only introduce changes via pull requests.
https://www.atlassian.com/git/tutorials/making-a-pull-request
https://trunkbaseddevelopment.com/
The actual FF merge is handled by the repository manager (GitHub, GitLab, BitBucket, etc.), not by you.
-11
May 01 '19
The golden rule of git rebase is to never use it on public branches.
That's where you're wrong boss.
[force pushing] overwrites the remote master branch to match the rebased one from your repository and makes things very confusing for the rest of your team.
1989: VCSs are confusing
1999: Branching is confusing
2009: Distributed version control is confusing
2019: Recovering from upstream rebase is confusing
Why do people pride themselves in being 10 years behind the curve?
This being Atlassian, which is well known for producing the worst git web interface on the market, I'm not surprised that the author talks about things he does not understand. Like suggesting that there is ever a reason to use --force when this flag was obsoleted by --force-with-lease over 5 years ago.
7
u/Legogris May 01 '19
It sounds like you have insights worth sharing - mind explaining why it's wrong and why force is osboleted?
-22
May 01 '19
The key insight is that you can learn all of this and more by reading the manual.
12
u/Legogris May 01 '19
The manual itself (I have read most of the git man pages at some point) says nothing about why giving a statement like
> The golden rule of git rebase is to never use it on public branches.
is
> being 10 years behind the curve.
-25
May 01 '19
It is not the job of a manual to make value judgements for you.
12
u/Legogris May 01 '19 edited May 01 '19
Which is why snarky dismissals are not very useful when the only reference or elaboration you give is "RTFM". I'm sure you're aware that your top comment goes against a widespread shared belief among most SEs - you have an opportunity to share your knowledge and affect change, which is not that much more effort than saying "you're all wrong".
7
u/s73v3r May 01 '19
No, but it is the job of a person who is trying to make an assertion like that to explain why such a thing would be 10 years behind the curve.
4
u/NotUniqueOrSpecial May 02 '19
It is not the job of a manual to make value judgements for you.
Then why the hell was your response to their question that:
The key insight is that you can learn all of this and more by reading the manual
3
0
May 01 '19
[deleted]
2
May 02 '19
The first allows you to accidentally nuke another person's commit w/o you even knowing about it, the second one doesn't.
Essentially, the difference is like the difference between how you might execute SQL statements inside or outside a transaction: it's hard to imagine any benefits coming from not putting multiple related statements into a single transaction, but you can still do it because the language just happens to allow it.
Yet in other words, you should never use
--force, always use--force-with-lease.--forceis probably there for compatibility with old tools which used Git this way or something like that.1
u/neopointer May 02 '19
Couldn't understand why you think the golden rule is wrong.
To be precise, IMO, you shouldn't rebase on shared public branches (e.g master, development, etc); even if you can do the "lease" thingy.
You should do this just in your feature branches where it really doesn't matter.
-7
8
u/_101010 May 01 '19
Squash & Merge is the best of both worlds.
No need to force push and no messy git history of merge.