git Tutorial and Fundamentals

This tutorial was posted on the community web site and is now transferred to your blog:

Http://oss.lzu.edu.cn/artical.php?id=16

Description: All pictures of this tutorial are from "Pro git". All of the following operations, unless specifically stated, are based on Linux terminals. If you find that this article has errors, or other questions, please contact me: wengpingbo@gmail.com

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 warehouse with full history and version information, independent of network and central servers. 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 said: "I am a wayward fool, so I put all my project name and I very similar." The first one is Linux and now it's git. "Git's help document describes git as: Clumsy content tracker (the stupid tracker). (translated from wiki)

For some of the historical origins of Git, you can look at this site: https://lkml.org/lkml/2005/4/6/121

2, why to use Git

Smoother work flow, in the development process, can be completely off-line operation fast, git distributed architecture so that the local warehouse contains all the historical version of information, you can quickly switch between different versions of the flexible local branch, in SVN, you build a branch need to copy the source code to another folder, and under Git , the cost of creating a branch is very small, just one command warehouse directory structure is concise, with git to copy a project, only in the project root directory to create a. Git, while the other directory is very clean content is stored in metadata, all version information is located in the. Git directory is good, easier to collaborate development Large user base, there are now tens of thousands of open source projects using Git to do project management, GitHub has countless code warehouses

3. Git Installation and configuration

a) Installation

1. From the source installation

Before installing, you must ensure that the following several dependencies 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

When all the dependencies have been resolved, you can download Git's source code from the Http://git-scm.com/download, and then compile the installation, with the following specific commands:

TAR-ZXF git-1.*.*.*.tar.gz

CD Git-1.*.*

Make prefix=/usr/local All

sudo make prefix=/usr/local install

2. Install on Linux

If your system is Linux or fedora, you can install git directly with the following command:

Yum install Git-core (Fedora)

Apt-get install Git-core (Ubuntu)

3. Install on Windows

Although Git originated in Linux, there is now a normal use of Git on Windows, except that it does not support Chinese, all Chinese displays a question mark in Windows, and a few feature bugs. So it is recommended to use Git on Linux, if you have to work on windows, you can go to http://msysgit.github.com/download the latest version of Msysgit, the installation process and other Windows programs almost, Basically, the next step is OK. Msysgit will install Git bash and git gui 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 first time using Git

After you install git, you need to modify some of the configuration to use git properly.

git configures git with the "git config" command, which has 2 options:--system,--global, plus the default option, which corresponds to the level 3 configuration file on Git, respectively. The first is the/etc/gitconfig file, which corresponds to the--system, which is the global configuration file, and modifying this file will affect all the users on the system, all the warehouses. The second 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 is the. git/.gitconfig file in your warehouse, which is the default modified configuration file for Git config, which only affects your current warehouse.

When you first use git, you need to tell your collaborative developer, who you are and what your mailbox is, that Git needs both information when you submit it. Specifically, set the following command:

git config--global user.name "Test OSS"

git config--global user.email oss.lzu.edu.cn@gmail.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.

Once you've set up git, you may need to generate your own SSH key pair if you want to get a warehouse from a git server or submit your code (such as GitHub) to a git server. GIT supports 4 protocols for server-side communication: git, http, ssh, and HTTPS. Where Git is just a read-only protocol, which means you can only get the warehouse from the server side, but you can't submit your own code. HTTP and HTTPS are rarely used, and most support only SSH and GIT protocols.

When you communicate with the remote server through the SSH protocol, you can generate the SSH key pair by using the following command:

SSH-KEYGEN-T RSA

If you do not specify the key name and store path, it defaults to two asymmetric keys in your home directory, the default name of the key file is Id_rsa and Id_rsa.pub, the former is the private key, the latter is the public key. The middle may want you to set access key password, this can be set, you can not 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 the key.

Then send your public key to git warehouse administrator, then you can access the server side via SSH protocol, during which the program will automatically match the key pair, if you set the access password, you may need to enter the password.

For more information on SSH, please visit here: http://www.freebsd.org/doc/zh_CN/books/handbook/openssh.html

Once these are done, you can check to see if your git is working properly by obtaining any open code warehouse. Like the following:

git clone git://git2.kernel.org/pub/scm/git/git.git

4. Git warehouse

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 the files you need to manage. For example, now that I have a project, which is in the test folder, I want Git to manage this project, and this time you need to go into this directory and run the git init command. At this point git will generate a. git hidden directory under this directory, and all files that Git uses for versioning and content tracking are under that folder.

Files that are under Git tracking have only three states:

Modified (working directory): modified file staged (staging area): Files added to staging areas via git add committed (git directory): through Git Commit a file to the warehouse

So, the general Git workflow might be this: modify some files, and then add them all to the suspend area, then commit to the warehouse to form a version or snapshot, and finally 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 the concept of staging areas, and submitting them directly 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 are free to control what files are submitted to the warehouse, which also avoids the inclusion of intermediate files, such as compiled files, in one version.

5. Git basic process

1. Initialize Warehouse

There are two scenarios for initializing a warehouse, one of which is to create a project directly in an empty directory where you can do this:

Git init

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 git@github.com:wengpingbo/microblog.git (remote repository)

Git clone/home/oss/test.git (local warehouse)

The first time you copy a warehouse from the server, it may be slow, because Git has to copy all the history and version, which is one of the drawbacks of Git.

After the copy is completed, 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 OK. For example, I want to put the test warehouse in the OSS repository: Git clone/home/oss/test.git oss

After that, you can start your work.

2. Add Files

After editing a few documents, you may suddenly recall that the file did not let git trace it. Git does not track your files in real time, it only records the current state of the specified file in the warehouse when you explicitly let it record your file, and then goes away. 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 too lazy to add one, you can try this:

Git add-a

It adds all the files in the current directory to the staging area.

3. Add a version

After you have added the file, you may feel you should create a commit.

Git commit

What do you think. Is there something wrong, as if the command hadn't jumped out of the way you thought it would, but ran directly into the editor you specified in the configuration. Take a closer look, the original is let you do some notes to this version, casually write something, and then save the exit on 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 wordy to commit a commit, but there's a shortcut that allows you to skip the process of adding files:

Git commit-a-m ' initial version '

Done, this command will add all the previously added files to this version.

Maybe you have a question again, the file you added earlier is 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 the file is added, it will always exist in each version. If you add a file and then modify it again, when you commit, you will only commit the state of the file when it is added, and you will not commit the subsequent modifications unless you add it again.

4. Push change

After you commit, you may want to submit your code to a github or other Git server and share it with others, and you will need to deal with a remote server.

If you are a locally built warehouse, there is no server address by default, and if you are a repository replicated from another server, this server address is automatically added to your warehouse, so you can view:

Git remote-v

If you enter Git remote only, the server-side alias is listed and the address is not listed.

A warehouse can have multiple server addresses, which means that you can copy the same warehouse from different people, but that doesn't disrupt your own branch, even if both branches have the same name. If you're working on the same branch of the same project as another two people, you find that a module of a is exactly what you want, and you want to incorporate his code into your current version, you can do this:

git remote add code_a git://url/test.git//Add each other's address, Code_a is alias

git fetch code_a//Copy each other's warehouse to the 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 other servers, at which point 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 his master to the server named origin.

5. Create and manage branches

When doing a project, you may want to write some extensibility features, or do some small experiments, but you do not want to affect your current project. At this point, you can create a branch, and then write something in this branch, and when you feel bad, you can remove the branch and have no effect on your previous main branch. Or you feel that this new feature is beyond your expectation and can be merged into the main branch, when you simply turn the work back to the main branch, merge the branches, and then delete the branches, and then you don't create the same branch. The specific actions are as follows:

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//combine 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//List of branch lists and current commit

The essence of Git merge is to put two versions together, then a new commit is created in the current branch, and if you modify it in the same place in the same file as the two branches, the merge will fail, and Git will not automatically create a new commit, but simply stop. You need to manually modify these conflicting files, select one of these two branches, or rewrite the section yourself, and then manually add the files to the staging area, and then commit to the OK. To see which files are conflicting, you can view them with git status.

6. Undo Changes

It's people who make mistakes. When you execute a command, you suddenly find yourself writing wrong, or missing a file, what to do at this time.

If you submit too early and forget to add certain files, you can do this:

Git commit-m ' add something '

git add file1

git commit--amend

The last command will give you the most recent commit to your current staging area. If you commit later, immediately amend, git will jump directly into the edit commit note, so you can modify your last commit comments.

If you add a file that shouldn't be added, you can save it:

git Add. Add all the files to the file.

Git reset head Readme//Remove Readme file from Staging area

If you find that you have edited a wrong file and you want to revert it to the previous version, you can do this:

Git checkout--filename1//Only undo this file

If you think this version sucks, and you want to roll back to the previous version completely, you can do the following things:

git reset--hard head^

The head is pointing to the current version, ^ refers to the parent version of the current version, and this operation cannot be undone. You can replace--hard with--soft, which will only rollback the commit message. There is also a--mixed default option, you can refer to the official documentation to see the specific differences between these 3 options.

6. Git common commands

Git add

Git Clone

Git Commit

Git push

Git Checkout

Git Reset

Git Pull

Git status

Git Branch

Advanced

Git tag

Git Log

Git Merge

7, learn git related information

"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