Considering some limitations of CVs, I recently launched git with my colleagues at the company. In fact, the implementation of SVN may be much less difficult. However, Lark said that since a new version management tool is introduced, it takes some time for training, deployment, and conversion. The implementation of git and SVN is not as costly as you think. Therefore, it is better to spend more time implementing git to bring more benefits. This idea convinced me. Then we started preparations. I found that many git tutorials on the Internet are not clear enough about some basic commands (such as Git-reset. In addition, we will introduce git1.5 and git1.4. In addition, there are few articles about Git-based cooperative development. Therefore, I decided to write a tutorial to reduce the training cost of promoting git in the company. In fact, I am also a beginner in git. This tutorial is also a process for me to learn and explore git myself. The mode of Git-based cooperative development refers to CVS, which should be a very basic mode of cooperation. However, you can only perform this step. All the instructions in this tutorial are verified by yourself. At least it can meet the company's basic cooperative development requirements. After completing the tutorial, Xie Xin said that he could share it with you on his blog. I think it's a good idea. On the one hand, I think this document should help git beginners, and on the other hand, I also welcome the guidance of git's experts. Thanks to the author of the GIT Chinese tutorial. In addition, the advantages of git in the overview copy the original words of a Daniel on the network, but the source of the copy is also reprinted. Here, thank you for the unknown Daniel. Next we will start. 1. Overview
For software version management tools, cool news decided to abandon CVs and turn to git.
Why git? When you actually learn to use git, you will feel that the answer to this question is very natural. However, when you really need to use text to answer the question, it seems that the text is not that adequate. Hi, what should I do?
In fact, the key question is not how to answer this question. The key to the problem is that the company has decided to use it. So, our programmers! Start your browser, and use your search engine tool to discover the answer. Here, I can only give you one of the most obscure feelings.
Unlike CVs and Svn, git is a distributed source code management tool. The Linux kernel code is managed by git. It is very strong and fast. Its direct benefits include:
1. the initialization of dummies will be finished, git init, git commit-. For anyone who writes two lines of code to the code management tool, it is not suitable. You can also use git as a backup system or synchronize the documents of the two machines.
2. Most of the operations are done locally, without interacting with the code management server in the cluster, and finally you can boldly check in code anytime and anywhere. Only the final version must be submitted to a centralized code management server.
3. Each commit creates a unique commit ID for all codes. Unlike CVs, the version of a single file is changed separately. Therefore, you can check all the code before a certain submission at a time without considering the files submitted. (SVN can also do this)
4. branch management is much easier. No redundant directories need to be created, either by creating a new branch or by switching between branch.
5. When branch is merge, not only will the code be merge together, but the check in history will be retained, which is very important.
6 .... Too many
Of course, git will also bring us some difficulties. First, if you want to use git well, you must really understand its principles and concepts. For those who are familiar with CVS, it is especially important to change the concept of pure centralized source code management, which may also make you feel a little difficult. You may feel a little difficult at the beginning of using git, but you will definitely like it when you get to know it. It must be, just as I asked you, "I like a gentle, unfeeling housewife, or a cool-running, so that you love a cool-eyed lover.
Next, let's start learning git...
Keep in mind that this is a very simple and basic tutorial. To become a git expert, you need to constantly explore it yourself.
2. Git basic commands 2.1 create a git library-Git-init
Have you ever created a CVS database? Few operations should have been performed, right? Because many people use the checkout code from the CVS library. Similarly, in cooperative development, if you are not the initiator of a code module, you will not use this command. More are using Git-clone (see section 2.7 ). However, if you want to develop a small module and manage it with code management tools for the time being (in fact, I often do this, at least many personal development processes can be preserved, it is easy and convenient to create a git library.
For Cool News, when a git library of code is created, a code file will be added to the library, and the library will be placed on the company's server dedicated for code management, so that you can clone it later (do not understand? It doesn't matter. You can see it later. For individuals, you can place this library wherever you like, as long as you can access it. It is easy and convenient to create a git library. You only need to use the git-init command. For versions earlier than git1.4 (including git1.4), this command is Git-init.
A) $ mkdir dir
B) $ CD dir
C) $ Git-init
In this way, an empty version library is created and a subdirectory named. Git is created in the current directory. In the future, the file change information will be saved to this directory. Unlike CVs, a nasty CVS directory will be created under each directory and subdirectory.
There is a config file in the. Git directory. You need to add your personal information before using it. Otherwise, we cannot add or modify any files.
The original config file is like this,
[Core]
Repositoryformatversion = 0
Filemode = true
Bare = false
Logallrefupdates = true
We need to join
[User]
Name = xxx
Emai = xxx@kuxun.cn
Now a git version library has been created, but it is empty and cannot do anything. The next step is how to add files to the version library. If you want to ignore some files, you need to add the. gitignore file under the GIT root directory.
2.2 An Important Command-Git-Update-Index
Before introducing how to add files to the GIT library, you have to introduce the git-Update-Index Command. This command may cause many users familiar with CVS to be confused. Generally, code changes submitted to a source code management library are abstracted into the following actions: Change files; submit the changes to the source code management system identity. For example, to delete an object from a CVS database, you need to delete the object first, then CVS Delete; and finally CVS commit.
Therefore, Git-Update-index is an abstract operation that changes the identity file of the source code management system. In brief, the git-Update-Index Command notifies the GIT database that the status of files has changed (new addition, modification, and deletion wait ). This command was frequently used in earlier git versions. The new git version (version 1.5 and later) has been packaged by other commands and is not recommended.
The most common methods of Git-Update-index are as follows. For more functions, see man Git-Update-index.
Method 1: Git-Update-index -- add file name list. If the file exists, this command identifies the file changes to the GIT Library (whether or not the file has been modified). If the file does not exist, this command indicates to the GIT library that a new file needs to be added.
Method 2: Git-Update-index -- force-Remove file name list. This indicates that files are deleted from the GIT repository. Whether the file has been deleted or not, this command only notifies the GIT library to delete the files from the library. These files are not affected.
Therefore, Git-Update-index only serves as a notification and identifier for the GIT library, and does not operate on specific files.
2.3 add or delete files to or from the GIT repository-Git-add and git-rm
In fact, it is wrong to use the git-add command to add files to the GIT repository, or at least completely. The essence of the git-add command is a package of the "Git-Update-index -- add" command. Therefore, in addition to adding files, Git-add can also identify file modifications. The commit operation can be performed only after Git-add is called. The same is true for Git-rm. It is a package of Git-Update-index -- force-Remove.
For Git-add, if Git-add * is called in a directory, all files in the subdirectory are recursively added to the GIT library by default. The same is true for Git-RM. This is a big difference from CVS.
In addition, you can run the git-ls-files command to view the files in the current git library. 2.4 check the version database status-Git-status
With this command, we can view the status of the version library. We can see that those files have changed and those files have not been added to the GIT library. We recommend that you use this command to check the database status before each commit operation. To avoid misoperation.
In general, the most common misoperation is that a file has been modified, And the commit operation is called directly without calling Git-add to notify the GIT library that the file has changed, as a result, the file is not actually submitted. If the developer thinks that the file has been submitted and continues to modify or even delete the file, the modified content is not managed by version. If you use Git-status to view the error before each commit, you can find this error. Therefore, if you call the git-STATUS Command, pay special attention to the files that prompt "changed but not updated. These files are all changed compared with the previous commit, but they are not identified by Git-add.
2.5 submit changes to the version library-Git-commit
Directly call the git-commit command and you will be prompted to enter a comment. You can also enter the submit comment in the command line as follows: Git-commit-M "Initial commit of gittutor reposistory ". Note: Unlike CVs, The commit comments of git must not be empty. Otherwise, the submission fails.
Git-commit also has a-a parameter that can be forcibly submitted without any changes identified by Git-Add. However, this method is not recommended.
For each commit, Git creates a unique commit ID code for the global code. You can use the git-revert command to restore the code at any commit. This is much easier to manage than different versions of CVS files. (Similar to SVN)
If you want to see the file changes before submitting the command, you can use Git-diff to view the changes. However, the output of this command is unfriendly. Therefore, we recommend that you use other tools to implement this function. After submission, you can also run the git-log command to view the submission records.
2.6 branch management-Git-branch
We ushered in the most powerful git, which is also more powerful than CVs and svn-branch management.
Every programmer may often encounter this situation:
1. You need to immediately put down your work, modify the bug of a previous version, and launch it online.
2. I wanted to make an important modification to the central database commit, but because I had to back up the code frequently, I had to commit it frequently to the central database. As a result, a large amount of useless commit information is retained in the central database.
3. Submit a change to a colleague for code review. However, the Code Review of the colleague is slow. When feedback is received, the Code has changed, which is difficult to merge.
If we use CVs or SVN to solve these scenarios, though they may not be able to solve them, they are complicated and complicated. It is certainly a sense that everyone else might feel worse! The key is that the branch management of CVs or SNV is too complex and basically unavailable.
The cost of creating branches in the GIT version library is almost zero, so you do not have to create several more branches. When Git-init is executed for the first time, the system creates a branch named "master. Other branches are created manually. The following lists some common branch policies that will facilitate your daily development.
1. Create a Personal Work Branch to avoid too much interference to the master of the master branch and facilitate communication and collaboration with others.
2. When performing high-risk work, it is better to create a pilot branch and discard a mess than to clean it up.
3. when merging other people's work, it is best to create a temporary branch for merging. After the merge is completed, "fatch" is added to your own branch (the merging and fatch are described later, if you don't understand it, continue reading it)
2.6.1 view branch-Git-branch
Call Git-branch to view the existing branches and current branches in the program.
2.6.2 create branch-Git-branch name
To create a branch, use the following method:
1. Git-branch name
2. Git-checout-B branch name
In the first method, although a branch is created, the current working branch is not switched to the new branch. Therefore, you also need to run the "Git-checkout branch name" command to switch, the second method not only creates a branch, but also switches the current working branch to the branch.
In addition, note that the branch name may be duplicated. For example, I have created two Branches A and B under the master branch, and then switched to the B branch, branch A and Branch C are created under branch B. This operation can be performed. In this case, branch a and branch A under the master are actually two different branches. Therefore, it is not recommended to perform this operation in actual use, which may lead to naming doubts.
2.6.3 Delete branch-Git-branch-d
The git-branch-D branch name can be used to delete a branch, but be careful that after the branch is deleted, all changes that occur in the branch cannot be recovered.
2.6.4 switch branch-Git-checkout branch name
If the Branch already exists, you can use the git-checkout branch name to switch the working branch to the branch name.
2.6.5 view branch history-Git-show-branch
You can call this command to view the historical changes of a branch. For example:
* [Dev1] D2
! [Master] m2
--
* [Dev1] D2
* [Dev1 ^] d1
* [Dev1 ~ 2] d1
* + [Master] m2
In the preceding example, the two rows above "--" indicate that there are two branches: dev1 and master, and the last commit log of the dev branch is "D2 ", the last submitted log on the master branch is m2 ". "--" Indicates the evolution history of the branch. dev1 indicates the last commit that occurred on the dev branch, dev ^ indicates the second-to-last commit on the dev branch. Dev1 ~ 2 indicates the last and third commit on the dev branch.
2.6.6 merge branch-Git-Merge
Git-merge is used as the source branch of the target branch merged by Git-merge "Some memo. For example:
Git-merge master dev1 ~ 2
If there is a conflict in the merge, git will prompt that git-merge is rarely used at present and replaced by Git-pull.
Usage: Source branch of the target branch merged by Git-pull. For example, Git-pull. dev1 ^ 2.7 remotely obtain a git repository Git-clone
As mentioned in section 2.1, if you are not the initiator of a code module, you will not use the git-init command, but rather use Git-clone. With this command, you can obtain a complete git library from the remote end and interact with the remote git through some commands.
The git-based code management organization structure usually forms a tree structure. developers generally obtain the development environment from the GIT library of the manager of a code module through Git-clone. After local iterative development, then, the module Administrator submits the code to the module administrator. The module administrator checks the submitted code and merges the code into his/her own database. The module code is submitted to the higher-level code manager.
For Cool News, the company has a central git library. during development, everyone obtains the latest code from the central Git-clone library.
Git-clone is used as follows: Git-clone [SSH: //] username @ ipaddr: path. Here, "SSH: //" is optional, and there are other obtaining methods, such as rsync. PATH is the root path of the remote git, also called repository.
After obtaining the remote git library through Git-clone, the developer information in. Git/config will not be cloned together. You still need to add developer information to the. Git/config file. In addition, developers must add their own. gitignore files.
In addition, the remote git library obtained through Git-clone only contains the current working branch of the remote git library. If you want to obtain other branch information, you need to use "Git-branch-R" to view it. If you need to obtain other remote branch code, you can run the command "Git checkout-B local branch name remote branch name", where the remote branch name is the branch name listed by Git-branch-R, it is generally like "origin/branch name. If the local branch name already exists, the "-B" parameter is not required. 2.8 obtain a git branch remotely-Git-pull
Unlike Git-clone, Git-pull can obtain the content of a branch from any git library. The usage is as follows:
Git-pull username @ ipaddr: Remote repository name remote branch name: local branch name. This command obtains a local branch of the local git library from the remote branch name of the remote git library. If the local branch name is not specified, the default pull is to the local branch.
Note that git-pull can also be used to merge branches. It works the same way as Git-merge. Therefore, if your local branch already has content, Git-pull will merge these files. If there is a conflict, an alert will be reported. 2.9 submit the local branch content to the remote branch-Git-push
Git-push and git-pull are the opposite. They submit the content of a local branch to a remote branch. Usage:
Git-push username @ ipaddr: Remote repository name local branch name: Remote branch name. This command pushes a local branch of the local git Library to the remote branch name of the remote git library. Note that git-push does not automatically Merge files. This is my test, but I am not sure if it is my use error. Therefore, if a conflict occurs during Git-push, the content of the Post-push file will be forcibly overwritten without any prompt. This is very dangerous during cooperative development.
2.10 database reversal and restoration-Git-Reset
In addition to Resetting discarded R & D code, database reversal and restoration also play an important role. For example, we cloned a code library from a remote server and submitted it back to the remote server after local development. However, the local code library has a functional commit and a commit for backup purposes during development. In short, there are a lot of useless logs in commit logs. We do not want to submit these logs to the database when they are submitted back to the remote. Therefore, Git-Reset is required.
The concept of Git-Reset is complicated. Command Format: Git-Reset [-- mixed | -- soft | -- hard] [<commit-ish>]
Command Options:
-- Mixed
This is the default option. For example, Git-Reset [-- mixed] dev1 ^ (for the definition of dev1 ^, see 2.6.5 ). It only resets the branch status to dev1 ^, but does not change the content of any working file. That is, all file changes from dev1 ^ To dev1 are retained, but all commit logs between dev1 ^ and dev1 are cleared, and, the changed file content is not identified by Git-add. If you want to re-commit the file, you also need to perform Git-add on the changed file. In this way, a very clean submission record is obtained after the commit operation.
-- Soft
It is equivalent to doing Git-reset-mixed, and then done Git-add for the changed file. If this option is used, you can directly commit it.
-- Hard
This command will cause the rollback of all information, including the file content. It is generally used only when the discarded code is reset. After execution, the file content cannot be restored. 2.11 more operations
The previous 10 sections only briefly introduced the basic commands of git. For more details, go to the man git document in Linux. In addition, http://www.linuxsir.org/main/doc/git/gittutorcn.htm also has a lot of more detailed introduction. 3. Git-based Cooperative Development
For Cool News, when we adopt git, how should we conduct cooperative development? The procedure is as follows:
3.1 get the latest code Cool will prepare a central git code library. First, we will build the compiled code modules in the GIT Central Library. Add the file to the central library. Next, the developer uses Git-clone to clone the code from the Central Library to the local development environment.
For large projects, we also recommend that you select a person in charge for each group to obtain and update the latest code from the central database, other developers clone code from the GIT code library of the owner. For developers, the GIT library of the owner is the central library. 3.2 developers perform local iterative development After you clone the code to the local machine, you can perform local iterative development. We recommend that you do not create a development branch on the master branch for development. During local development, you can create temporary branches and commit them at will. 3.3 ask other colleagues for code review When local development is complete, ask other colleagues for code review. The process is as follows:
1. through the git-pull command, user2 connects the developer's (user1) Development Branch (Dev) Pull to a local TMP branch of user2, and switches the Work Branch to the branch for code review.
2. After code review is completed, user2 switches back to its original Development Branch to continue development and notifies user1 that the modification has been completed.
3. user1 transfers the TMP branch of user2 Git-pull to the local TMP branch and performs merge with the dev branch. Finally, a Dev branch after code review is obtained.
Of course, user2 can also directly sit next to user1 and review his code. The preceding steps are not required. (Step 1 in the figure is not Git-pull, but modify directly on the dev branch and on the review side of user1) 3.4 merge code with the central database
Anyone who has used CVS knows that a CVS update is required before commit to avoid conflicts with the central database. The same is true for git.
Now we have passed the code review and are ready to submit changes to the central database. During the development period, the central database may have changed. Therefore, before submitting the changes to the central database, again, the master branch of the central database is Git-pull to the local master branch. And merge with the dev branch. Finally, the Merged Code is put into the master branch.
If too many logs are submitted during the development process, you can refer to section 2.10 for a git-reset.
In addition, if the merging process changes a lot, we recommend that you review the code again for the sake of code quality. 3.5 submit code to the central database
At this point, you are ready to submit the final code. You can use Git-push. 3.6 Cooperation Process summary
As you can see, git is used for cooperative development. This process has many similarities with CVS and enhances the following links:
1. Developers perform iterative development locally. They can perform regular commit operations without affecting others. And can be developed even if it is not online. You only need to submit it to the central database once.
2. As we all know, if CVS manages code, we often perform commit operations. However, before the commit operation, CVS update always checks the latest code in the central database. In this case, if any problem occurs, it is difficult to determine whether it is a self-developed bug or the impact of other user code. Using git avoids mutual development between users.
3. It is more conducive to code review before code submission. In the past, CVs was used for Code view only after code is submitted. If a problem occurs, you cannot avoid bad code on the server. However, if git is used, it is developed locally before it is actually committed to the central database. Code review can be easily performed before it is submitted to the central database. It is more conducive to code quality. In addition, you may feel that it is easier to review the code when using git, because there are fewer influencing factors.
4. creating multiple branches makes it easier to carry out multiple types of work in development without affecting each other. For example, when user2 review the code of user1, It is very convenient to retain the development site at that time and switch to the Code branch of user1. After the code review is complete, it can also be very convenient to switch to the work site that has been interrupted. It is true that operations are more complex than CVS while these benefits are brought. However, we feel that these troubles are worth comparing with the benefits we have gained. When you get used to it, you will find that this does not increase much complexity, and the development process will be more natural. Please try more! Experience the charm of git! Let's enjoy it! |
