Repository setup, branching, pull requests, reviews, and issues
This session turns version control into a team workflow. The goal is not only to push code, but to make changes traceable, reviewable, and easy to merge.
Create the repository, fill in the basics, and decide who owns the remote.
Invite teammates first. Review only works if the right people can see and comment on the code.
Work in VS Code or the terminal from a local clone, not by editing files in the browser.
Create a simple README or starter file once, then push it so everyone starts from the same baseline.
git clone <repo-url>
git checkout -b feature/short-task-name
git add .
git commit -m "Implement the first draft"
git push -u origin feature/short-task-nameDo not work directly on main. Each branch should map to one small task so the review is focused and conflicts stay manageable.
The base branch should be main. The compare branch should be the feature branch you just pushed.
The title states the change. The description explains the intent, what changed, and what needs review.
Assign the person doing the work and the person who will review it.
Use [WIP] in the title when the branch is not ready for review yet.
Review only the diff against main, not the whole repository.
Comment directly on the lines that need clarification or revision.
Choose comment, approve, or request changes based on the actual state of the branch.
Once comments are resolved and the team agrees, merge and stop working on that branch.
Describe one task or bug clearly and assign it to one person.
Create a dedicated branch to address that issue only.
Open a PR from that branch and mention the issue number in the description.
After the PR is merged, the issue becomes the record of why the change happened.
main locally after a merge.main,Applied Math Lab