For me, it's definitely:

git log --all --graph --decorate --oneline

I often rebase my feature branches, just by pulling the origin (see the [pull] rebase=true below) or interactive rebases
here's my .gitconfig:

[alias]
    a = add --all
    au = add -u
    # b = rev-parse --abbrev-ref HEAD
    b = branch
    compare = "!f(){ git rev-list --count --left-right "${2:+$1}...${2:-$1}" | { read ahead behind; printf 'ahead: %s\tbehind: %s\n' $ahead $behind; } };f"
    bd = for-each-ref --sort='-committerdate:iso8601' --format=' %(committerdate:iso8601)%09%(refname)' refs/heads
    br = rev-parse --abbrev-ref HEAD
    am = commit --amend -C HEAD
    ci = "!f() { git commit -m \"$*\"; }; f"
    ca = commit --amend
    cl =  clone --no-tags #--single-branch
    clgh = "!f() { git clone --no-tags git@github.com:$@; }; f"
    co = checkout
    cp = cherry-pick
    cpa = cherry-pick --abort
    cpc = cherry-pick --continue
    d = diff
    do = diff --name-only
    dp = diff --patience
    dc = diff --cached
    f = fetch
    fo = fetch origin
    g = grep -p
    l = log --oneline
    lg = log --oneline --graph --decorate --date-order
    ls = ls-files
    m = merge
    mf = merge --ff-only
    mff = merge --ff-only
    ma = merge --abort
    mc = merge --continue
    ms = merge --skip
    p = push
    pf = push -f
    pu = "!f() { git push -u ${1:-origin} ${2:-$(git rev-parse --abbrev-ref HEAD)}; }; f"
    pl = pull
    rb = rebase
    rba = rebase --abort
    rbc = rebase --continue
    rbi = rebase --interactive
    rbs = rebase --skip
    rehh = reset --hard HEAD
    r = remote
    ra = remote add
    ragh = "!f() { repo=$(git r get-url origin 2> /dev/null || pwd); git remote add ${1:-origin} git@github.com:${2:-caub/$(basename $repo)}; }; f"
    rr = remote rm
    rv = remote -v
    rs = remote show
    rn = remote rename
    rao = remote add origin
    rro = remote remove origin
    rsu = remote set-url
    rsuo = remote set-url origin
    rsuogh = "!f() { git remote set-url origin git@github.com:$1; }; f"
    s = status
    sb = status -s -b
    sw = stash show
    st = !git stash list | wc -l 2>/dev/null | grep -oEi '[0-9][0-9]*'
[core]
    editor = vim # +startinsert!
    excludesfile = ~/.gitignore
    hooksPath = ~/.hooks
[pull]
    rebase = true
[fetch]
    prune = true
[rebase]
    autoStash = true

I’d like developers, even seasoned ones, to learn Git’s internals on a basic level. You don’t have to be able to rewrite the whole thing from scratch, but it’s better to see how commits, branches, tags, and the like are interconnected, so it’s easier to back off when you mess up something. Also, people should finally learn that Git and GitHub/GitLab are not the same: there is no such thing as Pull Request in Git lingo. </rant>

Still, if i have to choose some Git commands, it’s stash (especially stash branch) and rebase (especially interactive rebasing).

Stash is an obvious choice for me. When i have changes not ready to be committed, i stash it away. When popping it back and it has too many merge conflicts, instead of resolving them there i like to move it to a separate branch instead. This can help a lot, especially if you stash a change you don’t want to commit later.

Rebase, i think, will meet some resistance. I know there is an ongoing religious war between rebasers and mergers, and i’m not going to promote any of them. However, rebase has a lot of use cases even if you are a merge believer.

Found a typo in a commit you haven’t pushed/merged yet? Do an interactive rebase, reword that commit, and you are done.

Found two commits that should be in one? Do an interactive rebase, and use squash or fixup to combine them.

Found a typo in the contents of a commit? Interactive rebase to the rescue, just use the edit keyword, amend that commit and you are done.

The only confusing thing during rebase conflicts is that “our state” is actually “their state” (so when you see “deleted by us”, it actually means it was deleted in the commits you are rebasing onto).

Marco Alka has covered almost all the necessary commands.

Here's the one I use the most:

git diff --- shows difference in the uncommitted code changes happened from the last commit

git diff <file-name> --- shows difference in the uncommitted code changes happened on that file from the last commit

If you have lot of uncommited changes then above command will be hard to visualise. In those cases, I use gitk which is a simple UI based available on all platforms (apt-get/brew/windows)

Marco Alka Has a good list here, most of which I use on a daily basis. The one command I find myself using often is

git rev-parse HEAD

I use this to inject commit hashes to binaries. This helps me find the commit which built the binary.

Don't forget git clean -df, after a hard reset.

Especially when working in a team environment, it's the second step in truly resetting the file structure to your target commit.

Also, the first time pushing a branch (often, not to origin/master), be sure to define the upstream, so that it tracks that remote branch correctly.

Ex. git push -u origin [branch_name]

Now, you can git pull and git push within that branch, without experiencing unnecessary issues during the remote merge.

Marco Alka

When using git, I usually have to use the following commands for our workflows. Since we use repository providers with web interfaces, we usually do the server-side tasks there, however, on the local side, I do not use a visual tool, so they are all CLI 😉. I don't really list all commands, since with the ones below, git will automatically correct you if you want to do advanced things (like pushing a new branch to a remote repository).

If you need advanced functionality, all below commands come with many many options and switches, which I don't really need on a regular basis, hence did not mention. Please consult the official documentation. It's a really good source!

Getting the repository ready for work

• $ git clone example.com/repo.git: Clone a repository to your local machine
• $ git status: Show the status of the current repository

Branch management

• $ git checkout develop: Change the current branch to another existing one
• $ git checkout -B new-branch: Change the current branch to a new one
• $ git branch -av: Show a list of all branches (local and remote) with a compact status on them
• $ git remote add upstream original-example.com/repo.git: Add a new remote source
• $ git remote rm upstream: Remove a remote source
• $ git branch -D old-branch: Delete a local branch

Code management

• $ git pull: Download all new commits from the remote repo
• $ git add file.rs: Add a new file to the version control, or stage it for commit
• $ git merge my-feature-branch: Merge another branch into the current one
• $ git commit -m "do a barrel roll": Pack all staged files into a commit and add it to the version history with a short description. By adding the -a option, you can automatically stage all added files for this commit, which makes committing a breeze!
• $ git rebase -i HEAD~3: Squash+Rebase. This command pulls together the last three commits into one and then replaces these three commits in the history. Using the command opens an editor, giving you additional options on how the operation should be conducted.
• $ git reset -- file.rs: Unstage a file
• $ git reset: Unstage all files
• $ git reset --hard: Reset the current branch to the last commit, all staged and unstaged changes are lost
• $ git clean -df: Removes all untracked files
• $ git rm file.rs: Remove a file from the version control and delete it from the file system
• $ git stash: Save all changes to the current repository and set it back to the last commit
• $ git stash pop: Merge all changes which were stashed back into the repository, removing the stash
• $ git push: Upload all new commits to the remote repo