6 ms·
You may believe so, but it's not true. Let me explain. There are two somewhat different use cases for rebasing: 1. You want to do the equivalent of a merge wit
by patrec 6y ago
You may believe so, but it's not true. Let me explain. There are two somewhat different use cases for rebasing:
1. You want to do the equivalent of a merge without creating a merge commit, which is what I was mostly talking about when I was contrasting a merge based with a rebase based workflow. There is precisely zero difference in guarantees of things working or building or whatever between you rebasing or merging a branch into master. In fact, funnily enough, if you actually do testing/CI correctly, issuing a "git merge feature-branch" command to land things in master will, with high likelihood do a rebase rather than creating a merge commit. This is because you will have pre-merged (or equivalently, as far as testing the right thins is concerned, rebased) master into your feature branch first. Because that's the only way to actually test the right thing (the state of the code as it will be once it lands it master).
2. You can use rebase to (potentially wildly) rewrite individual commits (splitting them up, re-arranging or melding or editing them etc.) on your feature branch. This is not what I'm talking about, but, I have the feeling, the thing you are actually objecting to. And yes, you can indeed mess up previously working commits this way. If you feel uncomfortable doing this, just don't -- you can still use (and profit from) a purely rebase based workflow.[+]
[+] As an aside: there are ways of doing this type of rewriting that give you guarantees of working and building -- e.g. just run git rebase --exec "make clean && make test" ... (each individual commit in the rebase is tested before landing and the rebase stops on anything that errors out)[++]. But as I mentioned, you can still get all the benefits of a rebase-based workflow without ever engaging in this type of rebasing, and similarly you can have a fully merge-based workflow (for landing things in master) and people might still wildly rebase-to-rewrite their commits on their feature branches (and if they are not even pushed, who's gonna stop them?). These things are really orthogonal. Also, whilst I agree that undisciplined rewriting of commits is a bad idea, and can mess up previously working non-HEAD commits, it should never mess up the final commit on a feature branch undetected. Because you're running CI, right?. And at the end of the day almost no workflow will run full tests/CI on every commit (too expensive for anything but small projects), so broken "intermediate" commits can even happen without rebasing and if you do in fact run CI on every commit, well even undisciplined rebasing is perfectly safe.
[++] Also: I'd recommend preferring git commit --fixup to wildy messing about with git rebase -i on the fly.
- lmm 6y ago> There is precisely zero difference in guarantees of things working or building or whatever between you rebasing or merging a branch into master. In fact, funnily enough, if you actually do testing/CI correctly, issuing a "git merge feature-branch" command to land things in master will, with high likelihood do a rebase rather than creating a merge commit. This is because you will have pre-merged (or equivalently, as far as testing the right thins is concerned, rebased) master into your feature branch first. Because that's the only way to actually test the right thing (the state of the code as it will be once it lands it master). The head commit on master is the same, but the state of previous commits from your branch becomes different and untested, and quite possibly broken. And presumably you valued that commit history on your branch, or why keep them at all? If you want master's history to only reflect the sequence of features landing master, squash-merging is a much better way to achieve that than rebasing - it doesn't create a fictional commit history, just the mega-commits you wanted. Future bisects will land you on a mega-commit, but at least you don't have to handle a bunch of non-compiling states on the way there.
- patrec 6y ago> The head commit on master is the same, but the state of previous commits from your branch becomes different and untested, and quite possibly broken. Try to break it down, and you will see that the scenario you're positing doesn't make much sense and your concerns are unfounded: Let's posit the following: 1. We have a feature branch B, with carefully crafted and individually tested commits. 2. We have a minimally working CI setup (which means we always test the code state of the new head of master before landing stuff in master "for real"). On that assumption one of two things can happen when you try to land B whether via rebase or merge: a) CI fails, because changes in master in the meantime make it so your branch now triggers a test failure or merge conflict whereas before it didn't. We can ignore this, scenario, because nothing lands till b) CI passes. So we know the HEAD commit on master is fine. But, you say, whilst I know the individual commits on B are also good (I tested them all) and the merge commit is good (CI!), with rebase I only know the head commit works -- what if the rebasing broke some intermediate commits? But for that to happen, all the following need to be true: 1. You don't didn't use rebase -x (why not, if you carefully test all individual commits on the feature branch?) 2. Your individual commits all work correctly on the feature branch and would pass CI. 3. The sum of your individual commits plus master works correctly and definitely does pass CI. 4. Because of changes in master branch since the common ancestor of present master and B, a) at least one of the commits of B no longer would pass CI when tested, although it does on the branch (not an unlikely scenario so far) AND b) a latter commit on the feature branch miraculously fixes this incompatibility (because we know the HEAD passes). This is not theoretically impossible, but exceedingly unlikely. And, you can easily guard against it happening as described above.