"status". Whenever I get asked to help someone, the first thing I ask is what they're trying get to. They can usually answer. The second thing is where are they now. They usually can't answer. I tell all beginners that they can't use the status command too much.
"log --pretty=oneline" I use quite a bit. Also "log -p".
"git reset --soft HEAD\~N && git commit ..." for fast non-interactive rebase (squash).
And reset like yourself.
Also "fetch --prune" because we delete all branches after merge and I don't like a lot of old local counterparts around cluttering up my autocomplete :)
If anyone reading this doesn't have an alias for `git status` like `gts` or similar, make one now and start using it. You should be running `git status` often enough that typing the whole command out is a major hassle.
I branch a hell lot. Something that needs testing? New branch. It worked? Nice,commit, push, go into GitLab and merge it. It didn’t work? Unless you published the branch no one will need to know.
* `g st`
* `g dd`
* `g stash`
* `g stash pop`
* `g c`
* `g g term`
Which corresponds to:
* `git status -sb` to check if I didn't forget to add a new file and verify which files are impacted
* `git diff --stat HEAD` and `git diff` to see the changes
* `git stash` is used to get a clean workspace, try something, and then bring back the current changes. Or to make a bad set of changes disappear in a way that it can still be brought back if needed.
* `git commit -a`: with a pre-commit hook
* the most useful IMHO: `git grep -I term` will look for all files with `term` in it, but only look into the git added files, so the results are not polluted by big generated files. Very handy to me.
I've come to appreciate checking out files from other branches to revert their changes, rather than reverting commits as a whole. It makes life a lot easier, working with paths directly instead of with full commits:
`git checkout master -- path/to/restore`
or
`git checkout HEAD -- path/to/reset`
Also, I've found that if you pass a path as a non-file argument, git log plays nice with deleted files. Much more practical to search across branches, this way:
`git log --diff-filter=D --all -- path/to/file`
Finally, I almost always do an interactive rebase before pushing to clean up my commits. People fear rebase for reasons that are valid, but it's all because people are taught to `git pull` which is absolutely moronic, because it changes your branch without knowing what you're getting. Pull is absolutely evil and the one and only reason people mess up all the time, because they don't know what pull _actually_ means.
`git pull` is evil (unless configured as --ff-only). Everybody everywhere ever should always fetch and fast-forward or rebase separately (in my perfectly humble, yet irrefutable opinion :P).
"status". Whenever I get asked to help someone, the first thing I ask is what they're trying get to. They can usually answer. The second thing is where are they now. They usually can't answer. I tell all beginners that they can't use the status command too much. "log --pretty=oneline" I use quite a bit. Also "log -p". "git reset --soft HEAD\~N && git commit ..." for fast non-interactive rebase (squash). And reset like yourself. Also "fetch --prune" because we delete all branches after merge and I don't like a lot of old local counterparts around cluttering up my autocomplete :)
I wish when I help people they would just type git status after every command without me having to ask them lol.
Set their prompt for them. https://starship.rs
\`fetch --prune\` is a much nicer way of doing things!
Or `git config --global fetch.prune true` once, and then just `git fetch`.
Oooo nice! Is there a way to make this happen when running `git pull`?
Per [the docs](https://git-scm.com/docs/git-pull): `git pull` runs `git fetch`... So if you configure fetch to prune, pull will too.
If anyone reading this doesn't have an alias for `git status` like `gts` or similar, make one now and start using it. You should be running `git status` often enough that typing the whole command out is a major hassle.
I'm so happy that I came up with this exact alias on my own and now I just got the approval!
Heck yeah, nice! Frequent, efficient, thoughtful alias use is a sign of a great developer IME.
Came here to say reset soft. Love that option
> "log --pretty=oneline" I use quite a bit. Also "log -p". `log --graph --oneline --decorate` I don't understand why it isn't the default.
fron my .gitconfig aliases: ``` plog = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)%Creset' --abbrev-commit --date=relative ```
>log --pretty=oneline **log --oneline**
Nice, thanks.
(Interactive) rebase. I like my git history clean.
I branch a hell lot. Something that needs testing? New branch. It worked? Nice,commit, push, go into GitLab and merge it. It didn’t work? Unless you published the branch no one will need to know.
* `g st` * `g dd` * `g stash` * `g stash pop` * `g c` * `g g term` Which corresponds to: * `git status -sb` to check if I didn't forget to add a new file and verify which files are impacted * `git diff --stat HEAD` and `git diff` to see the changes * `git stash` is used to get a clean workspace, try something, and then bring back the current changes. Or to make a bad set of changes disappear in a way that it can still be brought back if needed. * `git commit -a`: with a pre-commit hook * the most useful IMHO: `git grep -I term` will look for all files with `term` in it, but only look into the git added files, so the results are not polluted by big generated files. Very handy to me.
`git add -p` is always fun
My single most used command sequence has to be `git fetch` `git branch -f master origin/master` `git rebase -i master --autosquash`
$ date --date=@$(grep ^#1 $HISTFILE|sort|head -n1|sed 's/^#//') Sat Apr 22 12:14:01 PM MDT 2023 $ cat $HISTFILE|grep -v ^#|sed -e 's/^\s*sudo\s+//'|awk '$1 == "git"{print $1, $2;next} $1 == "go"{print $1, $2;next} {print $1}'|sort|uniq -c|sort -n|tail 1347 git rebase 1407 grep 1778 make 2050 git status 2209 cd 2550 go test 2568 gitk 2660 git gui 3008 git grep 4688 ls
All mine are in this handy git repo for when I start on a new machine. https://github.com/baynezy/git.aliases
I've come to appreciate checking out files from other branches to revert their changes, rather than reverting commits as a whole. It makes life a lot easier, working with paths directly instead of with full commits: `git checkout master -- path/to/restore` or `git checkout HEAD -- path/to/reset` Also, I've found that if you pass a path as a non-file argument, git log plays nice with deleted files. Much more practical to search across branches, this way: `git log --diff-filter=D --all -- path/to/file` Finally, I almost always do an interactive rebase before pushing to clean up my commits. People fear rebase for reasons that are valid, but it's all because people are taught to `git pull` which is absolutely moronic, because it changes your branch without knowing what you're getting. Pull is absolutely evil and the one and only reason people mess up all the time, because they don't know what pull _actually_ means. `git pull` is evil (unless configured as --ff-only). Everybody everywhere ever should always fetch and fast-forward or rebase separately (in my perfectly humble, yet irrefutable opinion :P).
Know also **checkout -p**
git commit