Ещё раз о «Mercurial против Git» (с картинками)

Когда мне самому пришло время сделать выбор, я тоже пришёл к тому, что Merculial удобнее и логичнее для меня, как говорится «ложиться в руку». Но определённое давление со стороны сообщества (подавляющее большинство проектов, которые мне интересны, используют git в общем и github в частности) заставило «смириться» и перейти на git.

Я это говорю не с целью продемонстрировать слабость своей воли ;) Скорее, чтобы сказать, что давайте уже программировать, а не играться с системами контроля версий.

достаточно просто метить тегами сборки в релизных ветках, тогда будет ясно что и когда изменилось с последней сборки. Без этого, действительно, возникает путаница при слияниях

Автор сего опуса не осилил тэги. Cool story bro.

У Git-а есть GitHub и огромная комьюнити.

У самого почему-то сердце больше лежит к меркуриалу, но простота пользования github'ом просто подкупает.

Да и для компании сейчас рассматриваем покупку GitHub Enterprise со всеми его фичами.

«Самое печальное, что большинство пользователей Git, похоже, имеют концептуальный блок против даже признания того, что здесь есть проблема.»

Действительно. Сколько лет пользуюсь всякими репозитариями, первый раз вижу такие запросы. 1 — обычно список изменений пишется по багтрекеру. По логу репозитария тоже можно, но зачем при этом видеть, в какой ветке писался фикс? Просто просматривается список коммитов в ветке, не важно, откуда они замержены. 2-3 — тоже какое-то надуманное. Мерж надо верифицировать в совокупности (всю его разницу с целевой веткой), а не по принципу «вот эти строчки — они приехали из другой ветки, поэтому их не верифицируем». Начинать новую ветку никогда не было нужно было «оттуда же, откуда другую», а с головы или с определённого известного коммита. Ну и, естественно, есть такая вещь, как теги.

Честно говоря, раскрашенные вершины совершенно не помогают понять, откуда взялась, например, ветка release: из master или temp. Если в Git делать обычные слияния из двух источников и продолжать только одну ветку (а зачем вам больше), то никакого различия нет. И аргумент про rebase в локальном репозитории какой-то надуманный…

Можете ли вы мне сказать, на какую ветку было зафиксировано изменение ab3e2afd?

for i in `git show-ref --heads --dereference --hash`; do
  if [ `git rev-list ab3e2afd ^$i | wc -l` -eq 0 ]; then
    echo "`git describe $i` includes the change ab3e2afd";
  fi;
done


Ок. У меня есть три ветки: интеграционная, для выкладки на тестовые стенды, для выкладки в продакшин. 90% коммитов попадают во все три. Как прикажете красить?

По-моему единственная проблема git — это сложность.
Начать действтвительно эффективно им пользоваться без старах выстрелить себе в ногу (и своим коллегам) можно только после того, как прочтешь хороший кусок документации и поймешь его архитектуру, которая, на мой взгляд, предельно осмысленная и в дополнениях уже не нуждается.

Очень надуманно… у нас в день валится пара десятков изменений в ветках, которые частично уходят на продакшн, частично на текущий релиз… Если вы наворотили делов, напишите гайд по веткам на страничку, и уже завтра все будет выглядеть идеально. Цветная раскраска, и что? GitX, GitGui тоже раскрашивают ветки.

Это всё очень религиозно. Наша команда, например, разделилась на две части — одна говорит, что гит — непонятная поделка, другая же, что меркуриал. И у всех есть свои основания так говорить. Не надо ничего сравнивать, нужно использовать то, что нравится для своих проектов и то, что придётся для проектов, где вы не решаете таких вопросов или их даже не надо решать (сложность переезда, невозможность выделения времени на это и т.п.)

Не очень понимаю комментаторов.
Ключевое различие git и mercurial — это подход к слиянию веток. В mercurial нельзя несколько веток слить в одном коммите и это очень правильно! Никакой путаницы, всё под контролем, всё последовательно. А после мегамёрджа в git никто ничего никогда уже не разберёт.

Засранцы, Линус ждет ваших патчей мердж реквестов.

Появился интересный ответ на оригинальную статью — felipec.wordpress.com/2012/05/26/no-mercurial-branches-are-still-not-better-than-git-ones-response-to-jhws-more-on-mercurial-vs-git-with-graphs/

Не смог остаться равнодушным.

Честно говоря, не нравятся обе ваши картинки. На мой взгляд, такого допускать не стоит ни в какой системе.
И то, в какой ветке было сделано какое-то изменение не имеет смысла. Имеет смысл то, в какой ветке есть это изменение, а в каких — нет.

Есть ощущение, что Mercurial круче и гибче, но из поста так и не смог вкурить чем же именно.
Как это часто бывает, пересев с Svn на Git испытал чувство экстаза. Все, что работало плохо и часто ломалось в Svn в Git просто великолепно реализовано. И сам процесс разработки с переездом на Git сразу сдвинулся с места. Конечно, ограничения ощущаешь лишь со временем, но до сих пор Git позволяет мне вести процесс разработки так, как мне нужно и удобно.

Возможно так и надо подходить к вопросу — если встают непреодолимые препятствия или существенные ограничения, то да, пора «менять кобылу». Но пока она везет и достаточно резво, какой резон пересаживаться на другую? Мне кажется в этом основная причина того, что Git — мэйнстрим. Он достаточно хорош, чтобы его использовать, а его ограничения не настолько критичны, чтобы переводить с него процесс на mercurial, в котором, кончено же, со временем тоже почувствуются свои ограничения.

Git очень гибок и в этом его минус, если не умеешь им пользоваться. Он дает огромное количество инструментов и надо их изучать.
Сейчас наш workflow построен так, что я точно знаю, где и когда было сделано то или иное изменение и когда оно выйдет в свет.
История проста и понятна и по ней я могу точно сказать, где именно был сделан тот или иной коммит и когда он попал в ту или иную ветку. Это видно по истории. Это в git решается не на уровне самой системы, а на уровне организации процесса. По крайней мере, у меня так.

Я пользовался долгое время и тем и другим. Принципиальной разницы не заметил. Декоративная разница есть, но не более того.

Хотя нет — есть разница при поведении в очень сложных ситуациях, которые сами по себе являются не допустимыми при коллективной работе. Но, с учетом того, что эти ситуации относительно редки, разница получается минимальной.

если вам графики цветные строить то до, пользуйтесь этим
а если работать, то всё таки git