Working as a team: branches, merges and conflicts

Why branches exist

Alone, you can work on the main branch. The moment there are two of you it begins: one commits, the other pulls, and both are broken.

A branch is a separate line of work. You do your task in your branch without disturbing anyone. When it's done, the changes move into the shared branch.

That's the basis of all collaborative work with code, and without understanding branches you won't be taken onto a team.

The usual flow

Fetch the current state of the shared branch:

git checkout main
git pull

Create a branch for the task:

git checkout -b feature/expense-export

Name it after the task, not "my-branch-2".

Work, committing in pieces:

git add .
git commit -m "add expense export to a file"

Push your branch:

git push -u origin feature/expense-export

Then you open a merge request on the platform, colleagues review the changes, you answer comments, and the changes land in the shared branch.

Rules that save a team

Don't work on the main branch. Ever, not even for a small fix.

Pull before starting. A branch created from a stale state guarantees conflicts.

Keep branches short. Two or three days of work. A branch alive for a month diverges so far that merging becomes agony.

One branch, one task. Don't sweep everything you noticed into it.

What a conflict is

A conflict arises when two people changed the same place differently and the system can't decide whose version is right.

It isn't a breakage or anybody's mistake. It's a normal part of the work.

Resolving a conflict

During a merge you'll see files with markers: your version, their version, and a separator.

The steps:

1. Open the file and find the markers.
2. Decide what should remain. Sometimes yours, sometimes theirs, most often a combination.
3. Remove the markers completely. A forgotten marker breaks the code.
4. Check that it works. Actually run it, don't eyeball it.
5. Commit the result.

If the conflict is large and unclear, don't guess — ask whoever wrote the other changes. That's normal and faster than working it out alone.

Avoiding conflicts

• Agree who touches which files. Half of all conflicts come from two people entering the same place.
• Pull from the shared branch often. Daily, not weekly.
• Make tasks smaller. The shorter a branch lives, the less it diverges.

What to say at interview

"Tell me how you worked with branches" gets asked almost every time, and the answer immediately reveals whether someone worked in a team or only alone.

Experience of building something together — even a learning project — lets you answer concretely: how branches were named, who reviewed changes, what you did about conflicts. That sounds entirely different from reciting a textbook.