Git series explanation (3): multi-person collaborative development under the same branch

The previous article talked about the basic operation of git in the case of a single person and a single branch, but the actual development process is a project jointly developed by multiple people. Everyone’s code will be merged into the same branch of the same warehouse, and then the code of the entire project will be merged Put it into the compilation system for compilation, and finally release the compiled image file.

1. Git model under multi-person collaboration

As shown in the figure below, if Zhang San and Li Si jointly develop the project sampleproject, they each synchronize the remote warehouse sampleproject to their own computers through the git clone command.
insert image description here

2. Remote warehouse configuration

In addition to the owner of the warehouse, if other members of the team can also have the upload permission of the warehouse, other people need to be added to the project members.
As shown in the figure below, click "Project Settings" —> "Project Member Settings" —> "Invite Users". After the invitation is successful, everyone can see the project on their gitcode homepage.

insert image description here
When everyone clones the project, everyone's directory is almost as follows:
insert image description here Note: All team members need to configure their own ssh keys, otherwise there will be problems when cloning the project through ssh

3. Case submission process

1. Case 1: Commit without conflicts

1. Zhang San fills in the following content in 1.txt and submits it
insert image description here
2. Li Si also wants to add his own information in 1.txt at this time, so
insert image description here
Li Si adds his own information in 1.txt Information, and make a submission
insert image description here
Check the branch diagram, you can see the submissions of Zhang San and Li Si
insert image description here

2. Case 2: Submission with conflicts (imperfect resolution)

Then the above case continued. After Li Si submitted, Zhang San wanted to add his height information in 1.txt, so the content of the file was as follows:
insert image description hereSubmitted immediately, but found that it was rejected by the remote warehouse when pushing up. It has been explained in the red box that someone (Li Si) submitted something again in the master branch of the remote warehouse, but our local is still our last submission (that is, the one that added the first and second lines of information in 1.txt Pen submission)
insert image description hereSo, Zhang San performed the following operations
insert image description hereand failed to merge, and then opened the 1.txt file to see the conflicting content
insert image description here. At this time, Zhang San could only go to Li Si to discuss how to write it. After discussing with the last two people, they decided to write this:
insert image description hereAfter the above manual merge, submit again, successfully
insert image description here

3. Case 3: Submission with conflicts (perfect resolution)

First, restore to the state at the beginning of Case 2 through 第四部分 - 1.回退远程版本库的master分支the method described, and then demonstrate the perfect submission plan, which is roughly four steps

======================< 1.创建本地工作分支work,修改目标文件并提交到本地work分支 >===================
sun@sun-pc:~/myProjects/codechina/sampleproject$ git branch work     #创建工作分支work
sun@sun-pc:~/myProjects/codechina/sampleproject$ git checkout work   #切换到工作分支work
切换到分支 'work'
sun@sun-pc:~/myProjects/codechina/sampleproject$ vi 1.txt   #修改1.txt内容
sun@sun-pc:~/myProjects/codechina/sampleproject$ git add 1.txt 
sun@sun-pc:~/myProjects/codechina/sampleproject$ git commit -m "modify zhangsan height in branch work"  #提交到本地work分支
[work 1c4181a] modify zhangsan height in branch work
 1 file changed, 1 insertion(+)

======================< 2.切换到master分支,拉取最新代码 >========================================
sun@sun-pc:~/myProjects/codechina/sampleproject$ git checkout master    #重新切换到master分支
切换到分支 'master'
sun@sun-pc:~/myProjects/codechina/sampleproject$ git pull origin master   #拉取服务器maser分支代码
来自 gitcode.net:In_engineer/sampleproject
 * branch            master     -> FETCH_HEAD
更新 497d396..ce9f545
Fast-forward
 1.txt | 2 ++
 1 file changed, 2 insertions(+)
sun@sun-pc:~/myProjects/codechina/sampleproject$ 

======================< 3.切换到work分支进行rebase并进行冲突解决 >=================================
sun@sun-pc:~/myProjects/codechina/sampleproject$ git checkout work   #再次切换到work分支
切换到分支 'work' 
sun@sun-pc:~/myProjects/codechina/sampleproject$ git rebase master  #将work分支rebase到master分支上
首先,回退分支以便在上面重放您的工作...
应用:modify zhangsan height in branch work
使用索引来重建一个(三方合并的)基础目录树...
M	1.txt
回落到基础版本上打补丁及进行三方合并...
自动合并 1.txt
冲突(内容):合并冲突于 1.txt
error: 无法合并变更。
打补丁失败于 0001 modify zhangsan height in branch work'git am --show-current-patch' 命令查看失败的补丁

手工解决所有冲突,执行 "git add/rm <冲突的文件>" 标记
冲突已解决,然后执行 "git rebase --continue"。您也可以执行
"git rebase --skip" 命令跳过这个提交。如果想要终止执行并回到
"git rebase" 执行之前的状态,执行 "git rebase --abort"

sun@sun-pc:~/myProjects/codechina/sampleproject$ vi 1.txt     #上一步合并有冲突,所以手动修改(merge)文件
sun@sun-pc:~/myProjects/codechina/sampleproject$ git add 1.txt   #因为前面rebase失败导致现在处于一个用于
                                                                 #变基的临时分支,直接git add将修改加进暂存区
sun@sun-pc:~/myProjects/codechina/sampleproject$ git rebase --continue    #使用continue选项继续前面的rebase
应用:modify zhangsan height in branch work   #rebase成功

======================< 4.切换到master分支进行merge并提交到远程服务器 >===============================
sun@sun-pc:~/myProjects/codechina/sampleproject$ git checkout master 
切换到分支 'master'
您的分支与上游分支 'origin/master' 一致。
sun@sun-pc:~/myProjects/codechina/sampleproject$ git merge work 
更新 ce9f545..6a0f51d
Fast-forward
 1.txt | 2 ++
 1 file changed, 2 insertions(+)
sun@sun-pc:~/myProjects/codechina/sampleproject$ git push origin master 
对象计数中: 3, 完成.
Delta compression using up to 16 threads.
压缩对象中: 100% (3/3), 完成.
写入对象中: 100% (3/3), 337 bytes | 337.00 KiB/s, 完成.
Total 3 (delta 0), reused 0 (delta 0)
To gitcode.net:In_engineer/sampleproject.git
   ce9f545..6a0f51d  master -> master
sun@sun-pc:~/myProjects/codechina/sampleproject

After finishing the work, you can see that the branch graph is still a straight line, and all the submissions of Zhang San and Li Si can be seen, and no abnormal branches have been generated. Note : If you use not
insert image description here

when submitting , it is best not to use the method of Case 3.git commit --amendgit commit

4. Submit a rollback

1. Roll back the local warehouse branch and the remote warehouse branch to a certain submission state

Then in Case 2, Zhang San and Li Si solved the conflict and submitted the revision. Before they were happy, they found a new problem after looking at the branch diagram. The branch graph actually forked, and a new green branch appeared, and the two of them immediately realized that such a submission would not work. At present, the project structure is relatively simple. If there are more people or more branches (in addition to the master branch in the real development process, according to the actual situation, it will also establish: develop branch, bugfix branch, release branch, feature branch, etc.), such a submission method will Let the branch graph be horrible, it is estimated that everyone will go crazy

insert image description hereNo way, it would be better for the two of them to ask their seniors for advice on how to do it. As soon as the senior saw this branch diagram, he immediately fell into obsessive-compulsive disorder. He said how to submit the problem first, and let this branch go back to Li Si's first Pen submission, if you don’t look uncomfortable, then start to operate:
insert image description herecheck the branch map on the gitcode platform, and find that it has been rolled back to Li Si’s first submission
insert image description hereNote: If git push -fyou are rejected and prompted that you have no permission, you need to add it to Zhang San Permissions (Project Settings -> Repository -> Protect Branch)

2. Roll back commits in special cases

The main basis for rollback is the commit id, but in some cases the previous commit id cannot be found through git log. For example, for a passed git commit --amendcommit, the new commit id will overwrite the previous one. How to do it? At this time, you can query the previous commit id through the index record, see the explanation below

1. Use git reflogthe index record of the query operation, as shown in the figure below, where the index id with the branch name in parentheses is the first 7 digits of the commit id, which can also be used for git reset. The current index id is 5042372 (at ②), find the place you want to roll back to (at ①, the index id is 51054e4)
insert image description here

2. Use git resetthe rollback to the state of the first submission

# 如果不加--hard,那么工作区的更改会被保留
git reset --hard 51054e4

V. Supplement

1. Analysis of the branch diagram of the process of Case 3

insert image description here

Guess you like

Origin blog.csdn.net/In_engineer/article/details/122175807