Preview files that will be deleted (dry-run)

git clean -fn

Real forced cleanup

git clean -f

Help

git help clean

Original solution is here

git reset HEAD^ # remove commit locally
git push origin +HEAD # force-push the new HEAD commit

Original solution I've found here

Бывает что нужно посмотреть какие файлы были изменены в выбранном коммите. Вариант решения может быть таким:
Сначала добавим алиас в конфиг, такого вида ~/.gitconfig

[alias]
  show-files = show --pretty="format:" --name-only

Для просмотра измененных файлов в одном коммите теперь можно делать так:

git show-files e2db3f1

Чтобы посмотреть все измененные файлы в нескольких коммитах теперь можно делать вот так:

git show-files e2db3f1 f93307c 96626aa 7104720 | sort | uniq

Это даст нам список всех файлов измененных в выбранных коммитах.

Допустим при коммите в сообщении была допущена грамматическая ошибка. Хочется этот текст коммита поправить. При этом коммит ещё в удаленный репозиторий не отправлен. Делается это так

git commit --amend -m 'new text message fixed'

Это элементарно, но у меня похоже, развивается склероз или типа того. Надоело гуглить одно и то же, решил записать.

У git есть интересная возможность включать в репозиторий проекта подмодули из других репозиториев. Например у нас есть некий проект, некая система состоящая из н-ного количества модулей. Какие-то модули могут быть опциональными и разрабатываться отдельными командами. Таким образом при очередной поставке продукта под конкретный проект можно подключать опциональные модули из других репозиториев и поддерживать их в актуальном состоянии.
Например есть три разделенных репозитория, каждый живет своей жизнью, поддерживается разными людьми

• Ядровая часть (A)
• Модуль 1 (B1)
• Модуль 2 (B2)

В очередной сборке нового проекта создаем репозиторий включающий подмодули A, B1 под другой проект A, B2 под третий A, B1, B2 и т.д. То есть отдельно кастомизировать какие-то вещи под конкретный проект, а какие-то модули/компоненты просто поддерживать в актуальном состоянии и использовать внутри этого проекта "как есть". Теоретически это можно решить просто хитрой схемой подключения модулей и раскладывать репозитории рядом в соответствии со своей схемой подключения. Подробности с примерами можно почитать вот здесь. Особенно внимательно стоит почитать раздел Issues with Submodules в котором описаны сложности доработки функционала подмодулей из того репозитория, которому эти подмодули собственно и принадлежат (сильно витиевато получилось, се ля ви).
Добавление подмодуля выглядит примерно так

# заходим в репозиторий проекта
cd ~/my/repo/name
# добавляем подмодуль и кладем его по относительному пути
git submodule add git://github.com/chneukirchen/rack.git ./modules/rack
git commit -am 'add submodule rack'
git push 

Операции для всех подмодулей могут выглядеть например вот так (см. git help submodule)

git submodule foreach git checkout master
git submodule foreach git pull

При клонировании репозитория с такими подмодулями, подмодули нужно будет инициализировать и обновить

mkdir new_folder
cd new_folder
git clone git://github.com/some/repo-name.git .
git submodule init
git submodule update

Список подмодулей можно посмотреть так

git submodule

Живой пример использования подмодулей можно посмотреть вот здесь, надеюсь ссылка выживет.