Git: remove untracked files

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: how to remove last commit from remote repository

git reset HEAD^ # remove commit locally
git push origin +HEAD # force-push the new HEAD commit
Original solution I've found here

Git: show affected files for commit

Бывает что нужно посмотреть какие файлы были изменены в выбранном коммите. Вариант решения может быть таким:
Сначала добавим алиас в конфиг, такого вида ~/.gitconfig
[alias]
  show-files = show --pretty="format:" --name-only
Для просмотра измененных файлов в одном коммите теперь можно делать так:
git show-files e2db3f1
Чтобы посмотреть все измененные файлы в нескольких коммитах теперь можно делать вот так:
git show-files e2db3f1 f93307c 96626aa 7104720 | sort | uniq
Это даст нам список всех файлов измененных в выбранных коммитах.

Git: Как исправить текст сообщения в предыдущем коммите

Допустим при коммите в сообщении была допущена грамматическая ошибка. Хочется этот текст коммита поправить. При этом коммит ещё в удаленный репозиторий не отправлен. Делается это так
git commit --amend -m 'new text message fixed'
Это элементарно, но у меня похоже, развивается склероз или типа того. Надоело гуглить одно и то же, решил записать.

Git: Подмодули

У 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
Живой пример использования подмодулей можно посмотреть вот здесь, надеюсь ссылка выживет.