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
- Git Basics: Your First Commands โ start here if the everyday loop is still new.
- Multiple GitHub Accounts with SSH โ one machine, more than one account.