-
Notifications
You must be signed in to change notification settings - Fork 1
git
History is written by those with advanced git skills
Get good at git: https://xkcd.com/1597/
I use the shortcuts provided by the oh-my-zsh git plugin.
Don't be this guy: https://xkcd.com/1296/
Use emoji
- https://github.com/dannyfritz/commit-message-emoji
- https://github.com/atom/atom/blob/master/CONTRIBUTING.md#git-commit-messages
Use good formatting
Be Conventional!
Pre-commit checklist:
- Only related/necessary changes/files are included.
- Unrelated/unnecessary changes/files are removed.
- There are no typos. (Run a spell checker.)
- All comments are still up to date.
- Remove all console logs/debugging code.
- Double check that all requirements are met.
- All tests are passing.
- There are no linter errors.
- All edge cases are covered.
- Have I verified that the code meets the requirements?
Often and not-often used git commands.
use: approve/stage each hunk. This will prevent acidentally committing console.log
s, etc.
-
ga -i
for interactive staging/patching. -
ga -p
to drop straight into patch mode.
use: squash, reorder, and edit commits. general rewriting of time
to change last N commits:
git rebase -i HEAD~N
Haven't committed yet:
-
git stash
- stash your changes -
gco -b feature/branch
- branch off of the current branch -
git stash pop
- pop your changes off the stack into the current branch
Have committed:
-
git branch feature/branch
- branch off the current branch -
git reset --hard HEAD^
- undo the last commit gco feature/branch
gc --amend
git reset --soft HEAD~1
- look at
gd --staged
andgit reset
the files you did not want to include in your commit. -
gc -c ORIG_HEAD
will commit with the original commit message. - You now have uncommited changes to either include in the next commit, or to discard with
gco <file>
.
e.g., committed to development
, meant to commit to feature/xyz
.
- Get the sha of the commit from
git log
ondevelopment
. -
gco feature/xyz
andgit cherry-pick <sha>
. You may have to resolve conflicts here. -
gco development
andgit reset --hard HEAD^
- Finally,
gco feature/xyz
and continue working.
Sometimes I want to keep a notes file in a project, but I don't want to commit that file to the .gitignore or anything.
echo "notes" >> ./.git/info/exclude
- oh-my-zsh git plugin cheatsheet: https://github.com/robbyrussell/oh-my-zsh/wiki/Plugin:git
- advanced git aliases: https://github.com/jlegrone/git-config
- flight rules: https://github.com/k88hudson/git-flight-rules
- ours vs theirs: https://nitaym.github.io/ourstheirs/
The Fork + Pull Request model was pioneered by GitHub, and copied by other git hosts, to keep you in the browser.
Git was originally designed to be used by email patches and, optionally, using a listserv.
See:
- tutorial: https://git-send-email.io/
- git email as a contributer: https://sourcehut.org/blog/2020-10-29-how-mailing-lists-prevent-censorship/
- as a maintainer: https://man.sr.ht/git.sr.ht/send-email.md
- Decentralized Collaboration http://www.lambdacreate.com/posts/17
A tiny CI system using the post-recieve
git-hook
=> https://www.0chris.com/tiny-ci-system.html
- https://benjamincongdon.me/blog/2021/12/07/Branchless-Git/
- git flow: https://www.gitkraken.com/learn/git/git-flow
- git worktree: https://scribe.rip/ngconf/git-worktrees-in-use-f4e516512feb
The basic idea of stacked diffs is that you have a local checkout of the repository which you can mangle to your heart’s content. The only thing that the world needs to care about is what you want to push out for review. This means you decide what view of your local checkout the reviewers see. You present something that can be ‘landed’ on top of master.
https://jg.gg/2018/09/29/stacked-diffs-versus-pull-requests/
An alternative to the ubiquitous githubesque pull request,
and also to the git send-email
methods of git collaboration.
- fossil!
- jujutsu is a git compatible vcs: