I created a bugfix branch to fix a bug on a project that I had forked on GitHub. I issued a pull request to the developer to incorporate my fix, but the developer decided to implement a different fix for the problem. At this point, I want to delete the bugfix branch both locally and on my project fork on GitHub.
$ git branch -D bugfix Deleted branch bugfix (was 2a14ef7).
$ git branch -d remotes/origin/bugfix error: branch 'remotes/origin/bugfix' not found. $ git branch -d origin/bugfix error: branch 'origin/bugfix' not found. $ git branch -rd origin/bugfix Deleted remote branch origin/bugfix (was 2a14ef7). $ git push Everything up-to-date $ git pull From github.com:gituser/gitproject * [new branch] bugfix -> origin/bugfix Already up-to-date.
What do I need to do differently to successfully delete the
remotes/origin/bugfix branch both locally and on GitHub?
As of Git v1.7.0, you can delete a remote branch using
git push origin --delete <branchName>
which is easier to remember than
git push origin :<branchName>
which was added in Git v1.5.0 "to delete a remote branch or a tag."
Therefore, the version of Git you have installed will dictate whether you need to use the easier or harder syntax.
From Chapter 3 of Pro Git by Scott Chacon:
Deleting Remote Branches
Suppose you’re done with a remote branch — say, you and your collaborators are finished with a feature and have merged it into your remote’s master branch (or whatever branch your stable codeline is in). You can delete a remote branch using the rather obtuse syntax
git push [remotename] :[branch]. If you want to delete your serverfix branch from the server, you run the following:
$ git push origin :serverfix To firstname.lastname@example.org:schacon/simplegit.git - [deleted] serverfix
Boom. No more branch on your server. You may want to dog-ear this page, because you’ll need that command, and you’ll likely forget the syntax. A way to remember this command is by recalling the
git push [remotename] [localbranch]:[remotebranch]syntax that we went over a bit earlier. If you leave off the
[localbranch]portion, then you’re basically saying, “Take nothing on my side and make it be
git push origin :bugfix and it worked beautifully. Scott Chacon was right—I will want to dog ear that page (or virtually dog ear by answering this on StackOverflow).
I have a master and a dev branch, both pushed to github, I've cloned, pulled, fetched, but I remain unable to get anything other than the master branch back.
I'm sure I'm missing something obvious, but I have RTM and I'm getting no joy at all.
First, clone a remote git repository and cd into it:
$ git clone git://example.com/myproject $ cd myproject
Next, look at the local branches in your repository:
$ git branch * master
But there are other branches hiding in your repository! You can see these using the
$ git branch -a * master remotes/origin/HEAD remotes/origin/master remotes/origin/v1.0-stable remotes/origin/experimental
If you just want to take a quick peek at an upstream branch, you can check it out directly:
$ git checkout origin/experimental
But if you want to work on that branch, you'll need to create a local tracking branch:
$ git checkout -b experimental origin/experimental
Now, if you look at your local branches, this is what you'll see:
$ git branch * experimental master
You can actually track more than one remote repository using
$ git remote add win32 git://example.com/users/joe/myproject-win32-port $ git branch -a * master remotes/origin/HEAD remotes/origin/master remotes/origin/v1.0-stable remotes/origin/experimental remotes/win32/master remotes/win32/new-widgets
At this point, things are getting pretty crazy, so run
gitk to see what's going on:
$ gitk --all &
I know how to make a new branch that tracks remote branches. But how do I make an existing branch track a remote branch. I know I can just edit the
.git/config file, but it seems there should be an easier way.
It looks like this can't currently be done in a convenient way with the current (1.6.1.x) version of Git.
Git version >= 1.7.0 supports this. See the accepted answer.
Given a branch
foo and a remote
As of Git 1.8.0:
git branch -u upstream/foo
Or, if local branch
foo is not the current branch:
git branch -u upstream/foo foo
Or, if you like to type longer commands, these are equivalent to the above two:
git branch --set-upstream-to=upstream/foo git branch --set-upstream-to=upstream/foo foo
As of Git 1.7.0:
git branch --set-upstream foo upstream/foo
All of the above commands will cause local branch
foo to track remote branch
foo from remote
upstream. The old (1.7.x) syntax is deprecated in favor of the new (1.8+) syntax. The new syntax is intended to be more intuitive and easier to remember.
I started some work on a new feature and after coding for a bit, I decided this feature should be on its own branch.
How do I move the existing uncommitted changes to a new branch and reset my current one?
I want to be sure that I can reset my current branch while preserving work on the uncompleted feature.
Use the following:
git checkout -b <new-branch>
This will leave your current branch as is, create and checkout a new branch and keep all your changes. You can then make a commit with
git add <files>
and commit to your new branch with:
The changes in the working directory and changes staged in index do not belong to any branch yet. This changes where those changes would end in.
You don't reset your original branch, it stays as it is. The last commit on
<old-branch> will still be the same. Therefore you
checkout -b and then commit.
I have the branch
master which tracks the remote branch
I want to rename them to
master-old both locally and remote. Is that possible? For other users who tracked
origin/master (and who updated their local
master branch always just via
git pull), what whould happen after I renamed the renamed the remote branch? Would their
git pull still work or would it throw an error that it coudln't find
Then, further on, I want to create a new
master branch (both locally and remote). Again, after I did this, what would happen now if the other users do the 'git pull' now?
I guess all this would result in a lot of trouble. Is there a clean way to get what I want? Or should I just leave
master as it is and create a new branch
master-new and just work there further on?
The closest thing to renaming is deleting and then re-creating on the remote. You can do this by eg:
git branch -m master master-old git push remote :master # delete master git push remote master-old # create master-old on remote git checkout -b master some-ref # create a new local master git push remote master # create master on remote
However this has a lot of caveats. First, no existing checkouts will know about the rename - git does not attempt to track branch renames. If the new
master doesn't exist yet, git pull will error out. If the new
master has been created. the pull will attempt to merge
master-old. So it's generally a bad idea unless you have the cooperation of everyone who has checked out the repository previously.
Note: Newer versions of git will not allow you to delete the master branch remotely by default. You can override this by setting the
receive.denyDeleteCurrent configuration value to
ignore on the remote repository. Otherwise, if you're ready to create a new master right away, skip the
git push remote :master step, and pass
--force to the
git push remote master step. Note that if you're not able to change the remote's configuration, you won't be able to completely delete the master branch!
This caveat only applies to the current branch (usually the
master branch); any other branch can be deleted and recreated as above.
Change the current branch to master in git
I have two branch in my git repo:
I created "seotweaks" with the intention of quickly merging it back into master, however that was 3 months ago and the code in this branch is 13 versions ahead of "master", it has effectively become our working master branch as all the code in "master" is more or less obsolete now.
Very bad practice I know, lesson learnt.
Do you know how I can replace all of the contents of the "master" branch with those in "seotweaks"?
I could just delete everything in "master" and merge, but this does not feel like best practice.
You should be able to use the "ours" merge strategy to overwrite master with seotweaks like this:
git checkout seotweaks git merge -s ours master git checkout master git merge seotweaks
The result should be your master is now essentially seotweaks.