Collaboration: remotes, pull requests and branching strategies

Remotes: fetch, pull and push

A remote is a named link to another copy of the repository. When you clone, Git creates a remote called origin pointing at the URL you cloned from. Git also keeps remote-tracking branches such as origin/main: your local record of where main was on the server the last time you talked to it.

git remote -v                    # list remotes and their URLs
git fetch origin                 # download new commits; updates origin/main, does NOT touch your files
git pull                         # fetch + merge origin/main into your current branch
git pull --rebase                # fetch + rebase your local commits on top instead
git push -u origin feature/upi   # upload a branch and set its upstream
git push                         # later pushes need no names

fetch is always safe: it only downloads. pull changes your branch, so it can cause conflicts. Many developers fetch first, look at git log main..origin/main to see what is new, and then merge or rebase.

Forks

You cannot push to a repository you do not have write access to, such as an open-source project. A fork is your own copy of it on GitHub. You push to your fork and open a pull request back to the original. By convention, your fork is origin and the original project is added as a second remote called upstream, so you can fetch its latest changes.

Pull requests and code review

A pull request (PR, called a merge request or MR on GitLab) asks to merge one branch into another. It shows the diff, runs automatic checks such as tests and linting, and lets teammates comment line by line. Only after approval and green checks is it merged.

• Keep PRs small: a few hundred lines at most. Reviewers find more problems in small PRs and review them faster.
• Write a description: what changed, why, how you tested it, and screenshots for UI changes. Link the issue or ticket.
• As a reviewer, comment on the code, not the person. Ask questions ("What happens if the UPI callback times out?") rather than giving orders, and label small preferences as "nit:" so the author knows they are optional.
• As an author, reply to every comment, push fixes as new commits, and do not take feedback personally.

Protected branches and required checks

On GitHub and GitLab, an admin can protect main with branch protection rules (GitHub also has the newer rulesets). Typical rules: changes only through PRs, at least one approval, required status checks (the CI pipeline must pass), branch up to date before merging, and no force pushes or deletion. This turns team agreements into rules the platform enforces.

A CODEOWNERS file (in .github/, the root or docs/) maps paths to the people or teams who own them, for example /payments/ @acme/payments-team. GitHub automatically requests their review, and a protection rule can require their approval.

Branching strategies

A feature flag is a setting in code that switches a feature on or off at runtime. With flags, half-built code can be merged and deployed safely while switched off, and then turned on for 5% of users, then everyone. This is what makes very short-lived branches practical. Gitflow adds overhead and long-lived branches; even its author has said simpler flows suit web apps that deploy continuously.

Conventional Commits

Conventional Commits is a simple, widely used format for commit messages that both humans and tools can read.

type(scope)!: description

feat(cart): add UPI QR payment option
fix: round GST to two decimals on invoices
docs(readme): explain local setup
refactor(api)!: rename /orders to /v2/orders

BREAKING CHANGE: clients must call /v2/orders

feat (a new feature) and fix (a bug fix) are defined by the specification; teams commonly add docs, chore, refactor, test, ci, build and perf. Because the format is predictable, release tools can work out the next version number and write the changelog automatically, as the next lesson shows.

Common mistakes and how to fix them

• Huge PRs that sit for a week: split them, and use feature flags so parts can be merged early.
• Working on an old copy of main: fetch and update your branch daily.
• Approving without reading: if you approve, you share responsibility. Run the code if the change is risky.