move existing, committed work to a new remote branch in git


I created a local branch and committed changed to it, but later a remote branch was created for me which I did a git fetch to obtain access to locally.

How do I now move everything including untracked files over to the remote branch that was created?

I don’t want to lose any of my work, basically I want it so it’s as if this new remote branch that was created is where I did my work all along, as I plan to delete the local branch I originally created.

This can be confusing, so let me illustrate.

I created a local branch called ENGA-2604, but this branch will not be used now. Instead, this one will be used remotes/origin/feature/ENGA-2603.

So origin/feature/ENGA-2603 is what was created for me and so my work has to be in that branch because of the network tree it follows has to be the same as you can see below:

enter image description here

So thatENGA-2604 with the yellow track lines is what I created and that one has to go away, it’s on the wrong track. As a result, feature/ENGA-2603 was created for me, the one on the red track line. So all my work has to be in that one.


How do I now move everything including untracked files over to the remote branch that was created?

(emphasis mine)

You don’t. Fortunately, you don’t need to. Side note: I’ve assumed feature/ENGA-2603 is a typo that should read feature/ENGA-2604. If not, change the strings below appropriately.

Untracked files are not in the index and therefore are not in the next commit. The definition of “untracked file” is a file that exists in the work-tree, but not in the index. Branches only contain commits. Commits contain files. Files that are in a commit wind up in the index when you check out that branch, so if the file is not in the index, it won’t be in the branch.

As I understand your question, you are currently working in a branch named ENGA-2604. That is, if you run git status, its first line will say:

on branch ENGA-2604

(most of the remaining lines will be about what’s different in the index vs the HEAD commit, and what’s different in the work-tree vs the index).

You can easily rename any branch, including the one you are on. So just rename this branch:

git branch -m feature/ENGA-2604

You are now working on a branch named feature/ENGA-2604. You can set its upstream to the name origin/feature/ENGA-2604:

git fetch
git branch --set-upstream-to origin/feature/ENGA-2604

The git fetch will create origin/feature/ENGA-2604 (since feature/ENGA-2604 now exists in the repository you call origin); the --set-upstream-to sets your (local) origin/feature/ENGA-2604 as the name that your Git should use when comparing your (local) feature/ENGA-2604 to its upstream. Now git status will say things like:

on branch feature/ENGA-2604 (ahead 2, behind 3)

if/as appropriate.

The three commands git branch -m, git fetch, and git branch --set-upstream-to have no effects at all upon your existing index and work-tree. So no work you are doing right now has changed in any way. You’ve just renamed your local branch so that its name is now feature/ENGA-2604, and set it up to “track”1 your origin/feature/ENGA-2604.

1This is a terrible verb, but is the one Git uses. A local branch such as feature/ENGA-2604 “tracks” a remote-tracking name such as origin/feature/ENGA-2604 when the remote-tracking name is set as the upstream of the branch name. What this really does is convince Git to print those ahead 2 and/or behind 3 kind of strings when you run git status.

Well, it does slightly more: it makes git push and git merge and git rebase all a little more convenient, too. It enables you to use git pull too, but I would encourage you to avoid git pull. Use git fetch, then look at the commits that git fetch fetched, then run git merge or git rebase as appropriate, based on what git fetch fetched.

If you can predict, with 100% certainty (or close enough), what git fetch will fetch, then you can use git pull, which is just shorthand for run git fetch, then run one of git merge or git rebase: I have already picked which second command to use, without looking at what git fetch is going to fetch. You control the second command through your Git configuration, or by using git pull --rebase.

Answered By – torek

This Answer collected from stackoverflow, is licensed under cc by-sa 2.5 , cc by-sa 3.0 and cc by-sa 4.0

Leave a Reply

(*) Required, Your email will not be published