This tutorial was previously sent to the community website and now turns it on your blog:)
Description: All of the pictures in this tutorial are from pro git. All of the following actions, unless specifically stated, are based on the Linux endpoint. If you find that this article has errors, or other questions, please contact me: firstname.lastname@example.org
1. What is git
Git is a distributed version control software and source code management system (Scm,source code management) that emphasizes speed. Git was originally a management software designed by Linus Torvalds for kernel development. Since Git was launched, it has been adopted by many open source projects. Each git working directory is a repository with full history and version information, independent of the network and the central server. Git is a free open source software that complies with the GNU V2 protocol.
The word git is a clumsy, useless person in English. Linus self-deprecating said: "I am a wayward fool, so I put all my project names are very similar to me." The first one is Linux, and now it's git. The GIT help document describes git as: Clumsy content tracker (the stupid contents tracker). (translated from wiki)
Some of the historical origins of git development can be seen on this site: https://lkml.org/lkml/2005/4/6/121
2. Why use git
Smoother workflow, the development process, completely offline operation fast, git distributed architecture allows the local repository to contain all the historical version information, you can quickly switch between different versions of the elastic local branch, in SVN, you build a branch to copy the source code to another folder, and in Git , the cost of creating a branch is very small, just a command warehouse directory structure concise, with git copy a project, only in the project root to create a. Git directory, and other directories are clean content is stored in metadata, all the version information is located in the. Git directory integrity, easier to collaborate on development There are thousands of open source projects using Git for project management, and there are countless code warehouses on GitHub.
3. Git Installation and configuration
1. Install from source
Before installing, you must ensure that the following dependent packages are installed on your system: curl, zlib, OpenSSL, expat, Libiconv. If your system is Ubuntu, you can install it like this:
Apt-get Install curl-devel expat-devel gettext-devel openssl-devel zlib-devel
When all the dependencies have been resolved, you can download git source code from Http://git-scm.com/download, and then compile the installation, the following commands:
Make prefix=/usr/local All
sudo make prefix=/usr/local install
2. Installing on Linux
If your system is Linux or fedora, you can install git directly using the following command:
Yum install Git-core (Fedora)
Apt-get install Git-core (Ubuntu)
3. Installing on Windows
Although git originates from Linux, it now has the ability to use Git on Windows, except that it doesn't support Chinese, that all Chinese in Windows display question marks, and some feature bugs. So it is recommended to use Git on Linux, if you have to work on Windows, you can download the latest version of Msysgit to http://msysgit.github.com/, the installation process is similar to other Windows programs, Basically the next step is OK. Msysgit installs the Git bash and git GUI programs by default, typically with Git bash, which supports commonly used commands. If you are not familiar with the Linux command line, you can also use the Git GUI, but the functionality is limited.
b) using Git for the first time
After you install git, you need to modify some configuration to use git normally.
git configures git with the "git config" command, which has 2 options:--system,--global, and the default option, which corresponds to the 3-level configuration file on Git. The first is the/etc/gitconfig file, which corresponds to the--system, which is the global profile, which modifies this file and will affect all the users on the system, all the repositories. The second one is the/.gitconfig file in your home directory, which corresponds to the--global and modifies it to affect all of your current users ' warehouses. The third one is the. git/.gitconfig file in your warehouse, which is the default modified configuration file for Git config, and it only affects your current warehouse.
When you use Git for the first time, you need to tell your co-developers who you are and your mailbox that Git needs both when you commit. Specifically set by the following command:
git config--global user.name "Test OSS"
git config--global user.email email@example.com
Of course you can also use the--global option, but that means you have to set this up in every warehouse.
At the same time, you can also specify your editor, your diff tool:
git config--global core.editor vim
git config--global merge.tool vimdiff
You can also view your settings by using the "git config--list" command.
When you have git set up, if you want to get a repository from a git server, or submit your code to a git server (like GitHub), you might need to generate your own SSH key pair. GIT supports 4 protocols for server-side communication: git, http, ssh, and HTTPS. Git is just a read-only protocol, which means you can only get the repository from the server side, but you can't submit your own code. HTTP and HTTPS are rarely used, and most of them only support the SSH protocol and the GIT protocol.
When you communicate with the remote server via the SSH protocol, you can generate an SSH key pair using the following command:
If you do not specify a key name and storage path, it defaults to placing two asymmetric keys in your home directory under the. SSH directory, the key file default name is Id_rsa and Id_rsa.pub, which is the private key, the latter is the public key. The middle may want you to set the access key password, this can be set, can not be set, but for security reasons, it is recommended that you set an access password. Otherwise, it means that any person holding your key can use that key.
Then send your public key to the GIT repository administrator, then you can access the server through the SSH protocol, the program will automatically match the key pair, if you set an access password, you may need to enter a password.
For more information about SSH, please visit here: http://www.freebsd.org/doc/zh_CN/books/handbook/openssh.html
After these settings, you can check whether your git is working properly by getting any of the public code repositories. For example, the following:
git clone git://git2.kernel.org/pub/scm/git/git.git
4. Git repository
Git as a resource management and tracking system, if you want to host your own files on git, then first you have to let git know where you need to manage the files. For example, now I have a project, which in the test folder, I want Git to manage this project, you need to go to this directory, and then run the "Git init" command. At this point git will generate a. git hidden directory in that directory, and all of the files Git uses for versioning and content tracking are in that folder.
Files that are under Git tracking have only three states:
Modified (working directory): modified file staged (staging area): Files added to the staging region via git add Committed (git directory): via Git Commit the file to the warehouse
So, the general Git workflow might be this: modify some files, then add the files to the block, and then commit to the repository to form a version or snapshot, and then commit to the GIT server. In the middle, it may be accompanied by branch management, branch switching, undo and merge.
Some people may find it strange, why Git has a concept of staging area, directly submitted to the warehouse is not OK. In fact, this is git in order to do version control, imagine if there is no staging area, every modification of a file, will form a version, too frequent, not easy to manage. The staging area is actually the next version of the file list, and you have the freedom to control what files are submitted to the repository, which also avoids having intermediate files in one version, such as compiled files.
5. Git basic process
1. Initializing the Warehouse
There are two cases of initializing a warehouse, one is to create a project directly in an empty directory, and you can do so:
Another is to copy a warehouse from another machine, such as this:
git clone git://git2.kernel.org/pub/scm/git/git.git (remote repository)
git clone https://github.com/jquery/jquery.git (remote repository)
git clone firstname.lastname@example.org:wengpingbo/microblog.git (remote repository)
Git clone/home/oss/test.git (local repository)
The first time a repository is copied from the server, it may be slow because git has to copy all of the history and version, which is a disadvantage of git.
After copying, a working directory is generated in the current directory, named after the warehouse name. If you do not want to specify a directory, then add a directory after the above command is OK. For example, I want to put the test repository in the OSS repository: Git clone/home/oss/test.git oss
After that, you can start your work.
2. Add Files
After editing several documents, you may suddenly think of it as if the file had not been followed by Git. Git does not keep track of your files in real time, it only records the current state of the specified files in the repository when you explicitly let it record your files, and then goes back to the store. I think that's why git is stupid. This time, you need to manually add your files to the staging area:
git add filename1 filename2
If you're not bothered by one plus, you can try this:
It will add all the files in the current directory to the staging area.
3. Add a version
After you add the file, you may feel that you should create a commit.
What do you think. Is something wrong, as if this command did not jump out of a successful submission as you thought, but ran directly to the editor you specified in the configuration. Look carefully, the original is to let you give this version to do some notes, casually write something, and then save the exit is OK. If you don't want to be so troublesome, you can do this:
Git commit-m ' initial version '
Maybe you think it's too verbose to commit a commit, but there's a shortcut that lets you skip the process of adding files:
Git commit-a-m ' initial version '
When you're done, this command will add all the previously added files to this version.
Perhaps you have questions again, the previously added files are not automatically added to the next version, ask what also add this-a parameter.
In fact, the git add command simply adds the current state of the specified file to the staging area, and does not mean that once a file is added, it will always exist in each version. If you add a file and then change it, when you commit, it will only commit the state of the file when it is added, and will not commit the subsequent changes unless you add it again.
4. Push changes
After your commit, you may want to submit your code to github or other GIT servers to share with others, and you need to deal with the remote server.
If you are building a warehouse locally, by default there is no server address, if you are copied from another server warehouse, this server address will be automatically added to your warehouse, you can view:
If you enter only "Git remote", only the server-side aliases will be listed and no addresses will be listed.
A warehouse can have multiple server addresses, which means that you can copy the same repository from different people, but that doesn't disrupt your own branch, even if the names of the branches are the same. If you are now in the same branch of the same project as two other people, you find that a module is exactly what you want, and you want to merge his code into your current version, and you can do this:
git remote add code_a git://url/test.git//Add each other's address, Code_a is an alias
git fetch code_a//Copy each other's repository to local, but not merge, Git pull will automatically merge
git merge code_a/master//merge the other Master branch into its current version
After merging, you may want to submit your code to another server, you can add the server address you want to submit, and then do this:
Git push Origin Master
The above command is to submit the branch of your master to the server named origin.
5. Create and manage branches
When you do a project, you may want to write some extensibility features, or do some small experiments, but you don't want to affect your current project. At this point, you can create a branch and then write something in that branch, and when you feel bad, you can delete the branch and have no effect on your previous main branch. Or you feel that this new feature is beyond your expectations and can be merged into the main branch, when you simply turn the work back to the main branch, then merge the branches, delete the branches, and then the branch is not created. Here's how:
GIT branch test//Create a test branch
git checkout test//GO to test branch
Edit Something...commit something ...
git checkout master//go to Master Branch
git merge test//merge Test Branch
git checkout-b test2//Create Test2 branch and go to Test2 branch
git branch-d Test//Delete Test Branch
GIT branch//list of branch lists
Git branch-v//Lists branch list and current commit
The essence of Git merge is to put two versions together and then create a new commit in the current branch, and if you make a change in the same place in the same file in the two branches, then the merge will fail, and git won't automatically create a new commit, but it will stop directly. You need to manually modify these conflicting files, select one of these two branches, or rewrite this section yourself, and then manually add the files to the staging area, and then commit to OK. To see which files are conflicting, you can use Git status to view them.
6. Undo Changes
It's people who make mistakes. When you execute a command, you suddenly find yourself writing a mistake, or missing a file, what to do.
If you submit too early and forget to add some files, you can do this:
Git commit-m ' add something '
git add file1
The last command will take the most recent commit of your current staging area. If you make a commit and immediately amend, git jumps directly to the edit commit comment so you can change the comment of your last commit.
If you add a file that you shouldn't add, you can save it like this:
git Add. Add all the files in
git reset HEAD Readme//Remove the Readme file from the staging area
If you find that you have edited the wrong file and you want to restore it to the previous version, you can:
Git checkout--filename1//undo only this one file
If you feel this version sucks and want to roll back to the previous version, you can do the following:
git reset--hard head^
Head is pointed to the current version, ^ refers to the current version of the parent version, this action cannot be undone. You can change the--hard to--soft, which will only return the commit message. There is also a--mixed default option, you can refer to the official documentation to see the specific differences between the 3 options.
6. Common git commands
7. Learn about git data
"Pro git": Http://git-scm.com/book/zh
"Git Magic": http://www.csc.kth.se/utbildning/kth/kurser/DD2385/material/gitmagic.pdf
Git manual :http://git-scm.com/docs