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 successfully creating it, return to local, and 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 Needed 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 after 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 next we will 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 was very smooth.
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, before pushing, need to pull first, then try to push.
First modify the file, let's assume we push directly to see what happens?
The previous steps are similar to git_learning_A, but an unexpected event 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 we will merge first.
git merge origin/feature/add_git_cmds:
After executing, 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, checking the local readme.md and xxx/css.x files, both are in the modified state, and now we can push directly.
git push:
Push successful! Collaborating on different files by different people is quite convenient, so isn't this method of collaboration very efficient? 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 in any repository, then push, keeping both repositories in sync. The readme.md file modification is as follows:
Because the files in the previous section were all 1 line, it was not possible 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 popped up, :wq to save and exit, indicating the merge was successful.
⚠️: Here, pulling directly will prompt that there is no clear pull strategy recommended.
-
You can manually configure the default strategy for pull.
-
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, checking the local readme.md file, it meets expectations, and we can push directly:
This method of collaboration is also quite smooth, and Git has the capability 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 need to be resolved manually.
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 used git pull with the option --no-rebase, indicating that we are pulling using the merge method.
Immediately, a conflict occurred, and we need to resolve it ourselves before committing.
vim readme.md, open the file with conflicts:
The conflict positions have obvious markers, where HEAD and === represent the local code, and the hash value and === represent 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 red box indicates that a merge is in progress; the lower one indicates canceling the merge and returning to the state before the merge.
Here we will practice the upper one. ⚠️: 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 smart, nor does it need to be that smart, because it definitely doesn't know whose code should be kept.
37 | How to handle changes to both the filename and file content at the same time?#
Conclusion first: Just merge directly.
git_learning_A: Changed the filename of xxx/css.x to xxx/css2.x.
Do you remember the git mv command? You can jump back to 1 Git Basics--06|A Convenient Method for Renaming Files for a review.
git_learning_B: Modified the content of xxx/css.x (not knowing that the filename has already been changed).
Cool～Git can automatically resolve such issues. Check the merge situation:
You can see that not only has the filename 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 filenames?#
Conclusion first: Conflicts will occur during merge, and need to be resolved manually.
git_learning_A: Changed the filename of xxx/css2.x to xxx/cssA.x.
git_learning_B: Changed the filename of xxx/css2.x to xxx/cssB.x. (not knowing that the filename has already been changed).
A conflict has occurred～
Check the file situation:
You can see that Git's approach is to simultaneously retain both modified filenames, and the contents of both files are identical.
Through git status, it clearly tells us the situation of the filename changes 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?