Does git branch -m have side effects for other developers?

We’ve already learned how to switch which branch points to what using git branch -m. If I do this, is it going to make life difficult for the other people pulling from my repository?

Say I do a bunch of stuff on a branch topic1 and then do a

  • while merging two branches. My files are getting lost
  • moving pushed commits to new branches
  • what should the master branch contain in git
  • Following git-flow how should you handle a hotfix of an earlier release?
  • Discard a local branch in Mercurial before it is pushed
  • How to move master to branch without merge
  • git branch -m master old_master
    git branch -m topic1 master
    git push origin master
    

    and then somebody else pulls master from the my remote repository, what will they have to do to make everything point to the right place? Will I have to tell everybody to repeat my steps?

    Is this akin to the problem of rebasing commits after pushing them and leaving other developers with dangling objects?

  • How to `git show` on a file that was renamed after specified revision?
  • Inconsistent information in Git (log vs. diff) about single file
  • How to deselect files when using git interactive staging?
  • Error during creating my own pod with ObjectiveC
  • Github: looking for a smart Git setup with shared files
  • How do I hide a file from a single remote repo in git?
  • 2 Solutions collect form web for “Does git branch -m have side effects for other developers?”

    I’m not exactly sure what your repo looks like but here’s the worst-case scenario.

    Suppose your origin repository looks like this

    origin:
    o---o---A---B---C  master
    

    And your local repository looks like this,

    JimPuls:
    o---o---A---B---C  master, origin/master
             \
              D---E---F topic1
    

    Then, after your branch renames your local repository looks like this:

    JimPuls:
    o---o---A---B---C  old_master, origin/master
             \
              D---E---F master
    

    Now, when you push master to origin that’ll be a non-fast-forward update. After the push, the origin repository will look like this:

    origin:
    o---o---A...B...C  (B & C are orphaned commits)
             \
              D---E---F master
    

    This can be cruel to your friends who may have done commits on top of C. For example, if Sally was working with you her repository may look like this:

    Sally:
    o---o---A---B---C  origin/master
                     \
                      G---H---I master
    

    Now, if you do your non-fast-forward push and Sally does a fetch her repository will look like this:

    Sally:
              D---E---F  origin/master
             /
    o---o---A---B---C  
                     \
                      G---H---I  master
    

    Now Sally has to figure out how to get her work (G, H, I) back into the repository. If she simply does a merge with origin/master then the changes in B and C will be back in the repository (oops!). Instead, she’ll have to cherry-pick or rebase her G-H-I changes onto origin/master.

    It’s cool that Git lets you do that but it’s kind of asking for trouble. You’re really hoping that Sally notices the situation. This is why you should warn all the other contributors when you do this so they can deal with the change appropriately.

    NOTE: the above is a worst-case scenario. If your topic1 branch departed from master at C then that change is a fast-forward and there are no problems.

    Basically your operations are the same as:

    # git checkout master
    # git reset --hard topic1
    # git push origin master
    

    And they will have exactly that effect: Everybody else will get the topic1 branch (it’s named master for them, though) and its ancestry up to the point where master and topic1 first diverged. The old master branch is then lying around in their repositories and will be garbage collected at some point in the future because nothing points to it anymore.

    If topic1 is a branch that originated from the current HEAD of master you will be fine here. Otherwise you will get into the “rewriting history” situation which can make a mess of your e.g. your tags. You need to think carefully about what you’re really trying to achieve. Maybe a simple git merge will serve you better?

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