Get to Know GitHub 5: What stays out and where work goes
Slides 11 to 13 (three things that never go in, committed a secret anyway, making your own repo). 0:37 to 0:43.
What this section has to do
Two jobs. First, make the never-commit list stick, with real examples from marketing work, and make it safe to admit a mistake. Second, show exactly how people make their own repo, so the homework doesn't stall on the first screen.
Never commit
| What | Real examples from our work | What to do instead |
|---|---|---|
| Passwords, keys, tokens | An OpenAI or Anthropic API key pasted at the top of a script. A Google Ads developer token. A Meta access token in an Apps Script. A login in a config file | Use a placeholder like YOUR_API_KEY_HERE. Real keys live in LastPass, or ask the dev team where they belong |
| Client data | A CSV export from an ad account. A customer list. Pasted client emails. A sheet with lead names and phone numbers used as test data | Test with dummy data, like the alias account from the governance meeting |
| Personal stuff | Your own logins. Private details about someone, like HR, health or home addresses | Leave it out. Notes on client work are fine |
A quick test people can use: "Would I be OK if this file showed up on a screen share in front of the client?" If not, it doesn't go in.
Committed a secret anyway (slide 12)
Tone matters more than content here. Say it plainly and kindly:
- Tell the dev team right away. Nobody's going to be mad, we just need to move fast.
- Deleting the file doesn't fix it. Git keeps every version, so the key has to be rotated, which means the old one gets turned off and a new one is made.
- It happens, we've all done it. We fix it and move on.
If you have a true story about a key leak you've handled, a one-sentence version lands well here. Keep client names out of it.
How Gitleaks fits
- Every repo made from AIMCLEAR's template (github.com/aimclear/employee-repo-template) brings the Gitleaks workflow along. It runs on GitHub for every push, browser uploads included, and flags things that look like keys and passwords before anything gets merged into main.
- If it flags something, the check goes red on the PR. Stop, don't merge, and ask the dev team. A flagged key has already left the laptop, so it still needs rotating (the old key gets turned off and a new one is made).
- With Gitleaks on your laptop (commits from GitHub Desktop or Claude Code, with a hook set up), it runs before each commit and catches a key before it leaves. The dev team can help set that up. Desktop has a Bypass Commit Hooks option. Don't use it.
- Gitleaks catches patterns that look like secrets. It doesn't catch client data. For client data, use the checklist above.
Making your own repo (slide 13)
To make your own repo, open github.com/aimclear/employee-repo-template and hit the green Use this template button, then Create a new repository. It's a different repo from the practice one, there so everyone starts from the same setup. Your new repo brings the Gitleaks check along, and an AIMCLEAR org rule protects main. Then three choices:
- Owner: AIMCLEAR. Not your personal account. In the org, the team can find your work, and it can be audited.
- Visibility: Private. Public means anyone on the internet can read it. Nothing gets flipped to public without asking first.
- What goes in: your stuff. The stuff you built with AI. If you've built it and you might use it again, it goes in AIMCLEAR's GitHub. Don't download something you found online and run it. New tools get approved first, per the new software policy.
Naming. Suggest one convention so the org stays findable. Something like yourname-scripts for a personal toolbox, or a plain-words name for a tool a team shares (weekly-report-builder). Pick one and put it on the slide or in the follow-up email.
One repo or many? Start with one personal repo for everything. Split a tool into its own repo when other people start using it.
README. Every script gets a line or two in the README: what it does, how to run it, who owns it. Claude can write this for them (see section 7).
Likely questions
- "What about scripts that need a key to run?" The script reads the key from somewhere outside the repo. The dev team can help set that up. Until then, the script goes in with a placeholder.
- "Is a client name in a filename a problem?" Client names are fine. Client data is not.
- "What if I'm not sure?" Leave it out and ask. Adding later is easy. Taking out of history is not.
- "Can I make it public to share it with a client?" No, not without asking first. There are other ways to share.
Done when
People can name the three things that never go in, know who to tell if something slips, and know the first three choices when they make their own repo.