4 ms·
As soon as two people work on the same branch, rebasing becomes a problem. As long as you're the only one modifying the branch, rebasing works nicely.
by hibbelig 6y ago
As soon as two people work on the same branch, rebasing becomes a problem.
As long as you're the only one modifying the branch, rebasing works nicely.
- dreamcompiler 6y agoI don't like rebase in solo code either; I want my personal history to be the truth, not some convenient fiction. In a team environment, somebody always insists on using rebase and then invariably they push a rebase to master and hijinks ensue. I wish there was a fork of git with rebase disabled.
- darekkay 6y ago> I want my personal history to be the truth, not some convenient fiction. I am mostly using the Git history when going through past changes. Why does this line do X? I just git blame this line and see exactly what happened. This is the time I really hate all those "oops, fixed mistake" and "forgot this change" commits. I don't care about those things, even if it's the "truth". They're just useless and distracting. Doing an amend/rebase/squash would have been perfectly fine in such a scenario. I have written more about rewriting Git history here [1]. > In a team environment, somebody always insists on using rebase and then invariably they push a rebase to master and hijinks ensue. I wish there was a fork of git with rebase disabled. That's why shared branches like master are usually protected, so you cannot push an alternative history. [1] https://darekkay.com/blog/git-rewriting-history/ https://darekkay.com/blog/git-rewriting-history/
- Accacin 6y agoWhere I work we always rebase on branches for features/bug fixes/tickets/whatever, but when we merge into master we always do `git merge --no-ff origin/branch`. We don't really care what the history of our branches are generally, and we preserve our commit history when we go into master. We never squash when we go into master either.