Scenario: Simulating two people maintaining the same Git branch.
First, create a new branch feature/add_git_cmds based on master in the Github repository, and click Create branch:
After successful creation, return to local, pull two repositories locally to simulate two people developing.
Don't forget to set different users for the two people～
Let's first look at the global configuration of the Git repository ( --global ):
We let git_learning_A use the default global user configuration and set a local user configuration for git_learning_B ( --local, which takes precedence over global configuration):
(Configuration can refer to 1 Git Basics--03|Minimum Configuration Required Before Using Git )
Finally, in both local repositories, create a corresponding local branch based on the remote feature/add_git_cmds branch.
Command: git checkout -b feature/add_git_cmds origin/feature/add_git_cmds, this command will create a local branch named the former based on the latter remote branch, track the remote branch, and switch to the newly created branch.
Perform the same operation on both local repositories.
At this point, we have simulated the scenario of two people developing on the same branch of the same repository, and now let's experiment with five different situations one by one🧪!
34 | How to handle different people modifying different files?#
Conclusion first: Just merge directly.
git_learning_A: Modified the readme.md file and pushed it to the remote.
git push went smoothly.
Check the remote repository:
Check the author of the commit record, corresponding to the global user configuration used by git_learning_A:
git_learning_B: Modified another file xxx/css.x, and before pushing, needs to pull first, then try to push.
First modify the file, let's assume pushing directly, and see what happens?
The previous steps are similar to git_learning_A, but an unexpected error occurred during git push, doesn't it seem familiar? The error is exactly the same as mentioned in the previous chapter: 3 Simple Synchronization of Git and GitHub--33|Syncing Local Repository to GitHub.
❌: git push -f force push.
✅: Pull first, then merge, then push.
git fetch :
You can see that the latest commit hash has been updated from d7d648a to 192a3b3.
In the branch description, it shows that the current branch and the remote branch status is: ahead 1 (local has updates that I have not pushed to remote), behind 1 (remote has updates that I have not merged into local), so let's merge first.
git merge origin/feature/add_git_cmds :
After execution, a commit message editor will pop up, you can keep the default or add a description as appropriate.
:wq to save and exit, you can see the merge was successful and the modification records.
The blue line shows that currently ahead 2, meaning the local has two more commits that have not been pushed to the remote;
The red box indicates the 2 commit records that are ahead.
At this point, check the local readme.md and xxx/css.x files, both are modified, and now you can push directly.
git push :
Push successful! Collaborating on different files is quite convenient, so isn't it efficient to work collaboratively in this way? Let's look at other situations～
35 | How to handle different people modifying different areas of the same file?#
Conclusion first: Just merge directly.
⚠️: First create an environment with different areas, add multiple lines in the readme.md file of any repository, then push, keeping both repositories in sync. The readme.md file is modified as follows:
Because the files in the previous section only had 1 line, it was impossible to modify different areas.
git_learning_A: Modified line 4 of readme.md and pushed directly.
git_learning_B: Modified line 7 of readme.md, pulled first, then pushed.
During git pull, after the commit message editor pops up, :wq to save and exit, indicating the merge was successful.
⚠️: Directly pulling here will prompt that there is no explicit pull strategy recommended.
-
You can manually configure the default strategy for pulling.
-
Or add options after the
git pullcommand, such as--rebase,--no-rebase,--ff-only. -
Or use
git fetchfirst, then choose a merge strategy.
At this point, check the local readme.md file, it meets expectations, and now you can push directly:
Collaboration in this way is also quite smooth, as Git has the ability to merge automatically～
36 | How to handle different people modifying the same area of the same file?#
Conclusion first: Conflicts will occur during merge, and you need to resolve them yourself.
git_learning_A: Modified line 1 of readme.md and pushed directly.
⚠️: Don't forget to perform git pull first, as the updates made by git_learning_B have not been synchronized yet.
git_learning_B: Also modified line 1 of readme.md, pulled first, manually resolved the conflict, then pushed.
This time we performed git pull with the option --no-rebase, indicating that we want to pull using the merge method.
Immediately, a conflict occurred, and we need to resolve the conflict ourselves before committing.
vim readme.md, open the file that has conflicts:
The conflict positions have obvious markers, with HEAD and === indicating the local code, and the hash value and === indicating the incoming code.
We need to modify this part of the code and remove these special markers, we can modify it like this: (In actual development, remember to communicate with relevant personnel before making modifications❗️)
After saving and exiting with :wq, check the repository status with git status:
The upper part in the red box indicates proceeding with the merge; the lower part indicates canceling the merge and returning to the state before merging.
Here we will practice the upper option. ⚠️: At this point, the modification is still in the working directory, we need to add it to the staging area before committing.
First add and commit, then push:
PS: -am includes both adding and committing operations.
This time we find that Git is not that intelligent, nor does it need to be, because it certainly doesn't know whose code should be kept.
37 | How to handle changes to both the file name and file content simultaneously?#
Conclusion first: Just merge directly.
git_learning_A: Changed the file name from xxx/css.x to xxx/css2.x.
Do you remember the git mv command? You can jump back to 1 Git Basics--06|Convenient Method for Renaming Files for a review.
git_learning_B: Modified the content in xxx/css.x (not knowing that the file name has been changed).
Cool～Git can automatically resolve such issues. Check the merge situation:
You can see that not only has the file name been changed, but the modifications in the file have also been retained.
Essentially, this is modifying different areas of the same file～
38 | How to handle changing the same file to different file names?#
Conclusion first: Conflicts will occur during merge, and you need to resolve them yourself.
git_learning_A: Changed the file name from xxx/css2.x to xxx/cssA.x.
git_learning_B: Changed the file name from xxx/css2.x to xxx/cssB.x. (not knowing that the file name has been changed).
A conflict has occurred～
Check the file situation:
You can see that Git's approach is to simultaneously retain both modified file names, and the contents of both files are identical.
Through git status, it also clearly informs us of the file name change situation and what we can do.
git rm the unnecessary file, git add the file you want to keep, commit, and push!
After looking at these scenarios of Git collaboration, are you no longer afraid of resolving conflicts?