If you can read only one chapter to get going with Git, this is it. This chapter covers every basic command you need to do the vast majority of the things you’ll eventually spend your time doing with Git. By the end of the chapter, you should be able to configure and initialize a repository, begin and stop tracking files, and stage and commit changes. I’ll also show you how to set up Git to ignore certain files and file patterns, how to undo mistakes quickly and easily, how to browse the history of your project and view changes between commits, and how to push and pull from remote repositories.
Getting a Git Repository :
You can get a Git project using two main approaches. The first takes an existing project or directory and imports it into Git. The second clones an existing Git repository from another server.
- Initializing a Repository in an Existing Directory
If you’re starting to track an existing project in Git, you need to go to the project’s directory and type :
This command creates a new subdirectory named .git that contains all of your necessary repository files—a Git repository skeleton. At this point, nothing in your project is tracked yet. (See Chapter 9 for more information about exactly what files are contained in the .git directory you just created.)
If you want to start version-controlling existing files (as opposed to an empty directory), you should probably begin tracking those files and do an initial commit. You can accomplish that with a few git add commands that specify the files you want to track, followed by a commit:
I’ll go over what these commands do in just a minute. At this point, you have a Git repository with tracked files and an initial commit.
- Cloning an Existing Repository
If you want to get a copy of an existing Git repository—for example, a project you’d like to contribute to—the command you need is git clone. If you’re familiar with other VCS systems such as Subversion, you’ll notice that the command is clone and not checkout. This is an important distinction—Git receives a copy of nearly all data that the server has. Every version of every file for the history of the project is pulled down when you run git clone. In fact, if your server disk gets corrupted, you can use any of the clones on any client to set the server back to the state it was in when it was cloned (you may lose some server-side hooks and such, but all the versioned data would be there—see Chapter 4 for more details).
You clone a repository with git clone [url]. For example, if you want to clone the Ruby Git library called Grit, you can do so like this :
That creates a directory named grit, initializes a .git directory inside it, pulls down all the data for that repository, and checks out a working copy of the latest version. If you go into the new grit directory, you’ll see the project files in there, ready to be worked on or used. If you want to clone the repository into a directory named something other than grit, you can specify that as the next command-line option :
This command does the same thing as the previous one, but the target directory is called mygrit.
Recording Changes to the Repository :
You have a bona fide Git repository and a checkout or working copy of the files for that project. You need to make some changes and commit snapshots of those changes into your repository each time the project reaches a state you want to record.
Remember that each file in your working directory can be in one of two states: tracked or untracked. Tracked files are files that were in the last snapshot; they can beunmodified, modified, or staged. Untracked files are everything else—any files in your working directory that weren’t in your last snapshot and aren’t in your staging area. When you first clone a repository, all of your files will be tracked and unmodified because you just checked them out and haven’t edited anything.
As you edit files, Git sees them as modified, because you’ve changed them since your last commit. You stage these modified files and then commit all your staged changes, and the cycle repeats. This lifecycle is illustrated in Figure 2-1.
- Checking the Status of Your Files
The tool you use to determine which files are in which state is the git status command. If you run this command after a clone, you should see something like this :
This means you have a clean working directory—in other words, there are no tracked and modified files. Git also doesn’t see any untracked files, or they would be listed here. Finally, the command tells you which branch you’re on. For now, that is always master, which is the default; you won’t worry about it here. The next chapter will go over branches and references in detail.
Let’s say you add a new file to your project, a simple TEST file. If the file didn’t exist before, and you run git status, you see your untracked file like so :
You can see that your new TEST file is untracked, because it’s under the “Untracked files” heading in your status output. Untracked basically means that Git sees a file you didn’t have in the previous snapshot (commit); Git won’t start including it in your commit snapshots until you explicitly tell it to do so. It does this so you don’t accidentally begin including generated binary files or other files that you didn’t mean to include.
- Tracking New Files
In order to begin tracking a new file, you use the command git add. To begin tracking the TEST file, you can run this :
If you run the git status command again, you can see that your TEST file is now tracked and staged :
You can tell that it’s staged because it’s under the “Changes to be committed” heading. If you commit at this point, the version of the file at the time you ran git add is what will be in the historical snapshot. You may recall that when you ran git init earlier, you then ran git add (files)—that was to begin tracking files in your directory. Thegit add command takes a path name for either a file or a directory; if it’s a directory, the command adds all the files in that directory recursively.
- Staging Modified Files :
Let’s change a file that was already tracked. If you change a previously tracked file called README and then run the git status command again, you get something that looks like this :
The README file appears under a section named "Changed but not updated"—which means that a file that is tracked has been modified in the working directory but not yet staged. To stage it, you run the git add command (it’s a multipurpose command—you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved). Let’s run git add now to stage the README file, and then run git status again :
Both files are staged and will go into your next commit. At this point, suppose you remember one little change that you want to make in README before you commit it. You open it again and make that change, and you’re ready to commit. However, let’s run git status one more time :
What the heck? Now README is listed as both staged and unstaged. How is that possible? It turns out that Git stages a file exactly as it is when you run the git addcommand. If you commit now, the version of README as it was when you last ran the git add command is how it will go into the commit, not the version of the file as it looks in your working directory when you run git commit. If you modify a file after you run git add, you have to run git add again to stage the latest version of the file.
- Ignoring Files
Often, you’ll have a class of files that you don’t want Git to automatically add or even show you as being untracked. These are generally automatically generated files such as log files or files produced by your build system. In such cases, you can create a file named .gitignore listing patterns to match them. Here is an example of it :
The first line tells Git to ignore any files ending in .a or .o—object and archive files that may be the product of building your code. The second line tells Git to ignore all files that end with a tilde (~), which is used by many text editors, such as Emacs, to mark temporary files. Setting up a .gitignore file before you get going is generally a good idea so you don’t accidentally commit files that you really don’t want in your Git repository. The rules for the patterns you can put in the .gitignore file are as follows :
Glob patterns are like simplified regular expressions that shells use. Here is another example .gitignore file :
- Viewing Your Staged and Unstaged Changes
If the git status command is too vague for you—you want to know exactly what you changed, not just which files were changed—you can use the git diff command. I’ll cover it in more detail later; but you’ll probably use it most often to answer these two questions: What have you changed but not yet staged? And what have you staged that you are about to commit? Although git status answers those questions very generally, git diff shows you the exact lines added and removed—the patch, as it were. Let’s say you edit and stage the README file again and then edit the TEST file without staging it. To see what you’ve changed but not yet staged, type git diffwith no other arguments :
That command compares what is in your working directory with what is in your staging area. The result tells you the changes you’ve made that you haven’t yet staged. If you want to see what you’ve staged that will go into your next commit, you can use git diff --cached. (In Git versions 1.6.1 and later, you can also use git diff --staged, which may be easier to remember.) This command compares your staged changes to your last commit :
For another example, if you stage the TEST file and then edit it, you can use git diff to see the changes in the file that are staged and the changes that are unstaged :
Now you can use git diff to see what is still unstaged and git diff --cached to see what change is staged :
- Committing Your Changes
Now that your staging area is set up the way you want it, you can commit your changes. Remember that anything that is still unstaged—any files you have created or modified that you haven’t run git add on since you edited them—won’t go into this commit. They will stay as modified files on your disk.
In this case, the last time you ran git status , you saw that everything was staged, so you’re ready to commit your changes. The simplest way to commit is to type git commit. Doing so launches your editor of choice. (This is set by your shell’s $EDITOR environment variable—usually vim or emacs, although you can configure it with whatever you want using the git config --global core.editor command, as you saw in Chapter 1.)
The editor displays the following text (this example is a Vim screen) :
You can see that the default commit message contains the latest output of the git status command commented out and one empty line on top. You can remove these comments and type your commit message, or you can leave them there to help you remember what you’re committing. (For an even more explicit reminder of what you’ve modified, you can pass the -v option to git commit. Doing so also puts the diff of your change in the editor so you can see exactly what you did.) When you exit the editor, Git creates your commit with that commit message (with the comments and diff stripped out).
Alternatively, you can type your commit message inline with the git commit command by specifying it after a -m flag, like this :
Now you’ve created your first commit! The commit has given you some output about itself: which branch you committed to (master), what SHA-1 checksum the commit has (0ce17c6), how many files were changed, and statistics about lines added and removed in the commit.
Remember that the commit records the snapshot you set up in your staging area. Anything you didn’t stage is still sitting there modified; you can do another commit to add it to your history. Every time you perform a commit, you’re recording a snapshot of your project that you can revert to or compare to later.
- Skipping the Staging Area
Although it can be amazingly useful for crafting commits exactly how you want them, the staging area is sometimes a bit more complex than you need in your workflow. If you want to skip the staging area, Git provides a simple shortcut. Providing the -a option to the git commit command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the git add part :
- Removing Files
To remove a file from Git, you have to remove it from your tracked files (more accurately, remove it from your staging area) and then commit. The git rm command does that and also removes the file from your working directory so you don’t see it as an untracked file next time around.
If you simply remove the file from your working directory, it shows up under the "Changed but not updated" (that is, unstaged) area of your git status output :
Then, if you run git rm, it stages the file’s removal (The file will be removed from Working physically too!) :
The next time you commit, the file will be gone and no longer tracked. If you modified the file and added it to the index already, you must force the removal with the -foption. This is a safety feature to prevent accidental removal of data that hasn’t yet been recorded in a snapshot and that can’t be recovered from Git.
Another useful thing you may want to do is to keep the file in your working tree but remove it from your staging area. In other words, you may want to keep the file on your hard drive but not have Git track it anymore. This is particularly useful if you forgot to add something to your .gitignore file and accidentally added it, like a large log file or a bunch of .a compiled files. To do this, use the --cached option :
- Moving Files
Unlike many other VCS systems, Git doesn’t explicitly track file movement. If you rename a file in Git, no metadata is stored in Git that tells it you renamed the file. However, Git is pretty smart about figuring that out after the fact—you’ll deal with detecting file movement a bit later.
Thus it’s a bit confusing that Git has a mv command. If you want to rename a file in Git, you can run something like :
and it works fine. In fact, if you run something like this and look at the status, you’ll see that Git considers it a renamed file :
However, this is equivalent to running something like this :
Git figures out that it’s a rename implicitly, so it doesn’t matter if you rename a file that way or with the mv command. The only real difference is that mv is one command instead of three—it’s a convenience function. More important, you can use any tool you like to rename a file, and address the add/rm later, before you commit.
沒有留言:
張貼留言