Back to Blog
Published on 9 July 2026GitDev ToolsTeamwork

๐Ÿค Working with Git in a Team

Once you're comfortable with the basics, the next challenge is working alongside other people ๐Ÿ˜„. These are the commands I reach for every day on a shared branch.

๐ŸŒฟ Work on a branch

Instead of committing straight to master, create a branch for each feature or fix:

git checkout -b new-branch-name

This keeps your work isolated until it's ready to merge.

๐Ÿงน Pull with rebase to keep history clean

When several people work on the same branch, a plain git pull creates extra "merge commits" that clutter the history. Pulling with rebase replays your commits on top of the latest changes instead:

git pull --rebase

The result is a straight, readable history.

๐Ÿ“ฆ Update while keeping your local changes

You often want the latest code but you're in the middle of something uncommitted. Stash your changes, pull, then put them back:

git stash && git pull --rebase && git stash pop

git stash tucks your uncommitted work aside, and git stash pop restores it afterwards.

Need to switch to master and update it without losing your work-in-progress? Chain it in one line:

git stash && git checkout master && git pull --rebase && git stash pop

๐Ÿ’ก IDE tip: Some editors do this for you. In IntelliJ IDEA, just press Update Project โ€” it asks whether you want to merge or rebase, then stashes and un-stashes your local changes automatically. In VS Code this isn't as smooth: you have to run the stash, pull, and un-stash steps manually yourself.

โš”๏ธ Resolving merge conflicts

Sooner or later, two people change the same lines and Git can't decide who wins ๐Ÿ™ˆ โ€” that's a conflict. Git marks the spot in the file like this:

<<<<<<< HEAD
your version
=======
their version
>>>>>>> branch-name

๐Ÿ’ก Tip: Before you resolve anything, open the repository in your hosting app (GitHub, GitLabโ€ฆ) and look at the recent commits or the Pull Request's Files changed tab. Seeing exactly what your teammates changed โ€” and why โ€” makes it much easier to understand both sides and pick the right final version for your merge.

Don't panic. Open the file, decide what the final code should be, and delete the <<<<<<<, =======, and >>>>>>> marker lines. Then stage the resolved file:

git add app/contact-form.js

Then continue the operation you were in the middle of:

git rebase --continue   # if you were rebasing (e.g. after pull --rebase)
git merge --continue    # if you were merging

If things get messy and you'd rather start over, back out safely:

git rebase --abort      # or: git merge --abort

This returns you to the state before the operation, with nothing lost.

๐ŸŽฏ The takeaway

Branch your work, pull --rebase to stay current with a clean history, use stash to move around freely, and treat conflicts as a normal, recoverable part of teamwork.

๐Ÿ“š Read next