Every team has its own rules. Look for a CONTRIBUTING.md file, and read git log --oneline on main to copy the style you see. The course's lab kit (the Github_Learning folder from Day 1) has ready-made examples in samples/.
Thing
Common convention
Example
Branch name
type/issue-short-description, lowercase with hyphens
Review is how a team shares knowledge. Comment on the code, never the person, and label how important each comment is:
Label
Means
Example
blocking:
Must change before merging
blocking: this reads the password from a file in the repo. Could we use an environment variable?
suggestion:
Worth considering, the author decides
suggestion: sum() might read more clearly than the loop.
question:
You want to understand
question: why do we round before tax, not after?
nit:
Tiny, optional
nit: typo in the docstring.
praise:
Something done well
praise: great test name.
Receiving review: say thanks, reply to every comment ("Done in a1b2c3d" or why not), and push fixes as new commits on the same branch. If a thread goes back and forth more than twice, have a quick call instead.
Every commit records user.name and user.email, and GitHub links commits to accounts by that email. Your global settings may use a personal address. At work, company repos should get your work email. Git can switch automatically based on the folder a repo lives in.
Keep all work repos under one folder, for example C:\work\.
Create the file .gitconfig-work in your home folder with VS Code: code $HOME\.gitconfig-work. Put these lines in it:
[user]
email = you@yourcompany.com
Tell Git to use that file for every repo under C:\work\: git config --global includeIf.gitdir/i:C:/work/.path '~/.gitconfig-work'
Check it: inside a work repo, git config user.email shows the work address. Anywhere else, it shows your personal one.
