Install Git and use Git to manage personal documents
1.1 install Git
The latest version of Git can be found.
Before installationFirst, make sure that the corresponding dependency package has been installed, mainly including the following:
Zlib
Libcurl
Libcrypto (OpenSSL)
Rsync (2.6.0 or later)
After these conditions are met, you can install Git:
1. tar-xzvf git-1.6.1.tar.gz
2. cd git-1.6.1
3../configure -- prefix =/usr/local
4. make
5. make install
If the installation is successful, you can view the version through git -- vertion.
1.2 project warehouse Establishment(Git init)
To use Git to control the version of an existing document, you must first create a project repository based on the existing document. It is easy to create a Git project repository. You only need to use the git-init-db command.
$ Mkdir project
$ Cd project
$ Git-init-dbgit will respond to the following:
Defaulting to local storage area
Or Initialized empty Git repository in project/. git/
In this way, an empty version library is created and a subdirectory named. git is created in the current directory. You can use ls-a to check the content and pay attention to the following three items:
A file named HEAD. Let's check its content now:
$ Cat. git/HEAD the current HEAD content should be like this:
Ref: refs/heads/master
We can see that the content in the HEAD file only contains an index information, and this index will always point to the current development branch in your project.
A subdirectory named objects contains all objects in your project. We do not need to know the content of these objects directly. We should be concerned about the data of projects stored in these objects.
In addition, the project directory is no longer a common document directory. We will call it a work tree in the future. Because we are mainly the development of Linux kernel, so the example below is mainly the operation of the kernel file, so the project directory is equivalent to the source code root directory, that is, the linux-2.6-vertex.
Some documents in the work tree should be stored in the Git repository selectively below. Since Git does not simply copy documents to a repository, it is necessary to process the added documents and generate the data format acceptable to the Git repository, git calls this process "take a snapshot (" to generate a snapshot ). To generate a snapshot of all documents (including subdirectories) under the Work tree, run the following command:
$ Cd project
$ Git add.
The snapshot is stored in a temporary storage area, which is called an index by Git. You can use the git-commit command to submit the index to the repository. This process is called commit. Each commit means that the version is being updated.
$ Git commit
When you execute the above git-commit command, Git will automatically call the system's default text editor, requiring you to enter version update instructions and save them. Remember, it is necessary to enter a simple and meaningful version update description to help you quickly recall major changes to the project.
For brief version updates, you can use the "-m" option of git-commit as follows:
$ Git commit-m "your version update information"
The git-commit command will be explained in detail later.
The above process is a general process of building a Git repository. I will summarize the process as shown in Figure 1.1:
Figure 1.1 Git repository creation process
In addition, pay attention to the following two issues during git project repository creation:
The first problem is that you need to introduce yourself to Git before using Git. Git does not like people who do not want to reveal their names, because it requires everyone to assume certain responsibilities when submitting data to the repository. To introduce yourself to Git, run the following command:
$ Git config -- global user. name "Your Name Comes Here"
$ Git config -- global user. email you@pub.admon.org
The second problem is that when you generate a snapshot of the document content, some documents in the work tree are not managed by Git, such as intermediate files generated during program compilation, how can I avoid generating snapshots for such files?
For example, the following sub-directories exist in the work tree:
Doc tmp ipc drivers fs
The tmp directory stores the intermediate files generated during document compilation. Therefore, this directory should not be managed by Git. To solve this problem, Git provides a document ignore mechanism to write the document information you do not want to accept Git management in the work tree to the. gitignore file in the same directory. For the tmp directory in this example, you can exclude it from the warehouse by using the following operations, and then generate a snapshot for the project.
$ Cd project
$ Echo "tmp">. gitignore
$ Git add.
For details about the gitignore file, refer to its user manual:
$ Man gitignore
1.3 project warehouse and work tree
As mentioned above, Git repository is the one. the git directory stores the submitted document index content. Git can track the content of the documents it manages based on the document index content to achieve document version control. The work tree is a directory containing. git, which is the project directory in the previous example.
To better understand the concept of a repository and a work tree, we will do the following experiment:
$ Cp-R project/. git/tmp/test. git
$ Cd/tmp
$ Git clone test. git test-copy
First, copy the. git directory in the project directory to the/tmp directory and rename it to test. git. Then, use the git-clone command to generate the test-copy directory from test. git. If you enter the test-copy directory, you will find that the contents in this directory are equivalent to the project directory.
The above experiment means that as long as we have a repository, that is, test. git, you can easily generate a work tree, which contains a repository, namely test-copy /. git. Therefore, we can understand that in Git, there is no need to clearly distinguish between the repository and the work tree.
1.4 File Operations
In the work tree, our daily work is nothing more than modifying the documents managed by the Git repository or adding/deleting some files. There is no difference between these operations and the use of Git to manage our documents, but remember to notify Git when you think that a work phase is complete and command it to write down your updates, this step is achieved by generating a document snapshot and adding it to the index. The following is an example.
For example, if I add a new file fs/binfmt_hwt.c to the project directory, I need to notify Git to remember my update:
$ Cd project
$ Git add fs/binfmt_hwt.c
In this way, Git will add updates related to fs/binfmt_hwt.c to the index. Then I made some modifications to other documents, such as modifying ipc/msg. c, and continue to use the git-add command to add their updates to the index:
$ Git add ipc/msg. c
You can also use the following command:
$ Git-update-index
In the evening, this day's work came to an end. I felt it was necessary to submit what I had done today to the repository, So I executed the git-commit operation and added the index content to the repository.
Maybe one day, you have updated many documents in the work tree (ADD, modify, and delete documents), but I forgot their names, in this case, if you add all the updates to the index, the method is:
1. The clone command of the working tree will be described in detail later.
$ Cd project
$ Git add.
$ Git commit-
... Enter the log information...
Last step-a is a general method, which I personally prefer
Git-commit-m "version information"-a, so that you do not need to operate on the version file.
The git-add command can usually determine the new documents added by the user under the current directory (including its subdirectories) and append the information to the index. The-a option of the git-commit command can submit the current status of all modified or deleted documents to the warehouse. Remember, if you only modify or delete the documents that have been managed by Git, you do not need to use the git-add command.
This section does not describe the new Git commands. It is a duplicate of some of the commands mentioned above, but they are only used in different scenarios. In addition, you should note that Git does not take the initiative to record your updates to the document unless you give a number to it.
1.5 view version history
In the work tree, you can use the git-log command to view the logs of the current project, that is, the version update information of the instance to which you submit a new version to the repository when using git-commit.
$ Git log
To view the general changes of each version, run the following command:
$ Git log -- stat -- summary
The following analyzes the response information of the git-log command. The following are the versions I submitted after modifying the kernel. The versions are marked as first, second, and third, and the bottom one is the original version.
Each version corresponds to a project version update submission. In the project log information, the first line of each log (that is, a string of inexplicable numbers) is the name of the version update submission. We can understand this name as the project version number. The project version number should be unique. By default, it is automatically generated by Git to indicate an update of the project. If you use the project version number as a parameter of the git-show command, you can view the update details of the project version:
$ Git show version number (I will not lose if it is a long time)
In addition to using the complete version number to view the details of the project version update, you can also use the following methods:
$ Git show ddea091 # generally, only the first few characters of the version number are used.
$ Git show HEAD # display the update details of the latest version of the current Branch
Each project version number usually corresponds to a parent version number, that is, the previous version status of the project. Run the following command to view the details of the parent version update of the current project:
$ Git show HEAD ^ # view the parent version update details of the HEAD
$ Git show HEAD ^ # view the grandfather version update details of the HEAD
$ Git show HEAD ~ 4 # view the version update details of HEAD grandfather
1.6 revocation and Restoration
An important task of the version control system is to provide the function of revoking and resuming a certain stage of work.
The git-reset command is prepared for such a task. It can locate the current version of the project to any version submitted previously.
The git-reset command has three options: -- mixed, -- soft, and -- hard. We only use the first two options in our daily use. The third option is too lethal and may damage the project repository. Therefore, we need to use it with caution.
-- Mixed
It is only to reset the index position, without changing anything in your work tree (that is, all changes in the file will be retained, and they will not be marked as pending ), the system prompts that the content has not been updated. This is the default option.
-- Soft
We neither touch the index position nor change any content in the work tree. We only need to make the content a good one (and then become the real submitted content ). This option enables you to reset submitted items to the "Updated but not submitted" status. Just like you have run the git-update-index Command, but haven't run the git-commit command.
-- Hard
Switch the content and header indexes in the work tree to the specified version location, that is, all the trace content and work tree content after <commit-ish> will be lost. Therefore, this option should be used with caution unless you are very sure that you do not want to see any more. For details about how to use the git-reset command, refer to the exercises in this chapter. You can create a Git repository and submit some version updates to it, and then test the effects of the -- mixed and -- soft options.
To view the impact of the git-reset command on the work tree, use the git-status Command. This is the key point and difficulty in our work!
1.7 Git command details
Branch Management: git-branch
Until now, our project version library has only one master branch. The cost of creating branches in the git version library is almost zero, so you do not have to create several more branches. The following lists some common branch policies for your reference only:
Create a Personal Work Branch to avoid too much interference to the master of the master branch and facilitate communication and collaboration with others.
It is better to create a pilot branch and discard a mess when performing high-risk work.
When merging others' jobs, it is best to create a temporary branch. The tips on how to use a temporary branch to merge others' jobs will be described later.
-- Create a branch:
The following command creates my own work branch named litary and transfers future work to this branch.
$ Git-branch litary
$ Git-checkout litary
-- Delete Branch:
To delete a branch in the version library, run the git-branch-D command, for example, $ git-branch-D branch-name.
-- View Branch:
Run the following command to obtain the branch list of your current working directory:
$ Git-branch
In the front of the output branch, * is the current branch. If you forget the branch on which you are working, you can check it and run the following command to tell you:
$ Cat. git/HEAD
View development changes and differences of projects
This section describes several useful commands for viewing the development and changes of the project's version library and differences:
Git-show-branch
Git-diff
Git-whatchanged
The git-show-branch command shows the development status of each branch in the version library, and shows whether the content submitted each time has entered each branch. Let's see the development history of the version library.
For example, if you want to view the differences between the system version labeled master ^ and litary, you can use the following command: $ git-diff master ^ litary
Merge two branches: git-merge
Since we have created different branches for the project, we need to often merge the work of ourselves or others on one branch to other branches. Now let's look at how to merge the work on the litary branch into the master branch. Now transfer our current work branch to the master, and merge the work on the litary branch.
$ Git-checkout master
$ Git-merge "Merge work in litary" HEAD litary merges two branches. in addition, the following commands are equivalent to the preceding commands.
$ Git-checkout master
$ Git-pull. litary
However, a merge conflict prompt appears in git at this time. You need to modify it based on the actual situation and requirements.
