Git version control (code management) system
1, Deploy Git
1. Basic environment
yum install git
yum install dh-autoreconf curl-devel expat-devel gettext-devel openssl-devel perl-devel zlib-devel
yum install asciidoc xmlto docbook2X
Unzip, compile and install
tar -xf git-2.9.5.tar.xz -C /usr/local cd /usr/locat/git-2.9.5 make && make install
2. Create version Library
Select a suitable place and create an empty directory
cd /opt mkdir test cd test git init # Initialize and change the current directory into the version library managed by git
You can see that a hidden folder will be created in the current directory git
It's easy not to touch any files in it, because this directory is used by Git to track and manage the version library. If you break it, the Git warehouse will be destroyed.
The. Git directory is the Git version library
There are many things stored in Git's version library, the most important of which is the temporary storage area called stage (or index), the first branch that git automatically creates for us, master (usually called the main branch), and a pointer to the master called HEAD.
3. Workspace, staging area and master branch
Git and SVN One of the differences is the concept of work area and temporary storage area * Work area: it is used for developing and editing files at ordinary times. Under the warehouse directory you created, it is the work area * Staging area: a place used to temporarily store documents to be submitted to the warehouse .git Directory. * master Branch: the place that is really used to store and publish the completed code files .git Directory.
Relationship between the three
The original file is in the workspace
git add readme.txt, the file is added to the staging area. At this time, the files in the workspace are consistent with those in the staging area.
After git commit -m "new file readme.txt", all files and directories in the staging area will be submitted (moved) to the branch master.
At this time, the files in the workspace will be consistent with the files in the current branch master, while there are no files in the staging area, which is clean.
You can add multiple times and submit once.
2, Git warehouse
1. Basic command
git add . #Submit all modified files in the current directory to the staging area git commit -m "add a.txt" #Submit version to warehouse # The - m parameter of git commit is followed by the description of the submitted version. git status #View the latest changes and status of the warehouse git reset --hard +Version number of fallback #Fallback version git log --graph --oneline --decorate --all #View current version submission status git tag # View all labels of the current version Library # Label the submission point where the current branch is located git tag Label name git tag v1.0 # Label historical submission points git tag Label name commit id git tag 2.0 23fe3456 # Switch version number with label git reset --hard Label name git reset --hard 2.0 # delete a tap git tag -d Tag name
2. HEAD pointer
The version to which HEAD refers is the current version; When you switch versions back and forth, Git just points the HEAD to the version you want to switch, and updates the files in the workspace, as shown in the figure below:
The pointer after the latest submission points to:
The pointer after version fallback points to
3. Branches and labels
(1) Branch creation and merging
In version fallback, you already know that Git strings them into a timeline for each submission, which is a branch. So far, there is only one timeline. In Git, this branch is called the main branch, that is, the master branch. Strictly speaking, HEAD does not point to submission, but to master, which points to submission. Therefore, HEAD points to the current branch.
At the beginning, the master branch is a line. Git uses master to point to the latest submission point, and then HEAD to point to master to determine the current branch and the submission point of the current branch:
Each time you submit, the master branch will move forward one step. In this way, as you continue to submit, the line of the master branch will become longer and longer
When we create a new branch, such as bac, Git will create a new pointer called bac, pointing to the same submission point of the master, and then point the HEAD to bac, indicating that the current branch is on bac:
Git creates a branch very quickly, because at this time, just add a bac pointer and change the direction of HEAD. There is no change in the files in the workspace!
From now on, the modification and submission of the workspace is for the bac branch. For example, after a new submission, the bac pointer moves forward one step, while the master pointer remains unchanged, and the HEAD pointer remains the same:
If our work on bac is completed, we can merge bac into master. How does Git merge? Very simply, first switch to the master branch, where the HEAD pointer will point to the master pointer, and then directly point the master to the current submission point of bac to complete the merger:
So Git merges branches very quickly! Just change the pointer, and the content of the workspace does not need to be changed!
After merging the branches, you think the bac branch is useless, and you can even delete the bac branch. Deleting the bac branch is to delete the bac pointer. After deletion, we have a master branch left:
(2) Branch operation
git branch #View the branch and all branches * indicates the branch git checkout dev #Switch to dev branch git merge dev #Merge dev branch to current branch git branch -d <name> #Delete branch
(3) Branching strategy
In actual development, we should carry out branch management according to several basic principles:
First, the master branch should be very stable, that is, it is only used to release new versions and cannot work on it at ordinary times;
Where do you work? Work on the dev branch, that is, the dev branch is unstable. At some time, for example, when version 1.0 is released, merge the dev branch into the master, and release version 1.0 in the master branch;
You and your friends, everyone works on the dev branch. Everyone has their own branch. Just merge on the dev branch from time to time.
So the branch of teamwork looks like this:
(4) Label operation
When publishing a version, we usually tag it in the version library first, so that we can only determine the version at the time of labeling. Whenever we take the version of a label in the future, we will take out the historical version of the labeled time. Therefore, the tag is also a snapshot of the version library.
Although Git's label is a snapshot of the version library, it is actually a pointer to a commit (much like a branch, right? But the branch can move, but the label cannot move). Therefore, the creation and deletion of labels are completed in an instant.
git tag #View all labels of the current version Library git tag v1.0 #Label the submission point where the current branch is located git tag Tag name commit +id #Label historical submission points git reset --hard v4.0 #Use the label to switch version v4 0 git tag -d +Tag name #delete a tap git show +Tag name #View label information
Note: labels are not listed in chronological order, but in alphabetical order
View historical versions
[root@ela1 test]# git log --pretty=oneline --abbrev-commit cb2b581 create a b.txt file fa9422f add 4 to a.txt 25b16e6 add 3 to a.txt 15da855 add 2 to a.txt 7947f08 add a.txt