hint: Look at the way this article, do not understand the first skip, read the length of the following may be understood.
git and GitHub
concept
Git---version control tool (command).
Tool Introduction Official Website: http://git-scm.com
Tool Download Address: http://git-scm.com/download/
git is an open source Distributed version control system for efficient, high-speed processing from very small to very large project versioning. git is a tool that, like GCC, is a shell command in Linux. git is an open source version control software developed by Linus Torvalds to help manage Linux kernel development. Torvalds started to develop git to replace BitKeeper as a transition solution, which was previously the primary source code tool used by Linux kernel developers worldwide. Some in the open source community felt that BitKeeper's license was not suitable for the work of the open source community, so Torvalds decided to embark on a more flexible version control system. While Git was originally developed to assist the Linux kernel development process, we have found that Git is also used in many other free software projects. For example, many freedesktop projects have migrated to Git.
Github---A platform (web site).
GitHub official website: https://github.com/
provide users with the Create Git storage space , Save (managed) user's some data documents or code, etc.
GitHub currently has more than 1.4 million developer users. As more and more applications migrate to the cloud, GitHub has become the preferred method of managing software development and discovering existing code. GitHub can host a variety of git libraries and provide a web interface, but unlike other platforms like SourceForge or Google code, GitHub's unique selling point is the simplicity of branching from another project. The code for a project is very simple: first click on the "Fork" button on the project site, then check out the code and add the changes to the code base that was just identified, and finally through the built-in "pull request" mechanism to the project owner for code merge. Someone has GitHub called the code Player's MySpace.
GitHub public warehouses are free and private warehouses are charged.
the relationship between Git and GitHub
After specifying remote links and user information (git by user name + mailbox-aware user), Git can help you push the code that you submitted to your local branch to a remote git repository (any server that provides a git hosting service, including You build your own server or a server provided by a github/bitbucket, or you fetch the code from the remote repository to the local site.
GitHub is just a server that provides storage space to store git repositories. now, of course, GitHub has been developed from a repository of git to an open source community ( not just the ability to store git warehouses ), you can participate in other people's open source projects, or you can involve others in your open source projects.
GitHub similar Products
There are many github similar platforms that provide storage for git warehouses.
BitBucket
Public and private warehouses are free of charge.
URL: https://bitbucket.org/
Gitcafe
URL: https://gitcafe.com/
Gitlab
Gitlab can download software Gitlab CE or operate directly on the online platform.
URL: http://www.gitlab.cc/
Git@osc
Git@osc is the open source China Community team based on open source project Gitlab development of online code hosting platform.
URL: http://git.oschina.net/
CSDN Code Hosting Platform
The CSDN code system is built on the Aliyun IaaS platform and provides services such as code hosting, online collaboration, social programming, and project management to individual developers, it teams, and businesses.
URL: https://code.csdn.net
the difference between git and CVs and svn
Git is a distributed version control system, where the code submission is local (so fast), and of course it needs to be networked to generate patches (patch) and then push to a remote server .
CVS, SVN is a centralized version control system, the code submission is committed to the remote server, is required to be networked (so slow) (this is the network is not to say that you write code when you want to network, but that you submit code must be networked; but git is different, Git commits the code is local do not need networking, generate patch after push patch need networking, the equivalent of SVN remote centralized server for GIT, this centralized remote server is local. This place is more difficult to understand.
A centralized version control system such as CVS and SVN, where the complete code warehouse (the code warehouse contains not only code, but also historical versions of information, etc. ) on the central server, once the hub server is dead, the complete code warehouse hangs, Although you may have previously obtained code from a central server, there is no historical version of the information, and you can no longer submit code.
Git is different, git does not have a central server concept, and every Git client (git node) contains a complete code warehouse (provided you have previously fetch code from a remote Git repository), so those historical versions are on your computer, and if which git node is dead, Randomly clone a code warehouse from other GIT nodes OK, the original code, version information, and so on is complete ( of course, if you are in this hanging git node of the new code is not dropped ).
In summary,each of Git's nodes (the first time you get code from a remote Git warehouse, which is a complete code warehouse) is the equivalent of SVN's central server, which contains the complete code warehouse .
How git works
Frame composition
Functional characteristics
Feature Features for git:
From a general developer 's point of view, Git has the following features:
1. Clone the complete Git repository (including code and version information) from the remote server to its own machine (stand-alone).
2, on their own machines according to different development purposes, create branches, modify the code.
3. Submit the code on the branch that you created on the stand-alone machine.
4. Merging branches on a single machine.
5, the remote server on the latest version of the code to fetch down, and then merge with their main branch.
6, Generate patches (patch), the patch sent to the main developer.
7, look at the feedback from the main developer, if the main developer found that two general developers conflict (they can cooperate to resolve the conflict), they will ask them to resolve the conflict, and then by one of the people submitted. If the main developer can resolve it himself, or if there is no conflict, pass it.
8, the general developers to resolve the conflict between the methods, developers can use the pull command to resolve conflicts, resolve the conflict and then submit the patch to the main developer.
From a master developer 's point of view, Git has the following features:
1, view the mail or other ways to view the general Developer's submission status.
2, the patch to resolve conflicts (you can solve their own, you can also ask the developer to resolve between the next resubmit, if it is open source projects, but also to decide which patches useful, which do not).
3, submit the results to the remote server (public), and then notify all developers.
Advantages:
1, suitable for distributed development, emphasizing individual.
2, the remote server (public) pressure and the amount of data are not too large.
3, fast, flexible.
4. It is easy to resolve conflicts between any two developers.
5, off-line work. ( of course, submitting a remote server or fetch code from a remote server is to be networked ).
some concepts and principles in Git
Work Area
Working Directory
The directory that can be seen on the computer is the working directory, for example:/e/git_repo/
Version Library
Repository
There is a hidden directory in the workspace. Git, this is not a workspace, it's a repository of git.
A lot of things are stored in Git's version library, the most important of which is called the stage (or index) registers, and the first branch master git automatically created for us, and one pointer to master is called head. Constructs see the above structure diagram.
Registers
Stage
Registers is an area of the version library, see the chart above.
relationships between workspaces, version libraries, registers
The process of git work is:
Step 1th, use git add to registers the file from the workspace to the version library, and the git add command can be used multiple times;
The 2nd step, using Git commit to commit the code, is to commit all the contents of the registers to the current branch.
In summary, the file revisions that need to be submitted are all put into the registers (possibly multiple git add), and then all the modifications to the registers are submitted at once to the current branch (git commit).
Branch
What is the use of the branch (branch)? Suppose you are ready to develop a new function, but it takes two weeks to complete, the first week you wrote 50% of the code, if immediately submitted, because the code has not finished, incomplete code base will cause others can not work. If all the code is written and submitted again, there is a huge risk of losing the progress of the day.
Now with the branch, don't be afraid. You have created a branch of your own, others can not see, but also continue to work in the original branch, and you are working on your own branch, want to submit to submit, until the development is completed, and then a one-time merger into the original branch, so that both safe, and does not affect others work.
Branch Internal Principle
1, as shown in the following picture, every time a commit is made by a version, Git concatenates them into a line based on the point of delivery. At first there was only one timeline, the master branch, and the head pointed to the current version of the current branch.
2. When you create a new branch, such as the Dev branch (through the command git branch dev), Git creates a new pointer Dev,dev=master,dev point to the version that master points to, and then switches to the Dev branch (by using the command git checkout Dev complete), point the head pointer to Dev, as shown below.
3, in the Dev branch coding development, are in the dev on the pointer movement, for example, in the Dev branch commit once, the dev pointer moved forward, but the master pointer does not change, as follows:
4. When we have completed the work on the dev branch, we want to branch merge, merging the contents of the Dev branch into the Master branch (by first switching to the master branch, git branch master, and then merging the git Merge Dev command). The internal principle is to point the head pointer at master first, and then point the master pointer at what the dev pointer is pointing to now. The following figure.
5, when the merger of the branch of the conflict (confict), such as a commit in the dev branch of a file File1, and also submitted on the master branch of the file File1, modified in different places (such as all modified the same statement), Then there is the possibility of conflict when merging, as shown in the following figure.
When the git merge dev command is executed, GIT will perform the merge by default, but to manually resolve the conflict, and then git add and git commit on master, now the structure of the GIT branch is shown below.
You can view the branching merge using the following command.
git log--graph--pretty=oneline--abbrev-commit
6, after the completion of the merger, you can delete the Dev branch (through the git branch-d dev command to complete).
So, is the principle of branching development. The benefits are also obvious.
Branch Policy
How to use branches appropriately.
In the actual development, we should follow several basic principles for branch management:
1, the master branch should be very stable, that is, only for the release of the new version, usually not in the Master branch coding development. The master branch should be synchronized with the remote repository ;
2, Common coding development in the Dev branch, that is, the dev branch is unstable, at some point, such as Release 1.0, then the Dev branch merged into Master, in the Master Branch Release 1.0 version of theDev branch should also be synchronized with the remote; Push/git pull also to resolve conflicts)
3, you and everyone in the team are working on the local Dev branch, each with its own branch, and Push/pull on the remote dev branch. (Push/pull is the time to resolve the conflict. ) )
The above diagram is a schematic diagram, in fact, the above figure is omitted git push/git pull operations, such as Bob on the local Dev branch, a new Feature1 branch to complete the work, the local Dev branch merged Feature1 branch, Then you push the dev branch onto the public server so Michael can pull what Bob has done. A more detailed picture is as follows:
PS: Git does not have the concept of a public server, each of Git's nodes is a complete git library, but the public server is convenient for the GIT node between the code to each other push/pull (otherwise each git node need to connect each other, Each additional git node will be connected to another Git node. As shown in the following illustration:
Structures with public servers have no public server structure
With a public server, when adding Tom nodes, only Tom and the public server are connected, and Tom can get (pull) Michael to submit (push, not commit,commit is locally committed, not pushed to the public server) code, You can also get Bob's submit (push) code.
Without a public server, Tom would have to establish a network connection between Tom and Michael if he wanted to get Michael's code (pull), and to get (pull) Bob's code, a network connection must be established between Tom and Bob.
git installation
installation on Linux
Yum Install git
installation on Windows
Http://git-scm.com/download/win
Download the installation can be.
After the installation is complete, you need to set the final step , and enter at the command line:
git config--global user.name "Your name"
git config--global user.email "email@example.com"
Because Git is a distributed version control system, every machine must be introduced herself: your name and email address. Note the --global parameter of the git config command, which means that all git warehouses on your machine will use this configuration, and of course you can specify a different username and email address for a warehouse . This opportunity then generates a. gitconfig file that contains information about User.Name and User.email.
Windows needs to add another configuration , as follows:
git config--global core.autocrlf false
If this configuration is not added, warning may be reported as follows for the following GIT operations:
This is because the newline character in Windows is CRLF (\ r \ n), and the line break under Linux is: LF (\ n).
When you use Git to build a project, the newline character in the file is LF, and in Windows, when you perform the Git add file operation, the system prompts: LF will be converted to CRLF.
CRLF-Carriage-return line-feed carriage return line, which is the carriage return (cr,ascii 13,\r) linefeed (Lf,ascii 10,\n).
git command
The Git directory is best not to include Chinese names.
Single operation command/single warehouse command
Create a version library repository
mkdir git_repo
cd git_repo
git init
The. Git folder is generated in the directory, which is the management file of the Git repository, and do not arbitrarily change the contents. The folder is hidden by default, and the LS command is not visible and can be seen with the Ls-ah command.
Create a new File1.txt file with the following contents (optional):
This is file1.txt.
For test~~~
adding files to the code base
git add file1 file2
... git commit-m "comment"
git add is to commit the file submitted to the commit cache first;
git commit is the real file submission.
By using the git add command, you are adding files to git management with a variety of git information tracking, such as the code version number, where it was modified, and so on.
View Code Warehouse status
git status
Suppose I modified the contents of the File1.txt file as follows:
Hello everybody!
This is a file1.txt.
End file.
Then take a look at the git status command:
The above hints tell us that File1.txt has been modified, but it has not yet been added to the commit cache, that is, it is not ready to commit (commit).
View Modified Content
Although Git status tells us that File1.txt has been modified, but does not tell us where it was modified, use the following command in order to see exactly where the file has been modified:
git diff file
The git diff command is used before the git add command, otherwise the git diff command fails once it is added to the commit cache。
after git add, and then look at git status, it becomes a ready to commit (commit) state .
Then git commits the success.
After the commit, let's look at Git status as follows:
The yellow box above shows that the current directory has a less file is not managed by git, this is the file I accidentally joined, in this useless, can be deleted. If it's the file you need, add it to git management via git Add.
After you delete the less file, look at git status as follows:
view the differences between two versions
git diff version 1 version 2 [file]
The file is an optional parameter and is compared with all the different modifications without the [file] parameter:
with [file] parameters, you can only view the difference of a file:
View Commit History
git log
View command History
Git reflog
version fallback
git reset--hard head^
git reset--hard head@{4}
First look at the history version with git log or Git reflog, and then roll back the version with git Reset command, as follows:
git is using head to represent the current version in the current branch , head^ represents the previous version, head^^ represents the previous version, and so on, if you want to roll back a very early version with the head@{version number}, the version number is viewed with Git reflog.
Undo Modification
Divided into 3 kinds of situation
Scenario 1: When you mess up the contents of a file in your workspace and want to discard the workspace changes directly, use the command git checkout-file or manual modification.
Scenario 2: When you not only changed the content of a file in the workspace, and also added to the registers (that is, already git add), want to discard changes, two steps, the first step with the command git reset head file, back to scene 1, the second step by scene 1 operation.
Scenario 3: If you have submitted an inappropriate modification to the version library, you want to undo this submission, you can use the version fallback (reference version fallback section), but only if it is not pushed to the remote library .
The following examples illustrate:
Scene 1
If the file is still in the workspace and there is no git add to registers, there are 2 ways to undo the modification: as follows:
The 1th approach: manual recovery, to restore unwanted modifications. (This method can modify only part of the file)
The 2nd approach: Use the command git checkout-file. ( here--very important, subsequent versions of the branch are also using the git checkout command, it does not--)
(This method can only recover files entirely, because git checkout-file actually replaces file in the version library with the workspace now)
Scene 2
When you not only changed the content of a file in the workspace, but also added to the registers, you want to discard changes, two steps.
Step 1th: Use the command git reset head file, back to scene 1;
2nd step: By scene 1 operation.
The git reset head file command deletes the file in the cache and does not affect the subsequent changes to the workspace, such as the above example, git add and then modifies the contents of the file Everybody->chenj_freedom,git reset After head file, the contents of file are still chenj_freedom.
Scene 3
If you have submitted an inappropriate modification to the version library, you want to undo this submission, and the reference version is back to the section, but only if it is not pushed to the remote library .
Delete file/mistakenly delete restore
Delete files from the version library
git rm file or git add file
git commit
Mistakenly delete recovery
Git checkout--file
Git checkout--file is actually replacing the workspace file with a file in the version library, so you can restore it with a single key, regardless of whether the workspace file is modified or deleted.
Remote Warehouse Command
associating remote warehouses
git sqlremote add remote warehouse name [URL]
Example:
Git remote add Origin git@github.com:chenj-freedom/learngit.git
As above, origin is the name of the remote warehouse (note: Yes
WarehouseThe name of the warehouse contains
Branchand other information).
View Remote repositories
git//view remote warehouse
git remote-v//view remote warehouse, more details
The following figure:
The fetch description has local permission to extract the remote warehouse, and the push indicates that there is a local right to push code to the remote warehouse.
cloning a remote repository
git clone [url]
Example:
The git clone will automatically name the remote repository as Originand crawl all the data in the remote repository, create a master pointer to it, name it locally as Orgin/master, and then, git automatically builds a local master branch of your own, starting with the same location on the master branch of the origin (theMaster Branch, also known as the Tracking Remote branch ), where you can start working.
The principle is shown in the following illustration:
Tracking Remote Branches
A local branch checkout from a remote branch, called a Trace branch (tracking branch). the essence of a trace branch is to make the local branch name point to the remote branch name. (essentially, setting the pointer), as in the previous section, makes the local branch name (master) point to the node to which the remote branch name (origin/master) points. after you set up a trace branch, using the git push/git pull command automatically makes the local branch (local-branch-name) automatically push/pull the contents of the remote branch (remote-branch-name).
The command format is as follows:
Git checkout-b [local-branch-name] [remote-name]/[remote-branch-name]//Legacy format
git checkout--track [remote-name]/[ Remote-branch-name]//simplified format
The first line is the traditional format, the second line is a simplified format, and in a simplified format, the local branch name defaults to the same name as the remote branch.
For example: Suppose there is now a branch dev11 in the remote repository.
After the branch is tracked in the traditional format, set the local branch name to the remote branch name and view it with the command git Remote Show Origin command. At this point, git push is configured to push the local DEV11 branch to the remote Dev11 branch, and the local master branch is pushed to the remote master Branch; The git pull command is configured to merge the remote DEV11 branch into the local DEV11 branch. The remote Master Branch is merged into the local master branch.
But if you set the local branch name differently than the remote branch name in the traditional way, use the command git Remote Show Origin command to view it. The git pull command or 2 branches (master and DEV11) can be pulled and merged into the local branch, but the push command is only available to the master branch. Therefore, it is best to configure the local branch name and the remote branch name. (therefore, the default local branch name and the remote branch name are used directly with--track)
Push Content
git push [remote-name] [Local-branch-name]:[remote-branch-name]
Attention:
1, the order of which local-branch-name or remote-branch-name can be omitted one of the two.
2, only on the remote server with write permission, or at the same time no one else is pushing data, this command will finish the task on schedule. If someone else has pushed a few updates before you push the data, your push will be dismissed. You have to take their update crawl (git pull) locally and merge them into your project before you can push them again.
Example: Git push Origin master
Here git automatically expands the master into Refs/heads/master:refs/heads/master, meaning "Take my local master branch and push it to the master branch of the remote repository."
If you want to call the remote Master branch The other branch, you can use GIT push Origin master:other.
Crawl Content
git fetch [remote-name]//Crawl the entire contents of the remote warehouse, but does not automatically merge
git pull//crawl the contents of the Remote warehouse Tracking branch and automatically merge to the appropriate local branch
Git pull is your local branch. Using this command, it automatically crawls the contents of the remote branch tracked by the local branch , then merges it on the local branch and does not crawl the content on the other branches.
Example 1:git fetch origin
This command will go to the remote repository and pull all data that is not in your local warehouse. Once the operation is complete, you can access all the branches in the remote repository locally.
Git fetch crawls all updates that have been uploaded to this remote repository since the last time you cloned it (or someone else has submitted the update since the last fetch). It's important to remember that thegit fetch command simply pulls the remote data to the local repository, does not automatically merge to the current work branch, and requires you to manually merge it yourself . As shown in the following illustration:
Create a new Git_repo folder locally, instead of cloning a remote library through the git clone command, rather than using the GIT remote add to associate it, and using git fetch to crawl all the data that is not crawled from the remote library, you must manually merge git when you crawl down The contents of the Merge remote library will display the branch content, otherwise, no manual merge, git fetch will not be automatically merged.
Example 2:git pull
Experimental premise: On the GitHub page, the DEV11 branch creates a new file Remote_file.txt and creates a new file Master_remote_file.txt in the Master branch. and use git checkout-b to track remote branch dev11 and master. Next, with the git pull command (note: The git pull command is used on the local DEV11 branch, the contents of the remote branch tracked by the Dev11 branch are crawled and merged into the local DEV11 branch.
However, the contents of the master branch have not changed. As follows:
Remove Remote Branch
The branch in the remote warehouse is deleted.
git push [remote-name]: [Remote-branch-name]
Remember git push command? git push [remote-name] [Local-branch-name]:[remote-branch-name], set the local branch to null (before the colon), In contrast to the Remote-branch-name branch that pushes an empty branch to a remote repository, it is equivalent to deleting the branch in the remote repository.
Example:
Delete Remote Warehouse Local association
Git remote RM [Remote-name]
Example: Git remote RM origin
Delete Remote Branch Local association
Deleting a remote Branch association also deletes the local trace branch.
Git branch-d [local-branch-name]
and delete the same command as the local branch.
Branch Management Commands
Create, toggle, view a branch
Suppose Dev is to create a branch name.
Git branch//view branch
git branch dev//Create branch
git checkout dev//Toggle branch
git checkout-b dev//Create and Toggle Branch
Merging Branches
Suppose Dev is to create a branch name.
Git merge--no-ff-m "commit comment" dev//disable Fast forward mode merge branch
git the merge dev//fast forward mode Merge branch
In Fast forward mode, the branch information is discarded when the branch is deleted.
Delete Branch
Suppose Dev is to create a branch name.
git branch-d dev
git branch-d dev//forcibly remove branches that have not yet merged
Bug Branch
Because Git has a powerful branch, modifying bugs is typically a new bug branch, modified, merged into your work branch (master branch or dev branch or whatever), and then remove the bug branch.
Assuming that the scenario, when you're coding on the dev branch, is suddenly receiving a bug that needs urgent fixes, you should want to build a bug branch, but your dev job hasn't been submitted (either add or commit), and you can use the "storage worker