How do I switch to a new branch in the same branch without retaining the commits from the previous push?

Related searches

I cloned a repo and checkout to branch featureA. I am working on branch featureA and push two commits.

Then I switch to featureB and want to push two new commits, but the commits in featureA are part of featureB. How do I switch to a new featureB branch and start "afresh" that was the state before I pushed two commits?

Then I switch to featureB and want to push two new commits, but the commits in featureA are part of featureB. How do I switch to a new featureB branch and start "afresh" that was the state before I pushed two commits?

if you would just switch to featureB, the commits in featureA wouldn't be there. However, the thing you've probably done is that you've branched featureB from featureA, in which case the commits would be there, too. You'll need to branch from master instead. In that case featureB wouldn't know about featureA.

Switching branches is done with:

git checkout featureB

while branching from somewhere (creating new branch) can be done with, among other things,

git checkout -b featureB

So first switch to master and then branch featureB from there:

git checkout master
git checkout -b featureB

git: commit state of current code to new branch without affecting , to commit them in another branch keeping your current branch same as it was earlier. For example, assuming you made 10 small commits on your branch, but commit -m 'single commit with all my changes' git push origin master the experiment branch; git checkout - Return to your previous branch. The previous example showed the merge of a file that was uncommitted in an old branch before switching to a new branch where the merge did not have a conflict. It gets a little more exciting when there is a conflict. Let’s start over with a new example that begins the same as the previous example.

If you have merged your commits from branch featureA to master, then you have to revert your changes from master and checkout to a new branch featureB. I am assuming that you are in your master branch in your local.

1. git revert <commit ID> -m <Parent number>
2. git push origin master
3. git checkout -b featureB

Rewriting History, This can involve changing the order of the commits, changing messages or However, once you push your work, it is a different story entirely, and you should actual content of your last commit, the process works basically the same way — first git filter-branch has many pitfalls, and is no longer the recommended way to� (Create if not existing and) checkout new branch, where you want to push your commit. Select the commit from the history, which should get commited & pushed to this branch. Right click and select Cherry pick commit. Press Cherry pickbutton afterwards.

TL;DR

You want git checkout -b featureB master, or similar.

Long

One of the many things to learn about Git is that Git is not really about branches. Git is really about commits. Branches—or more precisely, branch names—are just the method by which you, and Git, find commits.

Let's draw your existing situation. Drawing a graph of the set of existing commits is a good exercise and you should do it often.

I cloned a repo ...

When you first clone some existing repository, you get all of its commits. Each commit has some big ugly hash ID, unique to that commit. Every Git repository everywhere uses the same hash ID for those specific commits.

When you do this git clone, right at the start, you don't get any of the other Git's branches. But you don't need them, because Git isn't about branches. You just need some names so that you can find the commits. So your Git takes their branch names, and saves them in your repository as your remote-tracking names, such as origin/master and origin/develop. That is, your Git remembers their branch names, as your remote-tracking names.

The last step of the git clone process is that your Git creates, in your repository, one branch name. That one branch name has to point to one of the commits you got from their Git. Which of these commits should your Git use? There are probably hundreds or thousands of commits; how will your Git pick the right one? You can tell it, but the usual default is: Use the name origin/master, which we got from the other Git repository at origin, to pick out the commit; make my new branch name master identify that same commit.

So, if they have a series of commits ending at some hash ID H, we can draw it like this:

... <-F <-G <-H   <-- master, origin/master

The last of their master commits is this hash H. (Its actual hash is some big ugly string of letters and digits—we're just using H for short.) That commit stores inside it the hash ID of some other, earlier commit, which we'll call G. Commit G stores inside it the hash ID of some other earlier commit, which we'll call F.

When you run git log, Git starts by reading the name master to find hash H. Then it shows you commit H. Then it uses commit H to find hash G, and shows you commit G. It uses that to find F, and shows you F. This repeats all the way back to the very first commit ever. That first commit doesn't point back any further, because it can't, and that's how Git knows how to stop.

... and checkout to branch featureA.

There are two possibilities here: featureA existed on origin before, or it didn't. Your own Git doesn't have a featureA yet—it only has a master—so if you run:

git checkout featureA

your own Git would normally just say I don't have a featureA. But instead of doing that, your Git will check through your origin/* names, to see if you have an origin/featureA. If so, your Git will find the commit that your origin/featureA names, and create your own new featureA, pointing to that commit.

If you don't have an origin/featureA either, then you have to tell your Git to create featureA now, using either git branch or git checkout -b. You might tell your Git: Make new name featureA, pointing to the same commit that my current branch name master points to. This gives you:

...--F--G--H  <-- master, featureA, origin/master

Now that you have two branch names (plus all the remote-tracking names origin/*), we need some way to remember which branch name your Git is using. To do that, we'll attach the special name HEAD, in all uppercase like this, to one of the two branch names.

Note that the two branch names currently both point to the same commit hash ID (H in this example)! That's perfectly fine. It just means that both branches end at commit H.

I am working on branch featureA and push two commits.

Presumably, what you mean here is that you created two new commits, then used git push to get the other Git repository, over at origin, to take your two new commits and create or update its featureA name.

Let's draw this create-two-new-commits process. We start, as we saw, with:

...--F--G--H  <-- master, featureA (HEAD), origin/master

First, you made one new commit (in the usual way). That one new commit got a new, unique hash ID, different from the hash ID of every other commit everywhere in the world.1 We'll just call it I though, and draw it in:

...--F--G--H  <-- master, origin/master
            \
             I   <-- featureA (HEAD)

Note how new commit I points back to existing commit H, and that the name featureA now points to I instead of H. No existing commit has changed! You just added a new commit, with a new hash ID, and moved the branch name. This is how branches grow, in Git.

Then you made a second new commit:

...--F--G--H  <-- master, origin/master
            \
             I--J   <-- featureA (HEAD)

Last, you used git push to send the new commits, I and J, to the other Git over at origin. You asked that Git to set, in its repository, the name featureA to point to commit J. Given that it said OK, I have done that your Git then created your origin/featureA to remember that their Git, at origin, now has a featureA:

...--F--G--H  <-- master, origin/master
            \
             I--J   <-- featureA (HEAD), origin/featureA

Then I switch to featureB and want to push two new commits, but the commits in featureA are part of featureB. How do I switch to a new featureB branch and start "afresh" that was the state before I pushed two commits?

Now that we have all these graph drawings, the answer is much clearer. We just need to create the new name featureB such that it points to existing commit H, the same one that master and origin/master name.

The two normal ways to create a new branch name are to use git branch or git checkout -b. The difference is that git branch creates the name and then stops, while git checkout -b creates the name, then does a git checkout on the name. Since you want the git checkout step as well, it makes sense to use the combined command—but let's draw it out as separate steps.

By default, both commands create the new label—the new branch name—pointing to the current commit. Git finds the current commit using the special name HEAD. If that name is attached to a branch name, as it usually is, Git follows the arrow coming out of the branch name to find the commit.

Right now, HEAD is attached to featureA, and featureA points to commit J. So if you just create a branch name with git branch featureB, the new name would point to commit J. But you'd like it to point to commit H.

You can easily tell git branch to use any existing commit. All you need is its hash ID, or any name that points to that commit. So you can run git log and find the actual hash ID of commit H and type that in—which is kind of hard to do though cut-and-paste makes it easier to get it right—or you can just use any of the names that still point to commit H, such as master or origin/master:

git branch featureB master

for instance. This produces:

...--F--G--H  <-- master, featureB, origin/master
            \
             I--J   <-- featureA (HEAD), origin/featureA

Note that HEAD is still attached to featureA, which still points to commit J.

Now that featureB exists, we can use git checkout to switch to it. This replaces your index (which we haven't mentioned here as this answer is all about branch names) and working tree (which again we haven't really mentioned here) with the contents of commit H while attaching the name HEAD to the name featureB:

...--F--G--H  <-- master, featureB (HEAD), origin/master
            \
             I--J   <-- featureA, origin/featureA

Your current commit is now H; your current branch name is now featureB; and you're ready to make new commits, which will cause featureB to advance to include the new commits you make.


1This uniqueness is why Git hash IDs are so big and ugly. They really are this unique in practice, but they really only have to be unique across all Git repositories that ever "meet each other". However, since SHA-1 is considered insecure and "broken", Git is moving to SHA-256, to help maintain this "unique across all commits on Earth and anywhere else in the solar system or galaxy in the future" promise.

How (and why!) to keep your Git commit history clean, Git commit history is very easy to mess up, here's how you can fix it! Any code that you commit today, a year from now when you look at the same change; you So to simplify the effort of maintaining concise commit history, this push their changes on a remote branch that has new commits force pushed. <branch> Branch to switch to. <new-branch> Name for the new branch. <start-point> The starting point for the new branch. Specifying a <start-point> allows you to create a branch based on some other point in history than where HEAD currently points. (Or, in the case of --detach, allows you to inspect and detach from some other point.)

Git, It is first important to note that Git does not have a traditional 'undo' system like This tutorial provides all of the necessary skills to work with previous revisions It is entirely possible that the commit you're looking for is on another branch. It remains on the same branch and same commit, avoiding a 'detached head' state. The easiest way to switch branch on Git is to use the “ git checkout ” command and specify the name of the branch you want to switch to. If the destination branch does not exist, you have to append the “ -b ” option, otherwise you won’t be able to switch to that branch. $ git checkout <existing_branch> $ git checkout -b <new_branch>

Working with Branches in Git and GitHub – The New Stack, In our previous tutorials for the git version control software, we learned with Github.com to establish a repository and push our project code to the website. If you make changes to the master branch of a group project while “–no-ff” tells git we want to retain all of the commit messages prior to the merge. This is most commonly used because it will create the branch for you from your current branch and it will switch you to that branch in a single command. You can also optionally specify a different branch from which the new one will be created: $ git checkout -b new-branch dev-branch Switched to branch 'new-branch'

That depends: If you haven't committed the change yet, you can just create a new branch (or check out another branch) right now and then commit. If there are conflicting changes in the other branch you can Stash your changes before switching, then Apply the stash again afterwards.

Comments
  • featureA is two commits ahead of the master. Did you push the two commits in featureB?
  • You can combine as well: git checkout -b featureB master.
  • Maybe for the TLDR part just add git checkout master && git checkout -b featureB which should be the same but is more transparent whats happening? Love the effort you put in here :)
  • Thank you so much, really helped me understand what's happening.