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:

Git flowchart

(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