When someone else is working too

Written by a person. Last read by a person on 2026-09-05, 3 days ago. Its facts were checked by the eval suite on 2026-09-07.

A colleague changed the same document you are editing, your push was refused because the shared copy moved, you want to work on something without disturbing what everyone else is using, or your change needs a second pair of eyes before it lands.

Everything on the previous pages assumed you were the only person working. That assumption is what makes git seem manageable, and it is almost never true.

These four situations get harder in order. Each one adds exactly one idea to the one before, and the last one is where branches finally earn their keep. Read them in order the first time.

Someone changed it before you did

The situation. You and a colleague both look after the department handbook, working on it separately. You open it on Monday, make your edits, and try to push, and git refuses to accept them.

What you see.

! [rejected]        main -> main (fetch first)

What it means. GitHub's copy has entries that yours does not, because your colleague pushed on Friday while you were not looking. Nothing is broken and nothing has been lost. Your copy is behind theirs, which is the normal state of affairs and the reason git pull exists.

What to do.

git pull
git push

Why that works. git pull brings their entries into your history and replays yours on top. You now hold both sets of entries, and the push is accepted because your history contains everything GitHub's does.

You edited a different section, so the two sets of changes never touched. Git can combine them without asking you anything. This is the ordinary case, and it is most of them.

You both changed the same paragraph

The situation. Same handbook, same Monday, except you both rewrote the leave policy.

What you see. git pull stops and says the file has a conflict. Opening it shows this:

<<<<<<< HEAD
Staff may carry over five days.
=======
Staff may carry over ten days, with approval.
>>>>>>> origin/main

What it means. Git will combine work in different places without asking. It will not choose between two versions of the same sentence, because that is an editorial decision and it is not qualified to make it. It has stopped and handed you both.

What to do. Decide what the sentence should say. Delete the markers and the version you do not want, leaving the text you do. Then:

git add handbook.md
git commit
git push

The part nobody says out loud. You are allowed to write something neither of you wrote. The markers are a question, not a menu.

If the answer is not yours to make, stop and ask your colleague. Leaving the file conflicted while you talk costs nothing.

Working without disturbing anyone

The situation. You want to restructure the whole handbook, which will take a fortnight and will look wrong somewhere in the middle of that. Everyone else is still using it while you work.

What a branch is. A named line of history that starts from the shared one. Your entries go onto it instead of onto main, and nobody sees them until you say so.

flowchart LR
  A["main"] --> B["main"] --> C["main"] --> F["main<br/>(with your work)"]
  A --> D["your branch"] --> E["your branch"] --> F

What to do.

git switch -c handbook-restructure

Work normally on your branch, adding, committing and pushing exactly as you would otherwise. The only difference is the first push, which has to say where it is going:

git push -u origin handbook-restructure

Why this is the answer to the previous section. A conflict happens when two people change one thing at once. A branch does not prevent that, but it moves the argument to a moment you choose, rather than a Monday morning when you were trying to do something else.

What it costs. Your branch drifts from main while you work. The longer you stay on it, the more there is to reconcile at the end. A fortnight of drift is usually fine, whereas six months of it is a different problem altogether.

Getting it looked at before it lands

The situation. The restructure is finished, and you would like somebody to read it before it becomes the handbook everyone else has to use.

What to do. On GitHub, open a pull request from your branch to main. A pull request is a request that your branch be pulled into the shared one, and it is where the conversation happens.

What it is really for. Not approval. It is the place where the change and the discussion of the change live at the same address, permanently, so that in a year the answer to "why is it like this" is one click from the thing itself.

What to expect. Comments on specific lines, which you answer in the thread or address by changing the text, and both of those are normal. When it is agreed, the pull request is merged, and your branch's entries join main.

Then delete the branch. It has done its job, and its work is in main now. Keeping it around is how people end up unsure which line of history is the real one.

What this page does not cover

Rebasing, force pushing, and rewriting shared history. All three change entries other people may already have, and all three deserve a conversation before a command.

If somebody tells you to run git push --force, that is a reasonable thing to be asked and a reasonable thing to check first. Ask what it will do to the copies other people are holding.