Checklists

Six lists for the six moments where forgetting something costs real time. They are deliberately short: a checklist you skip is worse than none.

A new computer

Install Git, and confirm with git --version.
Set your identity: git config --global user.name and user.email, using an address verified on the platform.
Set the sensible defaults: init.defaultBranch main, pull.rebase, merge.conflictstyle zdiff3, fetch.prune true.
Choose your editor: git config --global core.editor "code --wait" or your preference.
Create an SSH key, add it to the agent, and upload the public half to each platform you use.
If you have work and personal identities, set up includeIf by folder now, before the first commit.
Turn on two-factor authentication if it is not already.
Install the linters your projects use, so your editor warns you before the pipeline does.

Clone it, and open the folder that contains .git.
Read README.md, then CONTRIBUTING.md in full.
Look for CODEOWNERS, issue and merge request templates, and .editorconfig.
Run git branch -r to see the long-lived branches, and work out the branching strategy.
Find out how to run the project, and run it once.
Read .gitlab-ci.yml or .github/workflows/, and run their commands locally once.
Check what access you have, and ask for the role you need, naming what you need to do.
Find the definition of done, or ask for it.

Add them to the right team or group, at the least role that lets them work.
Point them at CONTRIBUTING.md, and fix it if it is out of date.
Tell them the branching strategy and the naming convention in one sentence each.
Tell them how to run the project and how to run the checks locally.
Give them a first issue that is real, small, and touches documentation.
Offer to review their first merge request quickly, and say so.
Tell them who to ask, and where: the issue, not a private message.

git status is clean and everything intended is committed.
The branch is named by the convention, with the issue number.
The branch is up to date with main, or the platform's update button says so.
You have read your own diff, all of it.
The pipeline's own commands pass locally.
The description says what, why, how to check, and closes the issue.
Reviewers are requested in the sidebar, not in chat.
Documentation and changelog entries are in the same change, if the team expects them.

The pipeline is green, and you have looked at what it checked.
Every review thread is answered or resolved.
The required approvals are in.
The branch includes current main, if the rules require it.
The merge option is the one your team uses, and the squash message is a real message.
Delete source branch is ticked.
The issue will close, because the description says Closes #N.

In this order, and the first item is the one that matters:

Rotate the credential now. Revoke the old one and issue a new one. Assume it is public.
Tell whoever owns that credential, and your security contact if you have one.
Update the places that use it: CI/CD variables, deployment configuration, colleagues.
Add the file to .gitignore and remove it from tracking with git rm --cached.
Only then consider cleaning history, and only as a planned operation with the whole team.
Write down how it happened, and add a check that would have caught it.