Git Branch Management and the Use of Gitlab
For instructions and basic operations of gitlab, please refer to https://blog.51cto.com/wutengfei/2090253.
Using the GIT branch, let’s start with a simple case. There are many people in your team working on a project to develop a new function. It takes a week to complete it. He wrote 30% of the new functionality that has not been finished yet. If he submits the version, the rest of the team can’t continue. Developed. But when he has finished all his work and submitted it to us, we can’t see the progress of his development, and we can’t continue to work. What can we do?
For the above problem, we can use the branch management method to solve, work together to develop new functions, he can create a branch of his own, other colleagues temporarily can not see, continue to work on the development branch (usually have multiple branches), he works on his own branch, wait for him to fully develop. Is it convenient for us to complete and merge once more into the development branch so that we can know the progress of his development without affecting everyone’s work?
Here’s the explanation: SVN can also implement the functions mentioned above, but Git, whether you create or switch or delete it very quickly!
- The Nature of Branches
Branches are essentially a variable pointer to a submission. Git’s default branch name is master. And how do we know which branch we are currently in? The answer lies in the very special pointer HEAD, which is specifically used to point to the current branch in the local branch. We can simply understand that: commit < – Branch < – HEAD (note, simply say that HEAD points to the current branch in the local branch), as shown in the figure:
Note: The dev in the figure above refers to a branch of git.
- Creating Branches
When we need to debug a Bug or try to add or modify a module in the program without affecting the development of the main branch. You can satisfy your needs by creating branches. Creating a branch is equivalent to creating a new branch pointer to the current submission. We created dev branch on Commit3:
## Before creating dev branches, let's take a look at the current branches git branch -a \* master remotes/origin/master ## Create dev branch git branch dev ## View the current branch git branch -a dev \* master remotes/origin/master
- Switching branch
As you can see from the above operation, although we have created a new branch, HEAD still points to master. If you want to switch to a new branch while creating a branch, you can do this by following commands:
git checkout dev Switched to branch 'dev' git branch -a \* dev master remotes/origin/master ## Note: The git checkout command with the - b parameter indicates the creation and switching of branches.
The git branch-a command looks at all branches, and now our HEAD pointer points to the dev branch. You can see in the figure above that there is a * sign on the dev branch. As shown in the following figure:
- Submission of branch documents
## We're now on the dev branch. echo "this is a test" > shiyan.txt git add shiyan.txt git commit -m "add a file shiyan" [dev 0e7aa94] add a file shiyan 1 file changed, 1 insertion(+) git push fatal: The current branch dev has no upstream branch. To push the current branch and set the remote as upstream, use：git push --set-upstream origin dev git push --set-upstream origin dev
The process described above is illustrated by a flow chart as follows:
Now we’re working on the dev branch.
## Look at the files on the dev branch ls shiyan.txt ## Switch to master branch git checkout master ## View the files on the master branch ls ## There is no shiyan. TXT file. Let's log in to gitlab and see if there is a shiyan. TXT file on the dev branch. ## Cause: Because that submission is on the dev branch, and the master branch is unchanged.
- Merge Branches (Quick Merge)
Now, we merge the work of dev branch into master branch. The following is how to do this:
## Operating on the master branch git checkout master git merge dev Updating 602d921..f6f8543 Fast-forward shiyan.txt | 1 + 1 files changed, 1 insertion(+) create mode 100644 shiyan.txt ## The git merge command is used to merge the specified branch to the current branch. After merging, look at the contents of shiyan. TXT again, and you can see that the latest submission of dev branch is exactly the same. ls shiyan.txt ## Description: (1) The Fast-forward information above, Git tells us, this merge is "fast forward mode", that is, direct master to dev's current submission, so the merge speed is very fast. Of course, not every merger can be Fast-forward, we will later merge in other ways. Once the merge is complete, you can safely delete dev branches. (2) Shiyan.txt already exists in the master branch on gitlab.
- Delete branches
## Operating on the master branch git checkout master git branch -d dev Deleted branch dev (was f6f8543). ## View the current branch git branch -a \* master remotes/origin/dev remotes/origin/master
- Summary of commands
## View Branches git branch -a ## Creating Branches git branch name ## Switching branch git checkout name ## Create and switch git checkout -b name ## Merge a branch to the current branch git merge name ## Delete branches git branch -d name