[deleted]
Don't use Git rebase
51–60 of 88 posts
Re: Don't use Git rebase
#52There's a more nuanced approach to git rebase. You should use it the other way around - switch to your feature branch and `git rebase master` to update your branch and resolve conflicts. Then test it and `git merge`. I also use git rebase to tidy up the branch's history - generally not entirely squashing it, though.
Or well, simply use both. Feature branch, use merge - the feature is an important artefact, and there it is important for the history to show it. Bug Fix branch, working on a shared branch, use rebase. The branching in those case is a side effect the exact time two colleague committed on the same branch. There is no information you gather from that, it is just a technical blip in the history. Not quite sure the obses…
Rebases and merges don't work well together. By default, git rebase will get rid of merge commits. While there is an option to preserve merges (-p), it can lead to some strange behaviour while doing an interactive rebase - see BUGS section in git-rebase man page for more details.
I'd also argue that merge and rebase represent fundamental differences in what commits mean. The former being commits are history, and the latter being commits are features.
Re: Don't use Git rebase
#53I vehemently disagree. A counter-argument to his `git bisect` problem is whenever I do `git bisect` and I end up on the merge commit being the culprit. At that point I want to cry, because merge commits tend to be ungrokkable — there is so much noise in them.
Also, don't even get me started on `git revert`ing merge commits... Down that road lies sadness and disillusion.
Re: Don't use Git rebase
#54What's even the point of using rebase? Merging the development branch into your feature branch periodically is the obvious history preserving thing. Git already has merge commits, that can be used to label and describe bigger sets of changes in retrospect. There is no need to rewrite the commit history with the benefit of hindsight, it only erases the record of how changes were arrived at, thus losing the opportunity…
Gee, sounds like a fun PR to review.
Re: Don't use Git rebase
#55I vehemently disagree. A counter-argument to his `git bisect` problem is whenever I do `git bisect` and I end up on the merge commit being the culprit. At that point I want to cry, because merge commits tend to be ungrokkable — there is so much noise in them. Also, don't even get me started on `git revert`ing merge commits... Down that road lies sadness and disillusion.
Indeed. Seems like a better solution to his problem is to run unit tests after a merge before pushing it upstream. Then no more non compiling commits.
Re: Don't use Git rebase
#56`git rebase --exec {rebuild project}` solves the issue of invisible errors in commits. I'm a big fan of Gerrit's review workflow, which requires every commit to build in isolation. I also usually try to squash my changes into logical independent commits before review. I like rebase because it's prettier, but I also think there's an issue with the non-rebase case that the OP has missed: unless you rebase, you're setti…
My preferred solution is letting "robots" do the actual rebase back to master. In my GH repo I set a label that says 'ready to land' which means that the last CI run will assume that done stuff like proper commit messages and have reworked my commit into how I want them (atomicity, etc). If for whatever reason tests, the extra validations and ultimately trying to rebase to master doesn't pass I get notified as a PR status.
I like the separation between having full freedom in a feature branch without the extra hassle of having to consider timing (active repos usually suffers from this) or typo:ing in commit metadata.
Re: Don't use Git rebase
#57> Graphs of non-linear history, “train tracks”, can be intimidating. They certainly felt that way to me to begin with, but there’s no reason to be scared of them. There are many magnificent tools that can analyse and visualise complex Git history, both GUI- and CLI-based. It's a pity the author doesn't mention some of those magnificent tools. Some tools I know/use: CLI: tig GUI: gitg, qgit (Linux) Any others?
The only git tool that really stuck with me was "SmartGit".
Great log view and rebasing/reordering and squashing of commits with drag and drop.
I never have to use anything else^^
Re: Don't use Git rebase
#58Earlier quoted context omitted.
Or well, simply use both. Feature branch, use merge - the feature is an important artefact, and there it is important for the history to show it. Bug Fix branch, working on a shared branch, use rebase. The branching in those case is a side effect the exact time two colleague committed on the same branch. There is no information you gather from that, it is just a technical blip in the history. Not quite sure the obses…
Rebases and merges don't work well together. By default, git rebase will get rid of merge commits. While there is an option to preserve merges (-p), it can lead to some strange behaviour while doing an interactive rebase - see BUGS section in git-rebase man page for more details. I'd also argue that merge and rebase represent fundamental differences in what commits mean. The former being commits are history, and the…
I'm a pretty basic got user, just wanted to say this was a really useful distinction for me to read.
Re: Don't use Git rebase
#59`git rebase --exec {rebuild project}` solves the issue of invisible errors in commits. I'm a big fan of Gerrit's review workflow, which requires every commit to build in isolation. I also usually try to squash my changes into logical independent commits before review. I like rebase because it's prettier, but I also think there's an issue with the non-rebase case that the OP has missed: unless you rebase, you're setti…
But that's exactly why I prefer merges - seeing that the problem wasn't in any individual branch, but resulted from the combination of changes in both is the most honest result that I would've wanted to see. Why do you label this as a 'failure'?
It sounds like rebasing this way ensures branches will not overlap at merge time. This presumably pushes the "combination of changes" into the rebased-before-merging branch, which (if nothing else) makes sure that one committer owns the bug, not two.
Re: Don't use Git rebase
#60Earlier quoted context omitted.
Ok, if your set of changes is too large to review in one piece, and you put in the work of refactoring your changes into a speedrun-style best possible history so they are cognitively review-friendly, I grant that this is a valid use case for rebase. Though erasing the real history is still a serious drawback, and the unit of code review is still too large. Not many projects work like this, however.
On a given feature branch the history is only important if there is more than one review until the work is complete. What the developer does in between these visible/public events is almost always not important. For example in a "make work, make right" situation where the original work is thrown away and rewritten you definitely are not interested in the history.
Have you ever gone back to your (or someone else's) code from 6 months ago and needed to refresh your memory about what you tried and what didn't work, or why some of your test cases/data are what they are? Or why you commented out some test? It can be very helpful, I think this history is often important. And you won't know if a given bit of code history is important until you need it.