Version Control Using GitHub, Part 2: Branches, Pull Requests and Releases

A conflict, made and resolved

A conflict happens when two branches change the same lines. It is not a failure, and it is not rare: it is Git refusing to guess.

$ cd ~/team-repo
$ git switch -c feature/more-slots
Switched to a new branch 'feature/more-slots'
$ sed -i 's/^slots: .*/slots: 12:30 12:40 12:50 13:00 13:10/' rules.txt
$ git commit -q -am "Offer a fifth pickup slot"
$ git switch main
Switched to branch 'main'
$ sed -i 's/^slots: .*/slots: 12:30 12:45 13:00/' rules.txt
$ git commit -q -am "Reduce to three pickup slots"
$ git merge feature/more-slots
Auto-merging rules.txt
CONFLICT (content): Merge conflict in rules.txt
Automatic merge failed; fix conflicts and then commit the result.
$ cat rules.txt
<<<<<<< HEAD
slots: 12:30 12:45 13:00
=======
slots: 12:30 12:40 12:50 13:00 13:10
>>>>>>> feature/more-slots
cut-off: 15 minutes before the slot

Git has written both versions into the file, between markers: everything between <<<<<<< and ======= is what main says, and everything to >>>>>>> is what the branch says. Nothing is lost, and nothing is decided.

Resolving it is editing the file to what it should be, and committing:

$ cd ~/team-repo
$ printf 'slots: 12:30 12:40 12:50 13:00 13:10\ncut-off: 15 minutes before the slot\n' > rules.txt
$ git add rules.txt
$ git commit -q -m "Merge: keep the five slots the owner asked for"
$ cat rules.txt
slots: 12:30 12:40 12:50 13:00 13:10
cut-off: 15 minutes before the slot
$ git --no-pager log --oneline --graph | head -6
*   e322b14 Merge: keep the five slots the owner asked for
|\
| * e9fe3cc Offer a fifth pickup slot
* | 464d646 Reduce to three pickup slots
|/
* e3c3f51 Add the cut-off rule
$ git branch --merged main | tr -d ' ' | tr '\n' ' '
feature/cutoff feature/more-slots *main

The decision is the team's, not Git's. Here the owner had asked for five slots, so the branch's version won; the resolution's message says so, which is what makes the history readable later. And git branch --merged lists what has been merged and can be deleted: branches are cheap, and leaving a dozen stale ones is untidy.

Two habits that prevent most conflicts: pull before you start, and keep a branch short. A branch that lives for two weeks will conflict; one that lives for a day rarely does.

Pull requests

A pull request is a branch offered for merging, on GitHub, with the diff, the discussion and the checks in one place. A book cannot open one, so here is what the worked team did and what each part is for.

The one command a student runs locally is to push the branch:

git push -u origin feature/order-transaction

GitHub then offers to open the pull request. The rest is on the website:

The worked pull request, the one Prof. Iyer looked at in the code review (Chapter 49): Farhan's ordering change, reviewed by Rohan, three comments, two taken.

• "What happens if the second item is short?" Answered, and a test was added: the one that proves the stock is untouched (Chapter 45).
• "refusal() reads the item again inside the transaction. Is that needed?" Yes: it is what turns "no rows changed" into the right message, sold out or unavailable, and the comment above it now says so.
• "Could place() be shorter?" Not taken, and the reason was recorded: splitting the transaction across two functions would make it easy to end it in the wrong place.

A review is a conversation, not a verdict, and its record in the pull request is evidence for the examiner that the team read each other's code.

Protecting main

GitHub can require that main is changed only through a pull request, and that someone other than the author approves it. For a team of four it takes a minute to switch on and it makes the rule real instead of merely agreed.

Releases

When there is a version worth naming, tag it:

$ cd ~/team-repo
$ git tag -a v1.0 -m "The version submitted for Mini Project I"
$ git --no-pager tag
v1.0
$ git --no-pager show v1.0 --stat | head -5
tag v1.0
Tagger: Aditi Kulkarni <aditi@college.example>
Date:   Tue Sep 29 10:30:17 2026 +0530

The version submitted for Mini Project I

git push origin v1.0

A tag is a name for one commit, and it does not move. On GitHub a tag can be published as a release, with notes and files attached; for this paper the useful attachment is the signed APK (Chapter 59), so that an examiner can download exactly the file that was demonstrated.

What to tag in a mini project: the version shown at each increment review, and the version submitted. Three tags are plenty, and v1.0 on the submitted commit is the one that matters: it says precisely which state of the code the report describes.

What the examiner sees

Chapter 72 is about the repository as a deliverable, and branches, pull requests and releases are most of what it shows:

• branches that were merged and deleted, which means work was organised;
• pull requests with review comments, which means the team read each other's code;
• issues closed by commits, which means defects were tracked (Chapter 56);
• a tag on the submitted version, which means the report and the code agree.

Do this for your project

1. Keep main working, and do every piece of work on its own short-lived branch.
2. Name branches after the work, with the issue number when there is one.
3. Pull before you start; merge promptly; delete merged branches.
4. Open a pull request for every change, and have someone else read it.
5. Resolve conflicts by deciding, and say in the merge message what you decided.
6. Protect main so that the rule is enforced, not merely agreed.
7. Tag the version you submit, and attach the APK to the release.

Mistakes that cost marks

Everyone committing to main, and a broken main on the day of the demonstration.

A branch that lives for a month, whose merge is a day of conflicts.

Conflict markers committed, so <<<<<<< appears in the submitted code.

Pull requests merged by their own author with no review, which wastes the practice and the evidence.

No tag, so nobody can tell which commit the report describes.

--force pushes to shared branches, which quietly destroy other people's work.

Quick revision

• A branch per piece of work, named after it; main always works.
• git switch -c makes one; git merge joins it; a fast forward when main has not moved.
• A conflict is Git refusing to guess: both versions are written between markers, and you decide.
• Pull requests: push the branch, then title, description with "Closes #n", a reviewer, the diff, comments, merge on approval; protect main.
• Tag the submitted version (git tag -a v1.0), publish it as a release, attach the APK.
• Prevent conflicts: pull before you start, keep branches short.

Questions you must be able to answer

1. Why does a team work on branches rather than all on main? So that unfinished work never breaks the line everyone shares and everyone deploys. Each person's work is separate until it is finished and reviewed, and main can always be demonstrated.

2. What is a merge conflict, and whose job is it to resolve? It happens when two branches change the same lines, and Git will not choose between them. It writes both versions into the file between markers, and a person decides what the file should say, then commits the result.

3. What is a pull request, and what belongs in one? A request to merge a branch, on GitHub, with the diff and the discussion attached. It should carry a title saying what the change does, a description with why and a link to its issue, a reviewer who did not write it, and the review's comments and their answers.

4. Why protect the main branch? So that the team's rule, nothing merged without a review, is enforced by the tool rather than remembered by people at midnight before a deadline.

5. What is a tag, and which commits should be tagged in a mini project? A fixed name for one commit. Tag the version shown at each increment review and, most importantly, the version submitted, so that the report, the demonstration and the code can be shown to be the same thing.

6. Why are short-lived branches better than long ones? Because the longer a branch lives, the more the main line moves under it, and the more lines both have changed. A branch merged the day it is written rarely conflicts at all.