Is it bad to git rebase a local branch off of another branch that is itself rebased often?
Say I have local branch A off of origin/master. I am continuously making changes to branch A, fetching the remote master, and rebasing.
Then I have local branch B off of A. I am continuously making changes to branch B and rebasing.
I am the only one working on branches A and B.
Is this a bad setup since A’s commit IDs (hashes) may be changing frequently? Does that destabilize branch B in any way or make conflicts more likely?
In fact, how does Git even implement this setup? What is B’s HEAD if A’s commit IDs keep changing out from under it?
2 Solutions collect form web for “Is it bad to git rebase a local branch off of another branch that is itself rebased often?”
If you are in this type of cycle (fetch/rebase) and see the same conflicts over and over, you could activate the
git rerere feature.
That will avoid having to do the same conflict resolution for each of your rebase.
See also “Are there any downsides to enabling
git rerere?”, “Fun with rerere” and “Rerere Your Boat…” for more.
This could cause conflicts to continue to cause conflicts every time.
Don’t rebase B off A unless topic B depends on topic A.
Otherwise, avoid causing conflicts between A and B.
The git implementation is that commits on B will depend on commits on the old A branch until you rebase.
Basically, when you rebase, git doesn’t delete the old commits, it just creates new commits by rebasing, and sets the branch A head pointer to the new final commit.
A branch is just a pointer to a commit.