coub css express.js freeware git jquery laravel links linux macos mysql node.js php PostgreSQL python task1 ubuntu vim virtualbox анекдот игры интересно музыка стихи цитаты

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

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

Бывает что нужно посмотреть какие файлы были изменены в выбранном коммите. Вариант решения может быть таким:
Сначала добавим алиас в конфиг, такого вида ~/.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: Подмодули August 13, 2013
У 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
Живой пример использования подмодулей можно посмотреть вот здесь, надеюсь ссылка выживет.
git

Want this blog? Checkout that  here