Этот пост что-то вроде Advanced mercurial но для git. Рано или поздно все сталкиваются с двумя проблемами: у меня куда-то пропали коммиты и я запушил не туда. Во втором случае есть простой случай, когда никто не успел спулить и когда неправильный кормит у всей команды. Все опасаются применять команды с ключами --hard и --force, но это совсем не страшно, если понимаешь, что все обратимо и ты понимаешь чего хочешь достичь этими командами.
Концептуальное отличие от mercurial: в git коммит обязательно должен принадлежать бранчу (без бранча коммит становится detached head), а бранч может быть только один. В mercurial ветки могут быть анонимными, более того может быть несколько веток с одним именем. Чтобы коммит стал виден, должен существовать путь до него из какого-либо бранча. То самое отличие кроны и корневой системы (почему-то именно такая аналогия приходит в голову). В mercurial чтобы коммит был доступен должен существовать путь до него от 0-го коммита, а имена и прочее это мелочи. Соответственно и можно четко проследить начало и конец любой ветви, в отличии от git, где коммиты эфемерные дельты болтающиеся по узлам DAG. Хорошо это или плохо - зависит от, но в централизованной разработке мне больше импонирует mercurial с долгоживущими и вполне материальными ветвями, хотя это не значит что там нельзя редактировать историю - дельта алгебра везде одна. Git же заточен именно под распределенность и множество центральных узлов - помимо ветки foo-branch, обязательно есть origin/foo-branch или another/foo-branch с четким разделением откуда приехал коммит - в mercurial же именование веток сквозное по всем репозиториям, если стянули изменения то они уже ваши и отделить где чьё не получится.
Дальше пойдет описание трех сценариев в демке с github. Демка пошагово демонстрирует работу Алисы и Боба с общим репозиторием. Запускаем, читаем комментарии, жмем батон. Демка должна работать на unix-like системах где есть bash. Кстати, ознакомьтесь со статьей tonsky - прольет свет на внутренности git.
Концептуальное отличие от mercurial: в git коммит обязательно должен принадлежать бранчу (без бранча коммит становится detached head), а бранч может быть только один. В mercurial ветки могут быть анонимными, более того может быть несколько веток с одним именем. Чтобы коммит стал виден, должен существовать путь до него из какого-либо бранча. То самое отличие кроны и корневой системы (почему-то именно такая аналогия приходит в голову). В mercurial чтобы коммит был доступен должен существовать путь до него от 0-го коммита, а имена и прочее это мелочи. Соответственно и можно четко проследить начало и конец любой ветви, в отличии от git, где коммиты эфемерные дельты болтающиеся по узлам DAG. Хорошо это или плохо - зависит от, но в централизованной разработке мне больше импонирует mercurial с долгоживущими и вполне материальными ветвями, хотя это не значит что там нельзя редактировать историю - дельта алгебра везде одна. Git же заточен именно под распределенность и множество центральных узлов - помимо ветки foo-branch, обязательно есть origin/foo-branch или another/foo-branch с четким разделением откуда приехал коммит - в mercurial же именование веток сквозное по всем репозиториям, если стянули изменения то они уже ваши и отделить где чьё не получится.
Дальше пойдет описание трех сценариев в демке с github. Демка пошагово демонстрирует работу Алисы и Боба с общим репозиторием. Запускаем, читаем комментарии, жмем батон. Демка должна работать на unix-like системах где есть bash. Кстати, ознакомьтесь со статьей tonsky - прольет свет на внутренности git.

