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.

  • Maintain set of local commits working with git-svn
  • In Git, how do I configure a hook to run a server-side commands after a commit is accepted?
  • Search all of Git history for a string?
  • Unauthorized Fingerprint
  • Git doesn't recognize renamed and modified package file
  • Intellij import issue - Cannot run program “git”: error=2, No such file or directory
  • 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?

  • .gitignore does not work
  • Unable to access 'git/attributes'
  • In Eclipse/EGit is there a way to edit commit message of unpushed/local commit?
  • Where does Github desktop install command line version of Git
  • Eclipse shortcut for Compare With Head Revision
  • How to cleanup garbage in remote git repo
  • 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.