When we use git add, we add files (or changes within files) to the staging area. We will use these terms interchangeably throughout this post. Both of these terms refer to the same thing, and they are used often in git’s documentation. Instead, changes are first registered in something called the index, or the staging area. Yet, git does not commit changes from the working tree directly into the repository. Let’s create a file in the working dir and run git status:
Git reset branch to origin archive#
A repository ( repo for short) is a collection of commits, each of which is an archive of what the project’s working tree looked like at a past date, whether on our machine or someone else’s. git.Īfter we make some changes, we want to record them in our repository. It contains the folders and files of our project, and also a directory called.
Git reset branch to origin code#
When we work on our source code we work from a working dir - any directory on our file system which has a repository associated with it. If you would like an even deeper explanation, see this previous post. If you are confident about these terms, feel free to skip to the next section. Specifically, I mean the working dir, the index, and the repository. In order to understand the inner mechanisms of git reset, it is important to understand the process of recording changes within git . ? Common grounds- working dir, index and repository We will get to understand what git reset does behind the scenes, and then apply this knowledge to solve various scenarios. In this post, I would like to bridge this gap and elaborate on the git reset command. How do we apply our knowledge of git’s internals and use it to fix problems we’ve gotten ourselves into?
While understanding the internals of git is useful, getting the theory is almost never enough. In a previous post, I provided a visual intro to Git internals. When provided with a set of commands , what does each command do? And how did you get to these commands in the first place? There are many online resources about git, and some of them ( like this one) actually focus on what happens in these undesired scenarios.īut I always felt these resources were lacking the “ why” . Perhaps we committed something that we didn’t mean to. Perhaps we have committed to the wrong branch. But sometimes, and way more often than we might want, things go wrong. We use git all the time, and usually it helps us get the work done. Over time, I kind-of became “the Git guy”. And it has happened not only when I was teaching students, but also while working with experienced developers. Someone calls my name for help when something goes wrong with git. Does this sound familiar? “Help! I committed to the wrong branch!” “It happened again… Where is my commit?”
0 kommentar(er)
