7/11/2023 0 Comments Rebase branch with master git‘Always’ and ‘never’ are both equally bad. So are you really rewriting history? Debatable. You can still check out those old commits. Hell, if you do almost literally anything, all you’re ever doing is creating new commits. If you rebase, all you’re doing is creating new commits. If you do a non-fast-forward merge, all you’re doing is creating a new commit. Regardless of whether you rebase or merge to get your branch up to date with the target branch, you’re creating new commits. So what you meant to ask is “do you guys rebase or merge to get your feature branch up to date with the main branch”?Īnd honestly, if you think about it, it doesn’t really matter. In a normal workflow, rebasing is used to get a feature branch up to date with the target branch. main, master, staging) is to merge orĬherry-pick. The only ways to get commits from a feature branch into a target (e.g. This question in the title kind of doesn’t make sense. The history generated by rebasing is in my opinion a more realistic and honest representation of what happened in the code (when using pull requests instead of trunk base development).Īlso, the counterargument, that you said about "rewriting history", does only ever apply to the feature branch, which is in my eyes not such a big deal.While I'm still working on my feature branch (rebasing at least once a day) I can easily distinguish my changes from everything that is already on master.With that clean history many workflows become so much easier: cherry-picking, code reviews etc.That will become a pain to work with very quickly. When everybody merges, you will have all these commits mixed in the history. When you have three devs on a project and everybody uses rebase for their features, you can clearly see that in the history (commits 1-50 are feature A, commits 51-120 are feature B and commits 121 - 200 are feature C). Here are some reasons why I prefer rebasing: My workflow is, that I rebase at least every day, so that my feature branch is always up to date. In short, the majority of developers have a poor understanding of what a merge actually is, or even what a branch is, so rebasing leads to less confusion long-term. And the details it leaves out aren’t important details anyway. Sure, it makes the day-to-day workflow more inconvenient, but it makes it easy to understand the history of the repo. So my main reason for preferring rebases (along with squashes) is that it’s far less confusing. Instead, those two “branches” of commits are still very much separate, but there’s now a new commit (the merge commit) that essentially links those two sets of commits. But this is a lie, because that’s not what happened. The way those UI’s tell the story, the commits from the feature branch have actually been shoved into the history of your main/master branch (or whatever the target was) and those commits are all in one line now. Rebasing is often playfully called “lying”, but git log (with default arguments) and your average git web UI’s commit history view will lie to you just as much or even more after a merge. Piggybacking on this, I would actually argue that rebasing is far less misleading than a merge. He also agrees with me that git rebase is never a good idea and that we should have a discussion with the guy who set up our workflow about this. When I asked the lead dev over there about this, he said he doesn't like git rebase because it rewrites history. Interestingly, another department in my workplace only does git merge. Unfortunately, the dev who set up the workflows in my department is never available for general-purpose queries so I have no choice but to work with this. However, my workplace still uses git rebase and the only justification I keep hearing is that's the way it was always done. This way you can keep track of your entire work history. In git merge, you just take the HEAD of your feature branch and merge it with the HEAD of the main branch. With git rebase you are rewriting history by assuming your feature branch started with the most recent commit of the main branch (when, in reality, it started with a much earlier commit on the main branch).
0 Comments
Leave a Reply. |