That will leave the feature branch at the tip of the developments, while resetting main back to where it should be. Create the branch where you are, switch to the main branch, then reset -hard back a few commits. You can do something similar if you forget to use a branch when you started working on a new feature. But that's outside the scope of this article. This isn't the only way of rewriting history: there's a whole process around changing and combining commits, mainly using interactive rebases and the squash feature. If you create a new commit from here, you get all the changes for the new feature, without the complex history of the work-in-progress. The soft reset means that the Index contains all the changes in the whole branch. If you then soft reset back to the 3c67455 commit, where the main branch points, you get this situation, with feature still being the current branch. The new feature is complete, but the history of how you got there is messy.
Git change branch and reset files series#
Let's say you've been working on some feature and have created a series of commits as you've been working. Soft resets are useful when you want to collapse a sequence of commits into one.
HEAD and the current branch both point to the new commit, and the history of that commit points to 3c67455. If you now make a new commit from there, you'll end up in this position. With a mixed reset, you've not lost any work. Files in the working directory have remained the same. (Any other branches pointing at 2acad38 would remain there.) The Index has changed to mirror the contents of what is now the current commit. The current branch has also been moved back to the same commit. ( HEAD~ means "the parent of HEAD" and the mixed mode is the default, so it's assumed if you leave it out.)Īfter giving that command, the situation looks like this: After doing a mixed reset Instead, you reset HEAD back to the previous commit, 3c67455 so that you can commit from there. You could just create another commit based on the current one, but you'd prefer to keep the history a bit cleaner. You've now done some more work on that file and realised that what you did in that commit was wrong, a blind alley. You've been working on file.txt and made some changes to get to commit 2acad38. Let's say you're in the position shown below. It also updates the index and working directory (normally). Git reset moves HEAD to another branch, making it the current commit. When you make a commit, the current branch moves to the new commit and takes HEAD with it. When you switch between branches, HEAD moves to the new branch. But sometimes, you need to take control and move HEAD yourself. Normally, git updates HEAD as it goes along and it does the right thing. The current branch is the one that HEAD points to. HEAD (almost always) is a pointer to a branch, and a branch is a pointer to a commit. The result is the same as re-cloning the repository.Several times in the earlier parts, you've seen mysterious references to HEAD, the current commit. Reset to the latest commit on remote / upstream Remove all unstaged changes in my working tree.
Git change branch and reset files how to#
If you want to preserve anything for later, you can use stash: How to stash and restore an edit with gitĬonsider whether you can use a simple method to remove untracked files instead of reseting the branch. Make sure you know what changes you're about to lose.
We'll begin with the following assumptions: you have a user branch that is tracking a remote/upstream, you have local edits that you want to discard and you want to reset local to the latest remote/upstream commit. Here's a quick walkthrough to help you reset a local git branch to remote.
0 kommentar(er)
