
Git commands to know just after you get the basics - mdziubek
https://codersbible.com/5-git-commands-to-know-just-after-you-get-the-basics/
======
rjtobin
Some other Git features that I find super useful, which past colleagues of
mine haven't known about (which maybe suggests they are not universally
known).

git rev-parse branch-name: gets the hash of a branch name, useful for
verifying two branches are at the same place (so "git rev-parse HEAD" gets the
current hash)

The ^ and ~ notations for navigating commits: my_branch^ points to the commit
1 before my_branch, and can be repeated multiple times, ie. my_branch^^^ to
get the commit 3 from the top. Likewise the tilda notation allows one to jump
a fixed number of commits up: my_branch~10 is the commit 10 above my_branch.

git rebase -i HEAD~10: interactively rebase the last 10 commits. Easy way to
re-order, squash, drop, and/or edit the commit messages of recent history in a
single git command.

~~~
32bitkid
This one is interesting, because if I recall correctly, if you are using the
single symbol they more or less mean the same thing. You can do ~~~ or ^^^ and
get to the same spot

The difference is in their numerical notion. ~N means go to my Nth first
parent. Where ^N means my Nth parent, which is really only valuable/useful on
merge commits (Or more specifically octopus merges that merge more than two
commits)

This is why ~ and ^ in the single form mean the same thing.

So, in one mental model of the DAG you can think of ^ as horizontal navigation
(Right) and ~ as vertical (Down)

~~~
rjtobin
Oh cool! That's good to know. Sadly too late to edit my original message, but
have upvoted yours so people won't learn from my errors :)

------
eyegor
By far my most used git command is this alias for a much more condensed,
prettified log:

git config --global alias.lg "log --color --graph
--pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold
blue)<%an>%Creset' \--abbrev-commit"

From [https://coderwall.com/p/euwpig/a-better-git-
log](https://coderwall.com/p/euwpig/a-better-git-log)

~~~
kubanczyk
It doesn't show which commits have two parents. Which is usually useful for a
`git revert`.

------
fit2rule
My favourite is real simple - it just shows me which branches/tags are most
current, with the last worked-on at the top ..

    
    
        'git for-each-ref --sort=-committerdate'
    

Helps me keep my head around what branches are what ..

~~~
cryptonector
In rebase-happy workflows the commit date doesn't mean much.

------
ghayes
For me, I found it very useful to stop using tracking branches. This means I
move all of my branch pointers manually and once you get used to it, you’ll
begin to find rebases and cherry-picks more intuitive. In fact, it’s made me
really distaste merge commits in general.

Flow might be something like:

    
    
        git checkout master
        git checkout -b my_branch
        git push origin my_branch
        ...
        git fetch
        git log -p origin/my_branch
        git reset --hard origin/my_branch

------
Arkanosis
While a lot of git commands can compete for the title of the most useful, I
believe the combination of git reflog and git reset is what can transform the
git user from someone who lives in fear of their tool to someone who loves it.

Know reflog and you stop being afraid of losing your work if you mess up, know
reflog and reset and you stop being afraid of not being able to fix things if
you mess up.

~~~
hkai
Or, if you use SourceTree, you don't need to struggle at all.

------
rad_gruchalski
git reset --hard can be pretty destructive when applied at the wrong moment.
When reverting changes in selected files, my preferred way is to use git
checkout selectively.

~~~
saila
Agreed, and there's also _git restore_ now, which might be a bit more
intuitive.

------
vasergen
next commands I find very useful

    
    
      git diff # see diff 
      git diff master..develop # see diff between branches
      git show <commit> # see changes in specific commit
      git log -p <file> # see log for specific file with diff
      git checkout - # checkout in previous branch

------
3fe9a03ccd14ca5
git bisect is the command everyone should learn. With a single command (such
as a test you just wrote) you can have git do a binary search across any
number of commits and find exactly when the bug occurred.

~~~
32bitkid
git bisect and got blame are underrated tools, that in my opinion get lost in
the conversation about should-you-squash-or-not. They really have diminishing
returns when you start squashing huge feature branches into a single commit.

------
sebazzz
A git alias I use is "git preb", which stands for "pull with rebase". It
rebases my commits on top of origin using a merge algorithm, which is smarter
than the default which uses patches and often causes merge conflicts. Its
definition is - iirc, typing this on my mobile - "pull --rebase -s recursive".
Now I don't push any useless merge commits like "Merge origin/develop into
develop".

------
srikz
I wish I had learnt about gitignore sooner when I first learnt to use git.
Especially if you are using an IDE and it generates a ton of files.

~~~
johannes1234321
For IDE files a global ignore file is useful, then one doesn't have to repeat
this for all repos and not all contributors need to add their IDE's files to a
shared file. For local there is also .git/info/exclude per repo.

~~~
srikz
Yes, that’s good advice. I was referring to the concept of gitignore in
general. At least when I learnt git from some tutorials, gitignore was treated
like an advanced topic and I was fumbling with git for a while with all these
artefacts creeping into my repo until I learnt of this simple solution

------
vharuck
My most used git command is `git help`. My soon-to-be favorite I just
discovered is `git config --global alias`.

------
hyperpallium
Learning git is race-to-reflog, so you can undo your learning mistakes.

------
aliceryhl
My most useful tool for working with and fixing weird branch structures is the
graph based log output together with `git branch -f move_me to_here`

------
saila
I really don't think _git reset --hard_ should be at the top of a list of git
commands intended for beginners.

~~~
m4r35n357
and yet is one of the most useful commands for fixing mistakes made by
beginners . . .

~~~
u801e
Though it would probably be better to tell beginners to run git stash save
first. Then they wouldn't lose changes they made to the files before running a
hard reset.

------
teddyh
Obligatory xkcd: [https://xkcd.com/1597/](https://xkcd.com/1597/)

