For a long time, I was working with SVN as my default version control system. I liked it a lot for its clear syntax.

When I switched to the git, I was surprised how overloaded the checkout sub-command really is:

— You need to switch to another branch? Use git checkout.

— You need to revert modifications made to files? Use git checkout.

In SVN you have separate commands for each of these tasks.

Starting with git 2.23 we have new sub-commands to address this:

• git switch to switch between branches
• git restore to undo all modifications made

I'm sure this new syntax will be a great help for newcomers from SVN. Consider this new workflow. Extremely clear to me!

pasha@PG480 MINGW64 ~/go/src/github.com/cybertec-postgresql/pg_timetable (master)
$ git switch docker-tests
Switched to branch 'docker-tests'
Your branch is up to date with 'origin/docker-tests'.

pasha@PG480 MINGW64 ~/go/src/github.com/cybertec-postgresql/pg_timetable (docker-tests)
$ rm README.md

pasha@PG480 MINGW64 ~/go/src/github.com/cybertec-postgresql/pg_timetable (docker-tests)
$ git status
On branch docker-tests
Your branch is up to date with 'origin/docker-tests'.

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        deleted:    README.md

no changes added to commit (use "git add" and/or "git commit -a")

pasha@PG480 MINGW64 ~/go/src/github.com/cybertec-postgresql/pg_timetable (docker-tests)
$ git restore README.md

pasha@PG480 MINGW64 ~/go/src/github.com/cybertec-postgresql/pg_timetable (docker-tests)
$ git status
On branch docker-tests
Your branch is up to date with 'origin/docker-tests'.
nothing to commit, working tree clean

This one-liner will list all unpushed commits across all branches:

git log --branches --not --remotes

Working on a project, you might consider that one folder is more important than others. For example, src folder might be more relevant to you as a developer than doc, test, or samples, you name it. Or you may want source files to be listed first, e.g. *.c, *.go...

To order the list of files in git diff output, one may use git's diff.orderFile option.

If you are working with PostgreSQL for example, you may want such an order:

src/include/* 
src/common/* 
src/port/* 
config/* 
src/makefiles/* 
src/template/* 
src/backend/* 
src/fe_utils/* 
src/bin/* 
src/interfaces/libpq/* 
src/pl/* 
contrib/* 
src/interfaces/* 
doc/* 
src/test/*

To achieve this:

• create a file with the proper list, e.g. .gitorderfile
• run git config diff.orderFile .gitorderfile

You're done!

I often write lots of code at once and forget to commit. Then I have to create one huge commit with all changes, because I thought I can't partially stage and commit a file.

Turns out, you can do exactly that with git add -p!

This command lets you interactively select which hunks (blocks of changes) you want to stage.

With VS Code, you can interactively select which parts of a file should be staged:

1. Make changes to a file that is managed with git
2. Go to the Working Tree view of that file
3. Select the lines you want to stage and click the right mouse button
4. Click Stage Selected Ranges

Additionally, you can also unstage or revert the selected changes.

The code example below shows how to delete all branches which have already been merged into the current branch:

$ git branch
  feature-1
  feature-2
  feature-3
* master

$ git branch --merged
  feature-1
* master

$ git branch --merged | egrep -v "(^\*|master)"
  feature-1

$ git branch --merged | egrep -v "(^\*|master)" | xargs git branch -d
Deleted branch feature-1 (was 1d7fd54).

Check out this great Stack Overflow answer for more information.