-
Notifications
You must be signed in to change notification settings - Fork 0
Description
π€·ββοΈ Why
Git is a tool that creates results: Commits, tags, and branches. You could argue; as long as the result is compliant with the team's worthy-for-trunk quality, then you don't care what process led to the result.
But then again. Making sure that git works the same way for everyone in the team, essentially standardize the way you work, makes it much easier to continuously assess and improve the process and develop an explicit vocabulary and command set for how you work when you achieve the results.
Note
Git is configured by the gitconfig|.gitconfig file and it comes in three standard flavors:
system(same folder at thegitexecutable)global(current user's$HOME)local(current repository's.gitfolder)
Unfortunately there is no default location that supports what we really: The repository root.
Tip
Git config supports extensions by other files through include.path.
Run:
git config --local --add include.path ../.gitconfig
...and the config file in your repo's .gitfolder will read the .gitconfig file in you repo root - if it exists.
Git hooks are amazing - especially pre-commit, but they are not widely used, which is a shame, as a local script performs 10-100 times faster than a GitHub workflow with the same function and it runs before you commit any potential faults β not after. Running AI in agentic mode is usually detached from your main - on a separate branch, and any checks that occur runs after the commit. So the pre-commit hook has the potential of a big revival in the age of AI bots and can really boost the quality od the work your AI bots do for you.
Tip
When you create the pre-commit hook. Rather than hacking the hook directly, create a generic - reusable - scripts that you call (source) from the hook.
We may find good use of this check, even outside the context of the pre-commit hook.
π¬ Prompt
Create a script 'trunk-worthy' that checks if the repo's current state is trunk
material (linters, formatters, builds, unit tests, coverage). Create a 'pre-commit'
hook in a dedicated folder. Let the hook call the trunk-worthy script. Create a .gitconfig
file in the root of the repo, with general settings and nice, widely used aliases,
and which also sets the githooks path to the folder where you put the pre-commit hook.
Also create a postCreateCommand.sh script that makes the local git config file include
the one in the repo, and make the devcontainer.json run this script as the postCreateCommand.
Finally create a good, standard, generally useful '.gitignore' file in the repo root
π οΈ D.I.Y.
What we need are git-fu ninja tricks. The learning curve on becoming a black-belt git-fu ninja π₯·π» can be high. It takes a lot of training in the git dojo. This is why, teams often underestimate the value of setting git up. It's simply not a common skil, and therefore not on the radar as an option.
Spend more time in the git dojo!
π€ Automation
.scripts/co-sample "Setup git" \
batch3 \
.gitconfig \
.gitignore \
.devcontainer/postCreateCommand.sh \
.scripts/trunk-worthy \
.githooks/pre-commit- Rebuild the devcontainer.
π§ͺ Test
Try to run:
git root
git st
.scripts/trunk-worthy
.githooks/pre-commit
git config list --show-origin
git config list --show-scope