To add my own touch, I find staging certain parts of a file in the CLI bothersome, when I can just click-and-drag highlight what lines I want committed in eg. Sublime Merge. Not perfect, but waaay easier than with the default CLI in my opinion.

Can do it with a couple keys, 4 (commits tab), then ctl+j/k depending on where you want the commit to be.

I've heard good things about gitkraken though, but haven't used it myself.

Visual staging is extremely useful though and is a simple, single action.

Another tip is to constantly use the reflog. Reflog is your history of the history. Even if you lose a branch or commit garbage with a forced commit , reflog will restore it. That is very powerful. Just commit and experiment and reflog to undo

Git comfortable with the decentralized and wild nature of git .

  lol = !git --no-pager log --graph --decorate --abbrev-commit --all --date=local -25 --pretty=short
  sw = !git checkout $(git branch -a --format '%(refname:short)' | sed 's~origin/~~' | sort | uniq | fzf)
  lc = !git rev-parse HEAD
  rb = !git for-each-ref --sort=-committerdate refs/heads/ --format='%(refname:short) %(objectname:short) %(committerdate:format:%F)' | column -t
  ws = !git show --word-diff=color --word-diff-regex='\\w+'
  wd = !git diff --word-diff=color --word-diff-regex='\\w+'
  fza = "!git ls-files -m -o --exclude-standard | fzf -m --print0 | xargs -0 git add"
  gone = "!f() { git fetch --all --prune; git branch -vv | awk '/: gone]/{print $1}' | xargs git branch -D; }; f"
  root = rev-parse --show-toplevel
  oldest-ancestor = !zsh -c 'diff -u <(git rev-list --first-parent "${1:-main}") <(git rev-list --first-parent "${2:-HEAD}") | sed -ne \"s/^ //p\" | head -1' -
  diverges = !sh -c 'git rev-list --boundary $1...$2 | grep "^-" | cut -c2-'
  dlog = "!f() { GIT_EXTERNAL_DIFF=difft git log -p --ext-diff $@; }; f"

"git fza" (aliased to "ga") shows all unstaged files in fzf and you can use space to toggle them, then hitting enter finishes adding/staging them. This is great for selecting some files to stage. I use this one every day, it makes my workflow just a little better :)

"git gone" deletes local branches that don't exist in the remote.

"git lol" is a log alias.

"git oldest-ancestor brancha branchb" does what it says.

"git root" is part of an alias "gr" which runs "cd $(git root)". That takes you to the project root, and "cd -" will take you back to your previous location.

"git dlog" shows a detailed commit log.

"git lc" just shows the last commit.

Edited to add:

"git rb" shows recent branches. Piping it to "| sort -k3" will sort by date. (I really need to update that!)

"git sw" shows branches in fzf, hit enter on one and you checkout that branch.

I never use "git ws" and "git wd", I should remove those.

One exception: conventional commits. I find them very useful even on solo projects, since a) they make it easy to spot the type of change at a glance, and b) they force me to keep commits atomic. That is, if I'm ever compelled to make a commit that is both a `fix` and a `refactor`, usually out of laziness :), sticking to a conventional commit message is a quick way to determine what needs to be split into a different commit. These conventions really shine when used in a team, as they improve communication and keep the history tidy (along with all other benefits of atomic commits), but so far I haven't had the luck to work on teams that agree to adopt them. Using these commits to generate changelogs would be wrong, as changelogs should almost never be autogenerated (though these days maybe AI does an acceptable job at it), but they're still useful to keep track of the number of fixes, features, etc. that were produced in a release.

And a tip: in addition to plain shell and Git aliases, I've found scmpuff[1] and delta[2] to be invaluable in a Git CLI workflow.

[1]: https://mroth.github.io/scmpuff/

[2]: https://github.com/dandavison/delta

1. git status doesn't need to be run manually, https://github.com/woefe/git-prompt.zsh

2. I dislike aliases because they only work locally and not anywhere else which will be just confusing and especially when confusing when dealing with an emergency on non-local. It also makes sharing workflows harder. So I'd rather not use any.

3. On the other hand, I override git reset to commit before destroying work to save my own bacon. Oh and I added git cd which I guess contradicts #2 but oh well :) -- it's also not an alias -- and, to be fair, I use it somewhat rarely and it's not really a git command -- I could've named it cd-git-relative or something. Anyways here it is: https://gist.github.com/chx/d4e30aaf8e3d9a6fccad9e89bb8d73b8

https://github.com/jesseduffield/lazygit

Love the ability to pull a hunk out of a commit, create a new commit, then throw it over to another branch, with the press of a few keys.

I think if I were starting a team for scratch it's likely something I'd establish from the beginning - commit message guidelines, PR requirements, squash/rebase/merge standards. But I've only ever come into teams that have been working on the product for at least a year - and it's never seemed worth the 'political capital' to wrangle the team into a new standard for it.

I've tended to opt for doing things the way I think is right given that we aren't following a standard anyways - and pointing to the benefits of it when they come up.

  git hooks from https://pre-commit.com
    git-conventional-commits to enforce standardized messages
    linting
  github branch protection rules
  CODEOWNERS file and PR templates to speed PR creation