Git in the second: Git basics

Original: "Pro Git"

Git Basics

After reading this chapter you can get started with git (bole online Note: If you don't know git yet, it's recommended to start with the first article in this git series). This chapter introduces some of the most basic, and most commonly used, Git commands that are used in most of the time. After reading this chapter, you can initialize a new code repository, do some appropriate configuration, start or stop tracking some files, and stage or commit some updates. We'll also show you how to get Git to ignore certain files, or files with names that match a particular pattern, how to quickly and easily undo small mistakes, how to navigate the update history of a project, see the difference between a two update, and how to pull data down or push data from a remote repository.

2.1 Get the project Git repository

There are two ways to get the Git project warehouse. The first is to create a new Git repository in the existing directory by importing all the files. The second is to clone a new mirrored repository from an existing Git repository.

initializing a new warehouse in the working directory

To start using Git for an existing project, just go to the directory where the project is located and execute:

1	$ git init

After initialization, a directory named. Git appears in the current directory, and all of the data and resources that git needs are stored in this directory. At the moment, however, all of the files and directories are initialized in accordance with the existing structural framework, but we have not started to track any of the files in the management project. (In the Nineth chapter we will explain in detail what files are in the. git directory that you just created, and what the roles are.) ）

If there are several files in the current directory that you want to include in version control, you need to first tell Git to start tracking the files with the git add command and then commit:

1 2 3

$ git add *.c $ git add README $ git commit-m ' initial project version '

We will explain the meaning of each order in a moment. But now you've got a Git repository that actually maintains several files.

cloning from an existing warehouse

If you want to work on an open source project, you can first copy the Git repository for that project, which requires a git clone command. If you are familiar with other VCS such as Subversion, you may have noticed that clone is used instead of checkout. This is a very important difference, and Git collects all the data from the project history (each version of each file), and there are local data clones on the server. In fact, even if the server's disk fails, any cloned client can rebuild the repository on the server and go back to the original state of the clone (although some server-side hook settings may be lost, all versions of the data are still there, please refer to Chapter fourth for details). GitHub

The command format for the clone repository is git clone [url]. For example, to clone the Ruby language Git code repository Grit, you can use the following command:

1	$ git clone git://github. Com/schacon/grit. Git

This creates a directory named "Grit" under the current directory, which contains a. git directory that holds all the downloaded version records and then extracts the latest version of the file copy. If you enter this new grit directory, you will see that all the files in the project are already inside, ready for follow-up development and use. If you want to define a new project directory name when you are cloning, you can specify a new name at the end of the command above:

1	$ git clone git://github. Com/schacon/grit. Git mygrit

The only difference is that the new catalog is now Mygrit, and the rest is the same as the top.

Git supports many data transfer protocols. The previous example uses the GIT://protocol, but you can also use HTTP (s)://or User@server:/path.git to represent the SSH Transfer protocol. In the fourth chapter we will detail how all these protocols are used on the server side, and the pros and cons between the various ways.

2.2 Record each update to the warehouse

Now we have a Git repository with a real project in hand and a working copy of all the files from this repository. Next, make some changes to these files and submit this update to the warehouse after completing a phase goal.

Keep in mind that all the files under the working directory are the same in both states: tracked or not tracked. Tracked files are files that are already included in version control management, have their records in the last snapshot, and after a period of work, their status may not be updated, modified, or put into staging area. All other files belong to the files that are not tracked. They have neither the snapshot at the time of the last update nor the current staging area. When a warehouse is first cloned, all files in the working directory belong to the tracked file and the status is unmodified.

After editing some files, Git marks the files as modified. We progressively put these modified files into the staging area until we finally commit all of the files that were staged at once, so repeat. So the file state change cycle when using Git is shown in Figure 2-1.

Figure 2-1. The state change period of a file

Check the current file status

To determine which files are currently in what state, you can use the git status command. If you execute this command immediately after you clone the warehouse, you will see output similar to this:

1	$ git status # on branch Master No to commit (working directory clean)

This means your current working directory is quite clean. In other words, there are currently no tracked files, and no files have changed since the last commit. In addition, the above information indicates that no new files are in the current directory that are not being tracked, or Git will be listed here. Finally, the command also shows that the current branch is master, which is the default branch name, which is actually modifiable and is not considered at this time. In the next chapter we will discuss the branches and references in detail.

Now let's use vim to edit a new file README, save exit after running Git status will see the file appears in the list of non-tracked files:

1 2 3 4 5 6 7 8 9 10

$ vim README $ git status # on branch Master # untracked files: # (use "git add ..." to include Committed) # # README added to commit but untracked files present (use "Git add" to track)

is under the line "untracked files". Git doesn't automatically include it in the tracking range unless you tell it plainly that "I need to track the file", so you don't have to worry about putting temporary files and stuff into version management. However, in the present case, we do want to follow the management README file.

track new Files

Use the command git add to start tracking a new file. So, to trace the README file, run:

1	$ git Add README

Run the git status command again, and you'll see that the README file is tracked and in a staged state:

1 2 3 4 5 6 7 8 9

$ git status # on branch Master # changes to being committed: # (use "Git reset HEAD ..." to Unstage) # # New Fil E:readme #

As long as the "changes to be committed" line below, it means that the state is staged. If committed at this time, then the version of the file will be retained in the history at this moment. You might recall that before we used git init, we ran the git add command and started tracking the files in the current directory. After git add, you can indicate the path of the file or directory you want to track. If it is a directory, it means to recursively track all files in that directory. In fact, the subtext of git add is to put the target file snapshot into the staging area, that is, the add file into staged areas, while the files that have not been tracked are marked as needing tracking. This is a good way to understand the actual meaning of the subsequent add operation. ）

Staging modified Files

Now that we have modified the previously tracked file benchmarks.rb and run the status command again, we will see a status report like this:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

$ git status # on branch Master # changes to being committed: # (use "Git reset HEAD ..." to Unstage) # # New Fil    E:readme # # Changed but not updated: # (use "git add ..." To update what'll be committed) # # Modified: BENCHMARKS.RB #

The file benchmarks.rb appears below the "Changed but not updated" line, stating that the contents of the tracked file have changed, but have not yet been placed in the staging area. To stage this update, you need to run the git add command (this is a multi-function command, depending on the status of the target file, this command is also different: you can use it to start tracking new files, or to put the tracked files to staging area, but also for the merge when the conflicting files are marked as resolved state, etc.). Now let's run git add and put benchmarks.rb into staging area, and then look at the output of git status:

1 2 3 4 5 6 7 8 9 10 11

$ git add benchmarks.rb $ git status # on branch Master # changes to being committed: # (use "Git reset HEAD ..." t o unstage) # # New File:readme # modified:benchmarks.rb #

Now two files have been staged and will be recorded to the warehouse the next time they are submitted. Suppose at this point, you want to add a note in the BENCHMARKS.RB, re-edit the disk, ready to submit. But wait a second, run Git status to see:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

$ vim benchmarks.rb $ git status # on branch Master # changes to being committed: # (use "Git reset HEAD ..." to UN Stage) # # New File:readme # modified:benchmarks.rb # # Changed but not updated: # (use "Git add ..." To update what'll be committed) # # MODIFIED:BENCHMARKS.RB #

What's going on. BENCHMARKS.RB file has occurred two times. How is it possible that one count is not staged and one count has been staged? Well, actually git just saves the version of the git add command when you run it, and if you commit now, you commit the version before you add the comment, not the version in the current working directory. So, after running git add and making a revised file, you need to rerun git add to re-save the latest version:

1 2 3 4 5 6 7 8 9 10 11

$ git add benchmarks.rb $ git status # on branch Master # changes to being committed: # (use "Git reset HEAD ..." t o unstage) # # New File:readme # modified:benchmarks.rb #

Ignore some files

In general, we always have some files that don't need to be managed by Git and don't want them to always appear in the list of non-tracked files. These are usually auto-generated files, such as log files, or temporary files created during compilation. We can create a file named. Gitignore, which lists the file modes to ignore. Take a look at a practical example:

1	$ cat. Gitignore *. [OA] *~

The first line tells Git to ignore all files ending with. O or. A. Generally such object files and archive files are present during compilation, and we do not need to track their versions. The second line tells Git to ignore all files that end with a tilde (~), and many text-editing software (such as Emacs) saves the copy with such a file name. In addition, you may also need to ignore log,tmp or PID directories, as well as automatically generated documents, and so on. Get into the habit of setting up a. gitignore file in the beginning to avoid submitting such useless files in the future.

The format specification for file. Gitignore is as follows:

All empty lines or lines that start with the comment symbol # are ignored by Git.

You can use the standard glob pattern matching. * The match pattern is followed by a backslash (/) to indicate that the directory is to be ignored. * to ignore files or directories other than the specified pattern, you can add an exclamation point (!) in front of the pattern to reverse it.

The so-called glob pattern refers to the simplified regular expression used by the shell. The asterisk (*) matches 0 or more arbitrary characters, and [ABC] matches any character in square brackets (this example either matches a, matches a B, or matches a C); The question mark (?) matches only one arbitrary character; If you use a dash to separate two characters in square brackets, Indicates that all of the two character ranges can be matched (for example [0-9] to match all numbers from 0 to 9).

Let's look at another example of a. gitignore file:

1 2 3 4 5 6

# This is a comment – will be ignored by Git *.A # ignores all. A end-of-file!LIB.A # but LIB.A except/todo # simply ignores the TODO file under the project root, not including Subdir/todo build/ # ignores all files under the build/directory Doc/*.txt # ignores doc/notes.txt but does not include Doc/server/arch.txt

to view updates that have been staged and not staged

In fact, the Git status display is relatively simple, just list the modified files, if you want to see where the specific changes, you can use the git diff command. We'll cover git diff in more detail later, but now it can answer two of our questions: What updates are currently not staged. What updates have been staged and ready for the next commit. Git diff displays the specific rows added and deleted using the file patch format.

If you modify the README file again after staging, and then edit the benchmarks.rb file, do not staged, run the status command, you will see:

1 2 3 4 5 6 7 8 9