CentOS Question posted in
The official documentation can be found here.

How to move unpublished commits from one branch to another? – CentOS

I have committed my changes on my local master and was about to create a new feature branch for these commits. The local master is up-to-date with the master on my remote.
I forgot that the branch already exists both locally and on my remote, so this happened:

git checkout -b myFeatureBranch
fatal: A branch named 'myFeatureBranch' already exists.

The branch is based on an old master and includes couple of commits.

My goal is to get rid of the old commits on that branch, rebase the feature branch on the current master and apply my new commits that are on my local master branch.

What’s an elegant way to do this? I think a not so elegant way would be to:

  1. Checkout the old feature branch
  2. Rebase it on origin/master
  3. Replace the files I have edited with the most recent version of themselves (the version of my local master)
  4. force push (Im the only one working on that branch)
  5. ‘force pull’ master to get rid of my changes that I now have on the feature branch

I’m on git version 2.18.1 (most recent available release on Centos 8) and prefer to use the CLI.

Tags:

3

Answers


  1. 0

    You could just try resetting your feature branch to master:

    # from myFeatureBranch
git reset --hard master

    After this step, your feature branch would be starting off at whatever point in which the local master branch happens to be.

    Note that you would then need to force push your reset feature branch to the remote via:

    git push --force origin myFeatureBranch
    Login or Signup to reply.
  2. 0

    A. If you need your old branch commits, then you can simply create another branch instead of myFeatureBranch:

    git checkout -b myFeatureBranch2

    And then you can push your new branch and do what you want with that branch (eg. give a pull request to master).

    B. But if you don’t need your old branch commits (neither locally or remotely) you can delete old branch and then use that branch name:

    git push -d origin myFeatureBranch
git branch -d myFeatureBranch
git checkout -b myFeatureBranch

    C. If you have some useful commits on old myFeatureBranch, and don’t want to miss them, then you can go to that old branch and rebase it with master (containing new commits) and push it:

    git checkout myFeatureBranch
git rebase -i master
git push -f
git checkout master
git fetch origin
git reset --hard origin/master
    Login or Signup to reply.
  3. 0

    My goal is to get rid of the old commits on that branch, rebase the feature branch on the current master and apply my new commits that are on my local master branch.

    I think the first thing to do is clear up some confusion here. If you’ve removed the commits from the feature branch, then there is nothing to rebase. rebase is something you do to commits; it means “make a commit (usually with a different parent than the old commit) whose patch relative to its parent is the same as the old commit’s patch relative to its parent”.

    When people say they are rebasing a branch, they mean they are rebasing the commit(s) from the end of that branch, and then moving the branch to the new copies of the commits.

    And to be fair, you can use the rebase command without rewriting any commits, in which case it just moves the branch – which works out conveniently in cases where you don’t want to worry about whether there are any commits to rewrite or not.

    But it’s still worth understanding these details, because if you realize that you just want to move the branch without any commits, there are easier ways to do it. (You don’t even have to explicitly delete the old commits; it’s fine to just leave them behind when moving the branch, if they are in fact no longer needed.)

    The one caveat is that if you remove the old commits from the branch (whether by rebasing – which replaces those commits with new copies – or by just moving the branch or by any other means) then all other repos have to deal with an “upstream rebase” condition (see the git rebase docs) and, if they do it wrong, they may undo your work.

    That said, the simplest thing to do is to replace your checkout -b command with branch -f – i.e. instead of creating the branch, force it to move. With the new commit checked out (just as it would’ve been for the checkout -b):

    git branch -f myFeatureBranch
git push -f
# all other clones must now recover from upstream rebase
    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search