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.

  • Can I comment out a line on a .git/config file?
  • fatal: Pathspec 'autoload_classmap.php' is in submodule 'module/CocktailMakerModule'
  • Git branches cannot see changes after rebase of master
  • How do I get Putty to show color coding on git output?
  • Rebasing pushed commits if only on personal branch
  • Cloning on ubuntu takes a long time
  • 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?

  • How do I squash all commits without losing submodules?
  • Find source of mistake: git push rejected: error: failed to push some refs
  • How to make git grep show at the top instead of the bottom of the terminal screen?
  • Merge pull request into different branch
  • What are the common usages of tagging something else than a commit?
  • npm install error though Python already included
  • 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.

    Git Baby is a git and github fan, let's start git clone.