1

I am using git / github and by accident I have been committing into "master" branch instead of "4.2". I have now created a separate branch which is what "master" supposed to be, "4.1" and cherry-picked the essential commits.

Merges

I now want copy "4.1" into master to avoid the commits I've made on Nov1, 2, 3 and 7. What is the best way to do it?

I have tried to follow: Create git branch, and revert original to upstream state, but got this:

$ git push origin :master
remote: error: refusing to delete the current branch: refs/heads/master
To git@github.com:atk4/atk4.git
Community
  • 1
  • 1
romaninsh
  • 10,606
  • 4
  • 50
  • 70
  • It's on Github: https://github.com/atk4/atk4/network and there is related question: http://stackoverflow.com/questions/4759492/how-to-recreate-the-github-network-graph – romaninsh Nov 07 '11 at 16:57

2 Answers2

1

I've managed to restore by using this:

# git back to my master branch
git checkout master

# reset branch to other branch
git reset --hard 4.1

# push changes and --force to avoid rejection
git push --force origin master

enter image description here

Master is now the way it should have been. I wonder how will it affect clones who will "pull" master.

romaninsh
  • 10,606
  • 4
  • 50
  • 70
  • A pull is basically the same as a fetch and a merge. Thus, users who do a pull (and already have the broken master), will get a merge between the broken master and the fixed master. Which is likely to be something strange. You must tell them to reset to the new master, like so: `git checkout master; git fetch origin; git reset --hard origin/master`. – igorw Nov 07 '11 at 16:13
1

They will have their remote tracking branch (origin/master) pointing to a new place if they do a git fetch. If they do a git pull they will have to deal with conflicts if their work that they did not push yet (if they too were working off master). Depending on how many others were working with you on this, this may or may not be a big deal.

What they should do if they have master checked out is 'git reset --hard origin/master`. This would lose any commits they had that they did not push. They may want to branch to capture that first. Then they can rebase or merge those changes when ready.

If they are not working off the master, and they just want to update their local master branch, they can simply

git push . +origin/master:master

This saves you from having to checkout a branch to simply sync it up with the remote.

user229044
  • 232,980
  • 40
  • 330
  • 338
Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • Great info, which is difficult to come by. I might be lucky to notice it relatively soon and since users are using my stable releases, it won't affect them. Do you know how to do it otherwise? I have tried reverting but ended up with lots of conflicts. How could I have reverted all commits at once? – romaninsh Nov 07 '11 at 16:55
  • You need a good branching strategy. If you mistakenly put something out on master, an email explaining the situation is great. No matter what the tool is, good communication goes way further. Here's my branching strategy: https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR – Adam Dymitruk Nov 07 '11 at 18:24