Ordinarily, a commit has exactly one parent commit, namely, the previousĬommit. Local changes, Git will automatically merge, and report any conflicts. The latest version in a centralized version control system. If you have no localĬhanges, then the merge is a fast forward, a degenerate case akin to fetching The pull command in fact fetchesĬommits and then merges them into your current branch. We actually encountered merging long ago. With Git, merging is so trivial that you might be With some version control systems, creating branches is easy but merging themīack together is tough. In other words, after checking out an old state, Git automatically puts you in a new, unnamed branch, which can be named and saved with git checkout -b. Any commits made from now on take your files down a different road, which can be named later. At last we can tell the whole story: the files change to the requested state, but we must leave the master branch. We touched upon this command in an earlier chapter, when discussing loading old states. Whenever you want to return to the dirty changes, simply type: $ git checkout dirty What if you wanted to save the temporary changes after all? Easy: $ git checkout -b dirtyĪnd commit before switching back to the master branch. Observe that any uncommitted changes are carried over.
Now you can add ugly temporary code all over the place. Say you’re working on some feature, and for some reason, you need to go back three versions and temporarily put in a few print statements to see how something works. You can switch between the two versions of the file as much as you like, and commit to each independently. And if the boss decides to snoop around this directory, type: $ git checkout boss # switch to version suitable for boss' eyes Type: $ git checkout master # switch to original version of the fileĪnd hey presto! The text file is restored. It looks like we’ve just overwritten our file and committed it. $ echo "My boss is smarter than me" > myfile.txt Now type: $ git checkout -b boss # nothing seems to change after this We have created a Git repository that tracks one text file containing a certain message. In some directory: $ echo "I'm smarter than my boss" > myfile.txt Your files can morph from the last release to the experimental version to the current development version to your friend’s version and so on.Įver played one of those games where at the push of a button (“the boss key”), the screen would instantly display a spreadsheet or something? So if the boss walked in the office while you were playing the game you could quickly hide it away? This transformation can do more than merely go back or forward in history. With this magic word, the files in your directory suddenly shapeshift from one version to another. Solution: Git has a better tool for these situations that is much faster and more space-efficient than cloning: git branch. Even though Git reduces the cost of this with file sharing and hard links, the project files themselves must be recreated in their entirety in the new working directory. Distributed systems fare better, as we can clone the desired version locally.īut cloning still entails copying the whole working directory as well as the entire history up to the given point.
With centralized version control we must download a fresh working copy from the central server. Interrupting your train of thought can be detrimental to your productivity, and the more cumbersome it is to switch contexts, the greater the loss. In all cases, you must abruptly drop what you are doing and focus on a completely different task. A developer whose help you need for a key section of the project is about to leave. The deadline for aĬertain feature is moved closer. A severeīug manifests in the released version without warning. Problem: External factors inevitably necessitate context switching.
Instant branching and merging are the most lethal of Git’s killer features.