I'm using surprisingly few every day, I realized, and most of them have been already mentioned. Okay, I have a couple tricks up the sleeve. And I'll name my favorite command later. A bit of suspense, ok?
#1. Make your common command short
git config --edit [--global]
This sounds mundane, but look how far you can get with it:
[alias]
b = branch
bb = branch --all
bv = branch -vv
co = checkout
d = diff
dd = diff --staged
lg = log --graph --format='%C(142)%h %C(36)%ad%C(auto)%d %s' --date=format:%y%m%d
s = status --short --branch
ss = status --no-short
w = show
[pull]
rebase = true
[rerere]
enabled = true
[rebase]
autosquash = true
[push]
followTags = true
[grep]
lineNumber = true
patternType = perl
[completion]
commands = ls-files ls-remote ls-tree rev-parse -citool -gui -gitk -request-pull -send-email -shortlog -whatchanged -credential-gcloud.sh
Besides aliases, I am including a few often missed great defaults to other common commands. YMMV, of course, but I'll go over them, in this and next sections.
pull.rebase = true: If you are working through a pull request workflow, you want your commits stay on top of the source branch. You may get conflicts on a pull, but if you do, this means you will get them anyway when sending a PR, so this only saves you same embarrassment. But once you resolved them and then continue on your branch...
rerere.enabled = true (for "REcord REbase REsolution" or something like that) is the best thing since bottled beer! Without it, on another pull you'll get the same conflicts. With it, Git remembers how you resolved them, and applies the recorded resolution. Don't see them bastards again!
completion.commands = ...: hide/show what you get after a 'git <TAB>'. Those with the '-' are hidden from the default set. Those without are added if normally hidden. And since a package so helpfully decided to put 'git-credential-gcloud.sh' on the PATH, why would I want a non-command 'credential-gcloud.sh' in the completion list? Hide it! If you use "lower-level" commands, like ls-files or ls-remote, expose them to autocompletion! Note: This is new in 2.20, broken in 2.21, and fixed by 2.24.
push.followTags = true pushes all annotated tags reachable from the commit you're pushing. Might have been the default, but that would break compatibility with the Git past behavior and piss off a lot of graybeards. I'm only 51 years young, and am already pissed off all too easily. YMMV.
And now (...drum roll...) 'git s' is my favorite command. Succinct and readable output..
2. git grep
No-one's favorite? C'mon! Where are all calls to this function in my project? 'git grep PATTERN' runs grep on your worktree files from the current directory and all down below recursively; see man for more. The [grep] settings above add grep switches '-P' and '-n', respectively. Non-Perl regexps are even more 1980's than disco balls!
3. Three future PRs in one branch? Set rebase.autosquash=true
git commit --fixup <committish>
is what you really want. You work on adding three features at once, and, unfortunately, all of them are dependent. You want to send the first in a PR, then the second, then the third--this is the only way to keep PRs smaller and reviewable. Even found yourself doing this?
$ git lg -3
* d0835482 200423 Add flapdoodle enabled by bamboozler
* 28eb1f47 200421 Replace kaboodler with bamboozler
* e0ce67fc 200421 Fix threading to enable use of bamboozler
Now you're working on adding the flapdoodle, but also fixed another threading bug. No biggie. Stage the fix for the top commit first (git add -p, if needed), and amend the top commit (git commit --amend --no-edit). That's a well-known trick. But now commit all the remaining changes, that threading bug that your brand new flapdoodle uncovered, thanks to the bamboozler:
$ git commit -a --fixup e0ce67
After some testing, you fix more of the flapdoodle and commit a fixup, but then... oh no, what an embarrassing comment typo in the threading fix! So you commit another fixup. _Applying a fixup to the previous fixup reduces chances of a conflict, but doesn't eliminate the possibility.
$ git lg -6
* 6c022160 200426 fixup! fixup! Fix threading to enable use of bamboozler
* 6f34aa90 200426 fixup! Add flapdoodle enabled by bamboozler
* e0ce67fc 200426 fixup! Fix threading to enable use of bamboozler
* 6f34aa90 200426 Add flapdoodle enabled by bamboozler
* 28eb1f47 200421 Replace kaboodler with bamboozler
* e0ce67fc 200421 Fix threading to be able to switch to bamboozler
* . . . . (origin/master)
And now is a magic time! Note that the --autosquash switch is best set your default setting: it affects only fixups, and is required for the fixup magic to work.
$ git rebase -i --autosquash HEAD~6 # or origin/master.
And, wonderfully, when an editor opens, fixups are already marked to be applied as fixups, no room for error. Just save the script with no changes, and the rebase leaves you with three clean separate commits, each with the original message. Fork a branch off the bottommost one, send a PR, after it's accepted pull the remote master, rebase your branch on it (if you applied reviewer's comments, you'll get conflicts in that commit, but you just 'git rebase --skip' your initial version of the commit; you might get more conflicts because of these changes in the remaining upper commits, which you'll need to resolve), fork another branch from the bottommost commit... You got the idea. Another option is to 'git cherry-pick' the second bottommost commit to a new off-maser branch to sent it for a review.
4. Not Git proper, but git rev-parse...
...can be wrestled into a very powerful command-line parser for complex tools written in bash, with Git-style subcommands and help messages. Since this is not about Git proper, I'll just leave a link to the parser source and a representative tool sourcing and using it. Search for the occurrences of substrings ArgParse and OPT_, and you'll grok it. The first file is well-commented but still ugly when fixes a couple of Git idiosyncrasies, but the second, with the code which uses it... well, I would not marry it either, bit it's still much simpler and readable with the parser than without it. git rev-parse may provide a lot of leverage if you're facing a task of writing a 5K-line-long bash code tool suite for IaC management of a scientific computation cluster in the cloud...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm using surprisingly few every day, I realized, and most of them have been already mentioned. Okay, I have a couple tricks up the sleeve. And I'll name my favorite command later. A bit of suspense, ok?
#1. Make your common command short
This sounds mundane, but look how far you can get with it:
Besides aliases, I am including a few often missed great defaults to other common commands. YMMV, of course, but I'll go over them, in this and next sections.
pull.rebase = true: If you are working through a pull request workflow, you want your commits stay on top of the source branch. You may get conflicts on a pull, but if you do, this means you will get them anyway when sending a PR, so this only saves you same embarrassment. But once you resolved them and then continue on your branch...rerere.enabled = true(for "REcord REbase REsolution" or something like that) is the best thing since bottled beer! Without it, on another pull you'll get the same conflicts. With it, Git remembers how you resolved them, and applies the recorded resolution. Don't see them bastards again!completion.commands = ...: hide/show what you get after a 'git <TAB>'. Those with the '-' are hidden from the default set. Those without are added if normally hidden. And since a package so helpfully decided to put 'git-credential-gcloud.sh' on the PATH, why would I want a non-command 'credential-gcloud.sh' in the completion list? Hide it! If you use "lower-level" commands, likels-filesorls-remote, expose them to autocompletion! Note: This is new in 2.20, broken in 2.21, and fixed by 2.24.push.followTags = truepushes all annotated tags reachable from the commit you're pushing. Might have been the default, but that would break compatibility with the Git past behavior and piss off a lot of graybeards.I'm only 51 years young, and am already pissed off all too easily. YMMV.And now (...drum roll...) '
git s' is my favorite command. Succinct and readable output..2.
git grepNo-one's favorite? C'mon! Where are all calls to this function in my project? '
git grep PATTERN' runsgrepon your worktree files from the current directory and all down below recursively; see man for more. The[grep]settings above addgrepswitches '-P' and '-n', respectively. Non-Perl regexps are even more 1980's than disco balls!3. Three future PRs in one branch? Set
rebase.autosquash=trueis what you really want. You work on adding three features at once, and, unfortunately, all of them are dependent. You want to send the first in a PR, then the second, then the third--this is the only way to keep PRs smaller and reviewable. Even found yourself doing this?
Now you're working on adding the flapdoodle, but also fixed another threading bug. No biggie. Stage the fix for the top commit first (
git add -p, if needed), and amend the top commit (git commit --amend --no-edit). That's a well-known trick. But now commit all the remaining changes, that threading bug that your brand new flapdoodle uncovered, thanks to the bamboozler:After some testing, you fix more of the flapdoodle and commit a fixup, but then... oh no, what an embarrassing comment typo in the threading fix! So you commit another fixup. _Applying a fixup to the previous fixup reduces chances of a conflict, but doesn't eliminate the possibility.
And now is a magic time! Note that the
--autosquashswitch is best set your default setting: it affects only fixups, and is required for the fixup magic to work.And, wonderfully, when an editor opens, fixups are already marked to be applied as fixups, no room for error. Just save the script with no changes, and the rebase leaves you with three clean separate commits, each with the original message. Fork a branch off the bottommost one, send a PR, after it's accepted pull the remote master, rebase your branch on it (if you applied reviewer's comments, you'll get conflicts in that commit, but you just '
git rebase --skip' your initial version of the commit; you might get more conflicts because of these changes in the remaining upper commits, which you'll need to resolve), fork another branch from the bottommost commit... You got the idea. Another option is to 'git cherry-pick' the second bottommost commit to a new off-maser branch to sent it for a review.4. Not Git proper, but
git rev-parse......can be wrestled into a very powerful command-line parser for complex tools written in bash, with Git-style subcommands and help messages. Since this is not about Git proper, I'll just leave a link to the parser source and a representative tool sourcing and using it. Search for the occurrences of substrings
ArgParseandOPT_, and you'll grok it. The first file is well-commented but still ugly when fixes a couple of Git idiosyncrasies, but the second, with the code which uses it... well, I would not marry it either, bit it's still much simpler and readable with the parser than without it.git rev-parsemay provide a lot of leverage if you're facing a task of writing a 5K-line-long bash code tool suite for IaC management of a scientific computation cluster in the cloud...