I recently worked on a small project with a teammate, and it was my first time using Git for actual collaboration rather than just making solo commits. To avoid forgetting the steps, I wrote down a few of the basic operations we used.
Let’s use a simple two-person collaboration setup as an example. Assume everyone involved has at least developer-level access to the project, and the remote repository is hosted on Gitee.
Setting up the remote and local repositories
Creating the remote repository directly on Gitee is straightforward. In this example, the remote already has two branches: master and dev.
To connect a local repository to it, the easiest way is to clone the remote project:
- Use
git clone XXXXXXXto download it locally and establish the link to the remote. - After cloning, only the default branch may be available locally. If the remote
devbranch is not present yet, create a localdevbranch, switch to it, and pull from the remote branch.
➜ test git:(master) git branch
* master
➜ test git:(master) git checkout -b dev
Switched to a new branch 'dev'
➜ test git:(dev) git pull origin dev
From https://gitee.com/bosichong/test
* branch dev -> FETCH_HEAD
Already up-to-date.
➜ test git:(dev) git branch
* dev
master
At this point, the local repository is connected to the remote one and ready for collaborative work.
How code updates work in collaboration
In a shared project, master is usually treated as the main branch. It should be updated carefully, often by a designated person, and used for stable releases.
Daily development happens on a branch like dev. Once enough work has accumulated and is ready, dev can be merged into master for a release.
Here’s a simple example.
Suppose we are building an AI encoder. My teammates and I are all coding at the same time. I create a branch called aicode, write a lot of code in ai.py, and when I’m done, I want those changes to go up to the remote dev branch.
The process is:
- Do the work on
aicode - Merge
aicodeinto my localdev - Push
devto the remote repository
➜ test git:(dev) git checkout -b aicode
Switched to a new branch 'aicode'
➜ test git:(aicode) touch ai.py
➜ test git:(aicode) ✗ vi ai.py
➜ test git:(aicode) ✗ git add .
➜ test git:(aicode) ✗ git commit -m 'aicode功能更新'
[aicode a1e0b50] aicode功能更新
1 file changed, 2 insertions(+)
create mode 100644 ai.py
➜ test git:(aicode) git checkout dev
Switched to branch 'dev'
➜ test git:(dev) git merge aicode
Updating 8fcac3b..a1e0b50
Fast-forward
ai.py | 2 ++
1 file changed, 2 insertions(+)
create mode 100644 ai.py
➜ test git:(dev) git push origin dev
Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 298 bytes | 298.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: Powered by Gitee.com
To https://gitee.com/bosichong/test.git
8fcac3b..a1e0b50 dev -> dev
That completes one round of updating. In practice, it’s quite simple.
What to do when a conflict happens
One time, my teammate and I both edited README.md. He handled the first half, and I handled the second half. He finished earlier and pushed his version first. I finished my part afterward and tried to push dev, but Git rejected it:
To https://gitee.com/bosichong/test.git
! [rejected] dev -> dev (fetch first)
error: failed to push some refs to 'https://gitee.com/bosichong/test.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
The message basically means the remote branch is newer than the one on my machine. Before pushing, I need to pull the latest changes first.
So I pulled dev, and then Git gave me this:
* branch dev -> FETCH_HEAD
99ccc9c..4c49e33 dev -> origin/dev
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.
This means the remote changes were fetched, but README.md has conflicting edits that Git could not merge automatically.
The file looked like this:
<<<<<<< HEAD
我更新的下半部分啊
=======
小伙伴更新的上半部分
>>>>>>> 4c49e33af00dd498b2d4761d3fc607ee29afbdf4
I resolved it by editing the file into this:
小伙伴更新的上半部分
我更新的下半部分啊
After fixing the conflict, I could commit again and push dev to the remote repository. Once you understand the pattern, collaborating with teammates becomes much smoother.
A pull error caused by local uncommitted changes
Another issue I ran into was this: a teammate updated the dev branch, but I couldn’t pull the changes locally. Git showed the following error:
Updating e32f487..204c0a1
error: Your local changes to the following files would be overwritten by merge:
Psmrcddup.py
Please commit your changes or stash them before you merge.
The problem here is that local modifications would be overwritten by the incoming merge, so Git stops the pull.
The way I handled it was:
➜ PrimarySchoolMath git:(dev) ✗ git checkout -f
➜ PrimarySchoolMath git:(dev) git pull gitee dev
A practical branching strategy
In real development, branch management should follow a few basic rules.
First, master should stay highly stable. In other words, it should mainly be used for releasing new versions, not for day-to-day development work.
So where should development happen? Usually, work starts from dev, and each person creates their own branch from there. When a feature is finished, it gets merged back into local dev, and then dev is pushed to the remote repository.
That also means dev is not meant to be fully stable at all times. When the project reaches a release point—say version 1.0—dev can then be merged into master, and the release is published from master.
In a team setup, everyone works from dev, each person keeps their own branch, and those branches get merged back into dev from time to time.
So the branch relationship in a team often looks like this:
A few common Git commands for collaboration
查看分支：git branch
创建分支：git branch <name>
切换分支：git checkout <name>
创建+切换分支：git checkout -b <name>
合并某分支到当前分支：git merge <name>
删除分支：git branch -d <name>
git remote 显示 远程仓库的分支
git remote -v 显示更详细的信息：
These are all basic operations, but for first-time team collaboration they cover many of the situations you’re likely to run into.