The previous article introduced some basic concepts and common commands of git, and this article will talk about git branches in more depth.
1. Branch
Every time git commits, it will string them together into a timeline, and this timeline is a branch. As of now, there is only one timeline. In Git, this branch is called the master branch, that is, the master branch.
Strictly speaking, HEAD does not point to the commit, but to the master, and the master points to the commit, so HEAD points to the current branch.
With each commit, the master branch moves forward one step, so that as you keep committing, the master branch gets longer and longer:
A branch is equivalent to opening up a parallel space, and there is usually no intersection between parallel spaces unless a merge is made.
View branch: git branch
Create a branch: git branch <name>
Switch branches: git checkout <name>
Create + switch branches: git checkout -b <name>
Note: The branch marked with an asterisk indicates the current branch.
When we create a new branch, such as dev, Git creates a new pointer called dev, which points to the same commit as master, and then points HEAD to dev, which means that the current branch is on dev, and HEAD also points to dev. From the time of switching to the dev branch, the modification and submission of the workspace are for the dev branch. Once a new submission is made, the pointer of the dev branch moves forward one step but the pointer of the master branch remains unchanged, which is equivalent to the first creation of the dev branch. Now you have a copy of the same files as the default master branch.
1) For example, on the master branch at the beginning, the content of the hello.txt file is:
2) Switch to the dev branch: git checkout dev
3) Modify the hello.txt file:
4) Commit on the current branch:
5) Switch to the master branch, and then view the content of hello.txt:
The above experiments verify that the commits of different branches will not affect each other~
When our work on dev is completed, we can merge dev into the master branch. At this time, the master branch will be directly pointed to the current commit of dev, and HEAD is on master.
Merge a branch to the current branch: git merge <name> (equivalent to a commit, you can add a comment when merging: git merge -m "comment" <name>)
Verification: Merge the dev branch on master:
Then look at the contents of the hello.txt file on the master branch at this time:
You can see that the content of the hello.txt text on the master is the same as the content of hello.txt on the dev branch after merging the commits of the dev branch~
Once the merge is complete, you can delete the dev branch:
Delete branch: git branch -d <name>
Note: The branch of git must point to a commit. There is no branch without any commit. After submitting the first commit, git automatically creates the master branch.
When merging branches, Git uses Fast forward mode if possible, but in this mode, branch information is lost when a branch is deleted.
Note the --no-ff parameter, which means to disable Fast forward: git merge --no-ff -m "comment" <name>
The above situations are very common. For example, when your team receives the development of a new functional module, it is often necessary to open another branch. .
2. Branch conflict
Reasonable models for group development are commonly the following:
1) For a new function development module, open a new branch such as dev, and everyone develops on this branch;
2) Everyone has their own branch, just merge to the dev branch when the function is merged.
In any case, the master branch is a branch that directly deals with the repository, and is a relatively stable branch. We should not develop on the master branch, it is only used for version release~ The final developed branch must be merged here.
In order to simulate the branch conflict situation, because I only have one user at this time, then use mode 2) to simulate (in fact, it is equivalent to multiple development members of the team modifying the same Java class).
At the beginning, the content of dev's hello.txt is as follows:
1) If team member A uses branch A, the last line of hello.txt is modified as follows:
2) While group member B uses branch B, the last line is also modified (simple simulation conflict):
3) Now A tries to merge B's commit and finds a conflict:
Check the content of the hello.txt file directly on the A branch, you can see:
Look carefully at the conflicting part:
<<<<<<< HEAD表示当前版本下：do some out modify love and beauty
>>>>>>> B表示分支B下：do some out modify love & beauty
Attempt to merge under the current version HEAD:
Then add and commit:
You will see the words both modified.
When the branch conflicts: When git cannot automatically merge the branch, you must resolve the conflict first, and then use git log --graph --pretty=oneline --abbrev-commit to view the branch merge graph:
Conflicts are resolved and merge is complete.
3.clone remote warehouse and synchronize local warehouse
You can build a remote warehouse on github to simulate the company's private server.
For the specific tutorial, please refer to " Liao Xuefeng Great God ": http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/0013752340242354807e192f02a44359908df8a5643103a000
1) Clone the remote repository, for example, under the F drive, clone the HelloGit repository on github:
git clone git:@<ip>:<project/github账户名>/remote-repo-name.git
如：git clone git:@github.com:CommyChang/HelloGit.git
In this way, the local F drive will have a local library that is the same as the remote warehouse.
2) Associate the local repository to the remote server
To associate a remote repository, use the command git remote add origin git@server-name:path/repo-name.git;
After the association, use the command git push -u origin master to push all the contents of the master branch for the first time;
如：git remote add origin git@github:CommyChang/learngit.git；
git push -u origin master (you don't need to add it after adding u for the first time)
3. git pull and git push
Now the HelloGit in the local repository is associated with the HelloGit in the remote repository with the same name. Now suppose that colleague B has already modified the README.txt file on the master branch and pushed it to the remote warehouse. At this time , the content of the README.txt of the remote warehouse has changed from the original aaaaaaa to:
This is, colleague A also modified README.txt and submitted it to the local library:
Use git status to view the status at this time:
It will prompt that the version of the local warehouse is the same at this time, but it is 8 commits earlier than origin/master (the default name of the remote warehouse is origin), and push is recommended;
Then he also tried to push the contents of the local repository to the remote and found:
You will find that push is rejected, and git also recommends that we pull first.
git pull means to pull the version of the repository from the remote repository first,
It can be seen from the red part that in the process of pulling (that is, the process of merging the version of the remote warehouse with the local one), there is a conflict with the README.txt file. At this time, the content of the local README.txt is as follows:
Modify it and submit it to the local repository:
At this point, you can see that the file README.txt of the remote warehouse is after the merge:
At the same time, there are more files a.txt submitted by A that were not available before:
The above simulation experiment reproduces the actual development work well, so when dealing with branches of remote warehouses, you must remember to git pull and then git push. .
4. Tag management
In git, each version release preferably has a corresponding version number. This is where tags are needed.
1) On the current branch, the latest commit is tagged by default, and git tag can be used to view all tags, that is, version information:
2) Tag a commit and view the commit information corresponding to a tag:
First find the commit you want to tag:
Use the command git show <tagname> to see the description text;
You can also create labels with descriptions, use -a to specify the label name, and -m to specify the description text:
Next, let's talk about the operation of the label:
Delete tags: git tag -d tagname
Push to remote: git push origin tagname
One-time push to remote: git push origin --tags
Delete remote tags: first delete the local tag git tag -d tagname, then delete the remote git push origin :refs/tags/tagname
Summary: Based on the previous article, this article has a deeper understanding of the use of git in actual work through scenario reproduction, and hopes to have a clearer understanding of the use of git in the future~