×Закрыть

Mercurial vs. Git в коммерческой разработке

Для начала я хочу внести ясность в понятие коммерческой разработки и её отличий от других моделей. В коммерческой разработке принято ставить конкретные цели и отслеживать этапы выполнения работы. Тогда как, например, в open source моделях разработки, обычно цели ставит перед собой отдельный разработчик, а этапность их исполнения и привязка к бизнес требованиям никого не интересует.

Зачем вообще нужна система контроля версий? Есть несколько причин:
— Обеспечить одновременную возможность работы коллектива над кодом;
— Сохранить лог всех изменений и версий для того чтобы при необходимости вернуть версию или часть кода, а также разобраться в проблеме на основе анализа изменений.

Отличия между Git и Mercurial

Главное отличие — «Its all in branches», как сформулировал однажды Felipe Contreras в своём блоге. В статье приведена масса аргументов, почему git технически лучше, чем mercurial, и большинство из этих аргументов бесспорны. Действительно, для программиста проекта open source на сегодняшний день git — лучший выбор.

Да и вообще, если спрашивать только программистов, в том числе на коммерческих проектах, выбор тоже будет преимущественно в пользу git. Видимо, процесс выбора системы контроля версий полностью отдаётся на откуп программистам, а они, конечно же, выберут самый технически совершенный инструмент на рынке, чем и является на сегодня git.

Но этот выбор может оказаться сомнительным, если взглянуть на него с точки зрения PM. А вот многие слабые места Mercurial оказываются, на поверку, его сильными сторонами.

Взгляд техлида/PM — почему Mercurial удобнее

Предлагаю рассмотреть следующие отличия git vs. mercurial в контексте их удобства для PM и коммерческого проекта в целом:
— невозможность удаления веток, коммитов, т.е. изменения истории репозитория;
— уровень сложности обучения;
— «тяжёлые» ветки, в коммитах которых ветка привязана напрямую.

Отслеживаемость изменений

На всех наших проектах поддержка Traceability позволяет нам работать более эффективно. Если вернуться в начало статьи, то трассировка позволяет нам отслеживать:
— этапность изменений;
— привязку изменений к бизнес требованиям.

Как это реализовано на практике: связка с таском кодируется в названии ветки, например: 29277_pivot_table, 30249_summary_page, 30081_agroups, 28255_angularjs_todo. Мы работаем c теми самыми «тяжёлыми» ветками, в которых ветка привязана к коммиту. В номере ветки кодируется номер задачи и краткое описание. Потом, если вдруг в hg annotate (аналог команды blame) мы попытаемся понять, кто изменил конкретную строку кода, нам не составит труда открыть трекинговую систему с номером таска. В таске, в свою очередь, перечислены (путём обычных comments) список всех изменений к данному таску.

И если вдруг заказчик задаст мне вопрос: «Кто выпилил важный баннер на первой странице с рекламой главного рекламодателя?» — я смогу чётко ответить, указав ссылку на бизнес требование и таск, с ним связанный.

Полноценная трассировка невозможна в Git по нескольким причинам:

— Ветка может быть удалена. Git, как более мощный инструмент, позволяет удалять ветки и другие части лога из истории. То есть вполне может так оказаться, что останется только merge commit, в котором может быть указана только общая причина (например, «вливка версии 11 в master»).

— Возможно, вы обнаружите commit девелопера, но это ещё не решение. В коммите может быть сказано: «Выпилил баннер». А почему так произошло — тайна покрытая мраком. Тут приходится делать упор на то, чтобы девелоперы обязательно ставили номер таска в commit msg. Регулярно наблюдаю эту картинку в командах, которые работают с git, и там же регулярно наблюдаю процентов 40-60% коммитов без метки таска.

Для того, чтобы хоть как-то решить эту проблему, в Jira стоит авто-отслеживание коммитов по номеру таска, совпадающих с названием проекта. Но этого оказывается недостаточно для 100% гарантии результата.

Сложность обучения и эксплуатации

Большинство людей, которые используют git, вообще не понимают, о чём я говорю. Ну да, они «уже» работают, в 90% случаев не вдаваясь в подробности, почему это так устроено. Некоторые имеют на бумажке «шпаргалку» в которой указаны наиболее часто используемые команды.

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

1. Разделение типов репозиториев в git и команда clone

Начнём с первого шага, и здесь я сразу вижу некоторую неудобность git в рельной жизни. И в git, и в mercurial синтаксис команды clone одинаковый:

git clone <откуда> <куда>
hg clone <откуда> <куда>

Вроде всё логично? Всё, да не совсем. В Git, оказывается, есть разделение репозиториев на клоны для девелоперов (рабочие) и клоны для сервера (bare). Это сделано, видимо, в целях оптимизации, но в результате, чтобы обменяться кодом с соседом программистом, мне уже недостаточно будет просто написать hg push ssh://otheruser@othercomp, а потребуется создать bare репозиторий и организовать обмен кодом на его основе.

2. Работа с ветками

В Git придётся выучить целый раздел описания того, как работать с локальными и удалёнными ветками, как их клонировать, коммититься и т.п. Это, конечно, хорошо, если оно реально используется. Это суперфича важна для open source, когда можно локально играться на разных ветках и оправлять на оценку сообществу только те ветки, которые уже завершены и готовы к рассмотрению.

В коммерческой же модели разработки PM’у важно видеть объём и качество сделанной работы каждый день, а иногда и чаще. И, соответственно,удобно, чтобы все рабочие ветки заливались на сервер, что по умолчанию происходит в mercurial.

Я не хочу сказать, что работа с локальными/удалёнными ветками — это плохо. Опционально я был бы не против такой фичи в mercurial. Но её полезность в нашей ежедневной работе под большим сомнением.

Помимо того, данный функционал довольно сильно усложняет синтаксис вызова команд. Если в Mercurial всё, что вам требуется знать, — это просто команды создания, перехода между ветками, то в git всё намного сложнее. И хотя сложный функционал востребован редко, пользоваться им приходится всем. Примеры для сравнения:

hg git комментарий
hg diff git diff HEAD показать текущие изменения
hg up branchname git checkout -b branchname origin/branchname перейти в ветку
hg push git push
git push origin master
отправить изменения на сервер

Мне поначалу было сложно понять, что за origin и почему надо указывать ветку.

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

Будьте внимательны с синтаксисом вызова git. Допустим, для удаления ветки в git используется не очень понятная конструкция типа git push origin :the_remote_branch. То есть мы отправляем «пусто» заменить ветку на сервере — в результате команды удаляется ветка на сервере.

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

В Mercurial ничего удалить нельзя (тривиальным способом). Для меня как для PM’а это плюс, для разработчика скорее минус.

Простота запоминания команд в Mercurial

Сравните:

hg git
hg in git fetch && git log master..FETCH_HEAD
hg out git fetch && git log FETCH_HEAD..master
hg purge git clean -fd
hg revert -a git reset --hard
hg addremove git add .; git ls-files --deleted xargs git rm
hg glog git log --graph --all --decorate

Ну и закодированное git config по сравнению с обычным простым файлом .hg/hgrc

Минусы Mercurial

Все вышеуказанные плюсы в какой-то мере могут стать и минусами. Например, самая проблемная ситуация — не стоит добавлять огромные файлы в репозиторий. Один наш заказчик решил, что таким образом можно добавить media файлы, включая рекламные ролики, и размер репозитория резко вырос на размер видео, помноженный на два. Удалить их простым способом было невозможно, пришлось использовать ConvertExtension.

Второй минус — к хорошему привыкаешь быстро. Поработав немного с mercurial, возвращаться на git довольно сложно, так как приходится вспоминать зубодробительный синтаксис для простых вещей.

Третий минус — вы, как PM, скорее всего, не сможете переубедить свои программистов в необходимости перехода на Mercurial. Причина проста — они уже выучили один синтаксис, переучиваться не хотят. Тем более, на заведомо более слабую по фичам систему. Есть шанс, если стартовать новый проект.

Выводы

Спор о том, что лучше, а что хуже, сильно зависит от контекста решаемых задач. Мой выбор на сегодня прост — для Open Source я пользуюсь в основном git, в коммерческих проектах — только Mercurial.

Хочу пожелать читателям правильно делать свой выбор.

LinkedIn

Лучшие комментарии пропустить

жду статью «двойные кавычки vs одинарные кавычки в javascript в комерческой разработке»

Изначально думал не тратить время на комментарий, но, сделав себе крепкого кофе, приступим:
1.

Мне поначалу было сложно понять, что за origin и почему надо указывать ветку.
Кто же Вас заставляет писать origin?
2.
Ветка может быть удалена
По-Вашему это нормально, когда 100500 фича-бренчей висят после использования?
3.
регулярно наблюдаю процентов 40-60% коммитов без метки таска
А вот представьте, есть такая штука как hook, в скрипте настройки энва она устанавливается и в итоге Вы просто не сможете закомитить без метки таска. На одном из проектом, где я был, было 100% камитов с [PROJECT_NAME-JIRA_ISSUE_NUMBER] MESSAGE
4.
для удаления ветки в git используется не очень понятная конструкция
WTF? stackoverflow.com/a/2003515
5.
вы, как PM, скорее всего, не сможете переубедить свои программистов
Как PM у Вас есть возможность устанавливать правила на проекте


Я пользовался и hg, и git. Мне кажется, что для конечного пользователя (программиста, девопса или тестировщика) разницы нет, это довольно простой (и мощный, конечно) инструмент в использовании. Намного распространённей git, поэтому смысла изучать hg не вижу.
А ещё, перед написанием такого рода статьи, надо самому пройти курс git’a

Пожалуйста, выпилите эту статью. Неокрепшие умы могут подумать, что она правдива

Предлагаю рассмотреть следующие отличия git vs. mercurial в контексте их удобства для PM и коммерческого проекта в целом:
— невозможность удаления веток, коммитов, т.е. изменения истории репозитория;
Как можно ставить в преимущества невозможность сделать что-то? Ну не надо оно вам — договоритесь в команде не удалять и не править историю и делов-то. Как-то же договариваются о других вещах, а не ищут VCS с наперед вшитым шаблоном описания коммита или с принудительным созданием фич-бранчей.

Вброс на тему Г@вно vs Конфетка.
Натыкаясь на подобные статьи, понимаешь что «23-й кто-то там» это состояние души.
...
ТС перестаньте.
Я понимаю, что некоторое количество знаний у Вас перешло в качество.
Но не надо экстраполировать его на новые домены, в которых Вы не совсем эксперт.
Ещё и в ультимативной форме.
...
Команды в гите для вас не очень логичные!
А вас не смущает, что есть кран подъёмный и кран водопроводный?!
Это жизнь, она многообразнее всех вместе взятых проекций реального мира, под названием — люди.
...

Тогда как, например, в open source моделях разработки, обычно цели ставит перед собой отдельный разработчик, а этапность их исполнения и привязка к бизнес требованиям никого не интересует.
Это уже отметили. Это говорит человек, который скорее всего не контрибьютил ни в один опенсоурс проект.
...
Повторюсь, не пытайтесь экстраполировать ограниченный набор знаний на всевозможные домены, методики, механики, инструменты, модели.
...
Вам нравится Mercurial, бога ради. Решили поделиться опытом, как Вы зашиваете имя таски в имя ветки, а так как Mercurial не позволяет их удалять, у вас всё хорошо. Спасибо.
Но подход я Д’Артаньян все п..@.@.ы, никому не к лицу )))

118 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

честно говоря вообще пофиг, svn, git, tfs все работает в правильных руках

С этим сложно не согласиться ;-) Да и действительно, какой бы совершенный инструмент не был, если в процессах бардак, ничего не поможет. Мы вот проект один начинали на cvs, потом импорт в svn, далее в hg. 10+ лет, полёт нормальный, вся история с привязкой к tasks сохранилась

Автор, марш учить матчасть git-scm.com/book
Все надумано от незнания. Некоторые вещи вообще практически вывели меня из себя.
.

Как это реализовано на практике: связка с таском кодируется в названии ветки, например: 29277_pivot_table, 30249_summary_page, 30081_agroups, 28255_angularjs_todo.
Это никак не фича hg, вы делаете в git все то-же самое. А если посмотреть на более современные решения вроде github, то вообще ничего выдумывать не надо. Пулл реквесты дают сразу и traceability, и код ревью, и много всего другого (не хочу уходить в дебри, например тестирования изменений еще до мерджа).
.
— Ветка может быть удалена. Git, как более мощный инструмент, позволяет удалять ветки и другие части лога из истории. То есть вполне может так оказаться, что останется только merge commit, в котором может быть указана только общая причина (например, «вливка версии 11 в master»).
Сразу две ошибки, во-первых без force push ничего никуда не девается. В reflog есть все удаленные ветки. Ветка и тег это лишь симлинк, ссылка на коммит. Ссылка передвигается на другой коммит когда в ветку делается пуш git-scm.com/...es/branch-and-history.png
Во-вторых, при мердже кроме создания коммита «вливка версии 11 в master» все «влитые» коммиты так-же появляются в ветке, куда влили. Смотрите внимательнее, они могут быть не сверху если старые.
.
Большинство людей, которые используют git, вообще не понимают, о чём я говорю.
Конечно не понимают, потому что вы несете ахинею.
.
В Git, оказывается, есть разделение репозиториев на клоны для девелоперов (рабочие) и клоны для сервера (bare). Это сделано, видимо, в целях оптимизации, но в результате, чтобы обменяться кодом с соседом программистом, мне уже недостаточно будет просто написать hg push ssh://otheruser@othercomp, а потребуется создать bare репозиторий и организовать обмен кодом на его основе.
ORLY? Это вообщем-то одна из основопологающих идей гита. Децентрализованность и мгновенная организация коллаборейшна прямо на уровне локальной сети и двух девелоперов между собой: git-scm.com/...-the-Server-The-Protocols
.
В коммерческой же модели разработки PM’у важно видеть объём и качество сделанной работы каждый день, а иногда и чаще.
Что за бред. Вы случаем родом не из Индии? KPI по количеству строк кода случаем не высчитываете?
.
Допустим, для удаления ветки в git используется не очень понятная конструкция типа git push origin :the_remote_branch.
Эта непонятная конструкция лишь синтаксический сахар для тех кто в теме. В оригинале git push origin —delete <branchname>
.
В Mercurial ничего удалить нельзя (тривиальным способом). Для меня как для PM’а это плюс, для разработчика скорее минус.
В гите тоже. Только ребейс и форс пуш, чего нельзя делать в публичных репах по известной причине (только в качестве исключения, осознавая как это работает, например для удаления большого файла или случайно закоммиченого пароля). git-scm.com/...t-Tools-Rewriting-History
Ветка и тег это лишь симлинк, ссылка на коммит. Ссылка передвигается на другой коммит когда в ветку делается пуш
Вот это то и неудобно. В Mercurial тоже есть подобные бранчи, я ими не пользуюсь по причине, указанной в этой статье. Вернёмся к git, у меня есть commit, хочу понять при создании какой именно фичи он был создан. Есть ли у Вас однозначный ответ? Я читал вот это: stackoverflow.com/...ch-a-git-commit-came-from но большинство ответов данных и проголосованных там малоинформативны. Как я это делал раньше — открывал gitg, и смотрел какая ветка или мерж являются parent для этой серии коммитов. Но это муторное долгое дело, соответственно получить быстрый ответ к разработке какой фичи данный коммит относиться у меня не выходило...
Децентрализованность и мгновенная организация коллаборейшна
Спасибо! Действительно или что то изменилось за годы, или я изначально неправильно понял данный момент. Перепроверил только что — смог заклонировать репозиторий по ssh, признаю свою ошибку, в статье это указано неправильно. Буду писать summary comment, обязательно это учту.

Начнем с того, что ветки в hg не были задизайнены специально для того, что-бы в них хранить фича нейм. Вы *адоптировали* hg под себя. Точно так-же вы можете и в гите, как уже говорилось, записывать метаданные о коммите в коммит мессадж, или использовать теги, или организовав нужный вам маппинг в джире, итд — тем самым адоптировав под себя и гит. Я не хочу даже начинать спорить с «Тех. директор в UA2WEB» об организации девелопмент процесса в веб-студии, где преимущественно php и пришибленные заказчики. Вы не одиноки — с 1Сниками об этом я бы тоже спорить не стал. Ровно как и бухгалтеры, наверное, зачем-то, теоретически, могли бы адаптировать git/hg под какие-то свои нужды.
Я просто хочу сказать остальным девелоперам, которые случайно могут наткнуться на вашу статью, что-бы ни в коем случае вас не слушали. В остальном, прогрессивном мире, ваши проблемы надуманны и никому не интересны. Там стремятся уменьшить риски непрерывной интеграцией (или хотя-бы минимизацией времени жизни фича-бренчей), делая фокус на работающем продукте, а не на разборе полетов «кто удалил баннер» (я уже молчу о том, что в прогрессивном мире такой чендж просто бы не пропустили авто тесты).
Инфа по теме jeffkreeftmeijer.com/...arent-you-using-git-flow

Дмитрий, Вы второй раз позволяете себе переходить на личности и не отвечать на прямые вопросы. Да у нас в компании построен бизнес процесс который даёт определённый уровень прозрачности. Я совершенно согласен с тем, что не всем это нужно, и не собираюсь уговаривать всех переходить на аналогичные бизнес процессы.

Я задал простой вопрос, и вместо ответа получил "

где преимущественно php и пришибленные заказчики
и другие домыслы, которые мне тоже неинтересно читать. Нет ответа как построить на основе git тот бизнес процесс который интересует меня ? Нет ответа на прямой вопрос о том, как быстро узнать к какой фиче относиться данный коммит? Если нет ответов по существу, вести дискуссиию тем более с переходами на личности далее нет смысла.

Про git-flow интересно, но всё это мы делаем или вручную или с помощью инструментов типа Jira, те же самые feature-branches, hotfixes, releases, интеграции в master и тп.

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

Нет ответа как построить на основе git тот бизнес процесс который интересует меня ?
tl;dr: у вас не правильный бизнес и девелопмент процесс.
Long: Вы можете построить все, что вам угодно. Хоть свое написать, например свой дженкинс на php. Сейчас вы спрашиваете человека, который большую часть своей карьеры строил дев-процессы и помогал командам имплементировать разные методологии (типо CI/CD). И я вам отвечаю: у вас не правильный бизнес и девелопмент процесс.
На счет личностей: сложно не перейти на личности (прошу заметить, даже не с вами, а с вашей «фирмой») когда именно на примере опыта вашей «фирмы» вы пытаетесь донести нечто вроде «знания». Посудите сами об абсурдности ситуации: куча книг, литературы, статей, авторами всего этого добра выступают известные личности из известных компаний, лидеров индустрии, из силиконовой долины и не только. И тут, в какой-то Украине, на каком-то локальном девелоперсом форуме, (ну уж простите за личности, но тут иначе никак) какой-то «Тех. директор» в каком-то Харькове, из какой-то «UA2WEB» выдает за истину вещи диаметрально противоположные всем тем известным трудам и рукописям, о которых я писал выше. Ну вам разве самому не смешно? Мне правда не принципиально на личности переходить, и вообще с вами вести диалог. Судьба вашей компании мне до лампочки. Все происходящее там у вас весьма типично для «коммерческой разработки» в так называемых «веб студиях» :) (опять-же, ничего личного к веб-студиям и пхп, бывает самому надо по какой-то причине именно на пхп что-то заавтоматизировать, но статистика — она неуклонна).
Я просто переживаю за людей, которые прочтут этот опус и примут его за чистую монету, а мне потом может быть придется с ними работать, и тратить на них свои нервы.

Статья в ультимативной форме доказывет не то что hg лучше git (как раз технически наоборот), а что в конкретном бизнес процессе, с упором на traceability hg подходит лучше, по объективным причинам (их несколько, главная их которой конечно же ветки). На мой вопрос не ответили, отсыл к «куче книг, литературы» не засчитан т к это не решает мою проблему, поверьте, читал. Пусть люди сами переживают за себя, не переживайте так за них: они сами смогут сделать свои выводы. Всё на что Вы сослались это git-flow, который у нас применяется посредством Jira, но проблем указанных мною выше он не решает.

git-flow, который у нас применяется посредством Jira
Это я заберу в цитатник.
На мой вопрос не ответили, отсыл к «куче книг, литературы» не засчитан т к это не решает мою проблему, поверьте, читал.
Я вам тут в бесплатные менторы не записывался. Я уже дал как минимум три весьма полезных в вашей ситуации источника информации: для восполнения пробелов в знании гита; для понимания как правильно работать с бранчами (и не только в гите, не смотря на то что это называется git flow); и на риски в вашем процессе, на которые стоит обратить внимание.
traceability
Ладно, так и быть, вы раскрутили меня на еще один бесплатный совет, хотя я уже несколько раз говорил: это не те дроиды, которых вы ищете. В вашей команде правая рука не знает, что делает левая, и вы через traceability пытаетесь на скорую руку закрасить результаты этой ситуации. Отбросим такие эзкотические варианты, как TDD, ваш root cause решается на отлично тольковыми automation QA и авто тестами. Когда ТЗ оцифровано в авто-тестах, и девелопер пытается сделать чендж, который сделать нельзя — все сразу об этом узнают с отсылкой на нужную фичу. Таким образом проблема находится раньше, когда стоимость ее исправления минимальна (это есть в презентации, что я скидывал).
glenndejaeger.files.wordpress.com/2010/02/testing.gif
Так-же советую посмотреть на github и аналогичные продукты, где вводится понятия pull request. Хотя оно предназначено, опять-же, для снижения рисков и удобства код ревью, теоретически вы могли бы адаптировать это для своего traceability. Вы можете это попробовать даже не уходя с hg, перестав пользоваться бренчами не по назначению, заменив их пулл реквестами на bitbucket. Я не помню, как ведет себя hg, и покажет ли он merge коммит по запросу (который и отведет на страничку с нужным PR и веткой его обсуждения), но git — покажет.

Хорошо, допустим после моих изменений для новой фичи X в ветке валится тест Y, как понять какое бизнес требование тест Y отслеживает? Я должен сформулировать проблему в терминологии: «При попытки реализации фичи X нарушается целостность исполнения бизнес требования Z, с привязанным тестом Y». Что делать далее? Как выяснить какую часть заложенной логике и какие бизнес требования поломались? Большая часть команд валят всё на отдел QA, пусть они сами разбираются. Мне же такой подход претит, он занимает в разы больше времени и не даёт качественного результата, т к метаданные могут отсутствовать (зависит от того, насколько хорошо организвана работа отдела QA). Я же просто избегаю лишних шагов, если есть ветка, могу сказу сказать о том, какое бизнес требование Z будет нарушено в связи с введением новой фичи X и далее инициировать дискуссию бизнес аналитики, QA и меня как разработчика.

Большая часть команд валят всё на отдел QA, пусть они сами разбираются. Мне же такой подход претит, он занимает в разы больше времени и не даёт качественного результата, т к метаданные могут отсутствовать (зависит от того, насколько хорошо организвана работа отдела QA). Я же просто избегаю лишних
Я правильно понимаю, что по этой причине, QA у вас нет вообще? Тогда смысла продолжать диалог я лично не вижу.
На случай если я все-таки ошибся в выводах, отвечу на вопрос. Завалившийся тест не существует сам по себе, как сферический конь в ваакуме. Если есть тест, значит есть тест кейс, который входит в тест сет. QA не тестируют черную коробку, они должны разбираться в продукте. Я не QA, более детально объяснить не смогу, но QA в состоянии мгновенно ответить, к какой(каким) юзер стори относился завалившийся тест, а дальше это уже ваша работа — связать юзер стори с бизнес требованиями, и это уже точно находится за рамками дискуссии об SCM системах.

dou.ua/...cles/to-kill-the-project тут в соседнем топике коллега составил вам список вредных советов ;)

читал вот это: stackoverflow.com/...ch-a-git-commit-came-from но большинство ответов данных и проголосованных там малоинформативны.
это «git branch —contains» малоинформативный ответ?
встречный вопрос: что именно вам дает, в какой ветке был создан коммит?

В статье уже это расписывал, но попытаюсь ещё раз. Как мы работаем — для каждой функционально отдельной фичи делается заглавный таск и своя ветка, привязанная к этому таску. Помимо «фича» веток есть ещё master, stable ветки, первая для интеграции, вторая — текущая версия на продакшн сервере. Далее, коммиты соответсвенно будут или в ветках, или напрямую в master/stable. Вопросы которые я хочу решать оперативно с точки зрения управления проектом — получить список всех изменений, сделанных по этой фиче. Второй вопрос который я могу задать, и хочу получить быстрый ответ — к разработке какой фичи относиться данная строка кода. Как я действую во втором случае — учитывая то, что фичи рождаются в ветках, моей задачей является найти ветку, и далее найти ассоциированый таск, таск может быть самодостаточным, может ссылаться на развёрнутые бизнес требования. Вот такая вот история. git branch —contains показывает с десяток бранчей, в которых находиться данный коммит, ведь с тех пор как коммит попадает в master, а от мастера делаются дальнейшие ветки. Возможно я как то неправильно это применяю? Меня интересует одна ветка, в которой данный коммит попал в код. Т е первая команда которую я запускаю (посредством своего ide конечно же, не буду сейчас на него указывать), получаю список строк кода, рядом коммит в котором последний раз менялась эта строка. Потом даю этот commit аргументом к git branch —contains и в общем случае получаю список всех локальных веток, в которые этот commit входит. Это малоинформативно и не является ответом на тот вопрос, на который я хотел найти ответ. Буду признатален если сможете рассказать как добиться нужного мне результата.

Потом даю этот commit аргументом к git branch —contains и в общем случае получаю список всех локальных веток, в которые этот commit входит.
да, тут согласен. поторопился с ответом.
на самом деле это можно посмотреть, найдя мердж коммит в trunk. если никто не правил commit message для merge commit’a, то там будет указано, какая ветка мерджилась.
конечно, можно оформить это в консольную команду, которая будет принимать хеш коммита и выдавать «исходную ветку».
но я вообще на другом хотел акцент поставить.
как я понял из переписки ниже, вы пытаетесь таким образом получитьб информацию о контексте, потому что девелоперы не желают нормально писать commit message.
так вот, вопрос: а откуда тогда уверенность, что коммиты будут в соответствующих ветках? на багофикс у вас отдельная ветка? на рефакторинг у вас отдельная ветка? если в ветке по разработке некой фичи есть коммит, который не понятно, как вообще связан, то имя ветки не скажет ничего.
если у вас в коммите будет нормальное описание и ссылка на соответствующие баги-стори, то «имя оригинальной ветки» вам вообще не надо будет.
я не про «воркэраунд для компенсации ущербности гита», а о том, что полагаться на имя ветки — не надежно с любой системой контроля версий.

идея то простая — если мы *уже* пользуемся бранчами при создании новых фич, то в дальнейшем можно было бы положиться на эту информацию для раскрутки обратного процесса (см ниже). но суть простая — и польза следующая — допустим заказчик поручает сделать фичу X, программист открывает код, начинает менять, и находит кусок логики, включая unit test который повалится после введения новой логики, для фичи X. Вот тут внимание вопрос — к кому идти с вопросом, и как его сформулировать? я обычно формулирую просто — логика фичи X, противоречит логике фичи Y (нахожу бизнес требование к Y по коммиту, далее таску и связке). Без этой связки фича X конечно заработает, но разборки потом почему логика X поломало Y, Z ложится целиком на плечи QA. Я не привык ломать а потом разбираться, лучше вначале разобраться, и делать свои изменения осознанно, в рамках понимания проекта целиком а не логики отдельной фичи которая делается сейчас

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

В компаниях работают разные люди, и для «эпизодического» пользователя SCM или того кто переходит с SVN важны вот эти все мелкие детали. Веб-дизайнеру или сисамдину, который работает с репозитарием раз в месяц, реально либо использовать GUI, либо начать с чего-то концептуально простого. Сетевая шара, Drpobox — понятно. SVN — на уровень сложнее. Mercurial — почти космос. Git — космос.

Они не глупые, просто оно им не нужно, как vi.

Черепашка в винде очень сильно упрощает всё. Да, в линухе нет аналогичной черепашки (вечный танец с бубном запустить аналог под очередным файл менеджером).
Личноя без какой VСS уже вообще работать не могу. Кроме того обычному программисту очень редко нужны все возможности этих систем, обычно достаточно pull, commit, push.

Есть и rabbit-vcs. Он наиболее близок к черепашке, но почему-то с ним вечно какие-то глюки. И интеграция вечно с глюками.
Вот сейчас в каждом дистре юникса свой недоделанный файл менеджер и, кажется, если уж делаете свой менеджер, то добавьте туда интеграцию c система контроля версий. Логично же, но нет — две кривые панельки с квадратными колесами. И получается, что подогнать линух под себя для разработки получается сильно дольше, чем Винду. Причем каждое очередное обновление в линухе неизвестно, что сломает. А еще репозитории, вечно устаревшие и для тех, что на основе убунты дуй в ppa. Это отступление было.
Но в итоге и оказывается, что для работы с git в линухе хорошо работает только консоль (а это сильно менее удобно, чем кликнуть кнопку в черепашке).
Только не надо предлагать начать мне писать аналог черепашки для линуха — другие задачи есть.

Не, интеграция по правому клику по файлу — это фигня.

Ну, когда тебе подсвечивает измененные файлы и т.п. — это, конечно, неудобно. Вот консоль с трехэтажными командами — это круто. И бамажка рядом, где несколько страниц этих команд выписано. Ой, а какой сейчас год? Неужто 1990?

Да вы, батенька, небось и IDE пользуетесь.

Таки да. Командной строки мне еще в 1990 хватило с xedit’ом.

На С++ без IDE таки тяжко. То ли дело javascript.

А отлаживать. Я ж Матлаб юзаю, а не Octave. IDE удобная и отлаживаться удобно.
А вот тот же QtCreator напрягает тормозами в отадчике.

Во-первых, если мы говорим о коммерческой разработке, то тут требование не только VCS системы, а полного флакона, включая CI, какой-то review board и тому подобное, причём связанное между собой. Тут упоминалась JIRA. Я с этим зверем, как со всем Atlassian’овским хозяйством, не сдружился, а на предыдущей работе наблюдал замечательный флакон Gerrit+Jenkins+RequestTracker. (Могу дать координаты, думаю, продадут дешевле, чем решения от JIRA.) И вот там часть обозначенных проблем уже принципиально решена: коммит без номера тикета в трекере просто не будет принят, и используется per-commit peer review (на базе Gerrit). Gerrit же не позволяет просто так удалять ветки, но и не светит их на каждый чих. Ещё из его вкусностей — общий id изменения, проходящий через разные релизные ветки и не меняющийся, как собственно Git commit id.

С другой стороны, старые ветки и нужно переносить в старый репозиторий (IMHO).

Во-вторых, в статье заметное количество фактических ошибок или необоснованных стилевых комментариев по Git. В частности (постараюсь не сильно дублировать уже отписавшихся коллег):

> И, соответственно,удобно, чтобы все рабочие ветки заливались на сервер, что по умолчанию происходит в mercurial.

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

> В Git, оказывается, есть разделение репозиториев на клоны для девелоперов (рабочие) и клоны для сервера (bare). Это сделано, видимо, в целях оптимизации, но в результате, чтобы обменяться кодом с соседом программистом, мне уже недостаточно будет просто написать hg push ssh://otheruser@othercomp, а потребуется создать bare репозиторий и организовать обмен кодом на его основе.

Можно свободно делать pull от соседа или push ему в не-текущую ветку и на не-bare репо. В текущую не допускается хотя бы потому, что могут быть конфликты с локальными правками, и удалённый пушер не вправе резолвить эти конфликты. Но из локальной ветки сам владелец запросто заберёт всё, что ему нужно, в пришедшем.

> git diff HEAD

git diff, просто.

git checkout -b branchname origin/branchname

git checkout $branchname (если настроен один дефолтный origin, что тривиально, а в случае создания по clone делается автоматически)

> Мне поначалу было сложно понять, что за origin и почему надо указывать ветку.

Точно так же — есть ремота по умолчанию (и ветку тоже можно строить, или задавать все, или группу по маске)

> Ну и закодированное git config по сравнению с обычным простым файлом .hg/hgrc

С простым файлом $REPO/.git/config или ~/.gitconfig

> Второй минус — к хорошему привыкаешь быстро. Поработав немного с mercurial, возвращаться на git довольно сложно, так как приходится вспоминать зубодробительный синтаксис для простых вещей.

Вкусовщина, но мне строго наоборот — git выучился почти мгновенно, а с Hg всё время проблемы из-за нарушения POLA. До этого были CVS и Subversion, так вот SVN резко сложнее из-за неочевидных подходов, а Git проще SVN, несмотря на особенности от распределённости.

> Тем более, на заведомо более слабую по фичам систему.

Верно. Одно только staging area по удобству использования достаточно, чтобы про Hg не вспоминать.

Valentin, а можете немного расписать как Вы пользуетесь staging area в git, потому как видимо многие этого не понимают, включая меня. У меня простой алгоритм работы — работаю с файлами, добавляю удаляю и тп, и потом делаю commit. Я выборочно могу указать какие файлы и изменения войдут в этот commit, какие нет. Если вдруг необходимо «отложить» коммит, есть команда git stash, аналогичная ей команда hg shelve/unshelve. Т е этого ф-ла мне хватает с головой, и реально staging area, где файлы могут отличаться от того, что реально будет коммититься по моему запутывает ситуацию. Когда именно это востребовано? Т е Вы допустим сделали изменения, готовитесь к commit, но commit не делаете а далее модифицируете файлы, понимаете что это коммититься пока не будете, и коммитите те, что лежат уже в staging? Или я как от не так понимаю?

Я выборочно могу указать какие файлы и изменения войдут в этот commit, какие нет.

Вот весь вопрос об уровне выборочности. Представим себе, что над локальной копией по сравнению с состоянием репозитория сделаны следующие изменения:
1. Добавление отладочной печати под ловлю конкретного бага (не предназначена для коммита).
2. Переименование переменных — для стиля (старое название соответствует ушедшему функционалу). Сам факт отставания названия обнаружен уже когда началось исправление бага.
3. Функциональное изменение — правка бага.

В некотором куске кода изменения находятся слишком близко друг к другу и с точки зрения diff относятся к одному чанку. Средствами указания конкретного чанка я не могу их разделить (например, в одной и той же строке поучаствовали правка бага и переименование, а отладочная печать примыкает к ним вплотную). Мне нужно получить коммит на переименование. Добавление целого файла не сработает. stash (shelve) — аналогично. add —patch — аналогично.
Работает только один вариант (для Git) — «add -e». Тогда в редактируемом диффе я формирую в этом конкретном чанке только переименование, срезая остальное.

После этого я вижу два диффа — между committed и staging (git diff —cached) — то, что я собираюсь коммитить; между staging и рабочей версией (git diff) — то, что не коммитится (правка бага и отладочная печать). Оба изменения чётко и понятно читаются, и я могу проверить глазами, что в них только необходимая суть каждого. Потом я говорю commit и перехожу к выделению второго изменения (правка бага), срезая из диффа отладочную печать.
С этого момента оба изменения локально зафиксированы, я могу сделать какой-нибудь sync на бэкапное хранение, могу сделать push в рабочую копию на сервере... важная часть работы сделана и расшарена. Отладочная печать в этой рабочей копии может оставаться ещё долго для последующей проверки (бывало, не удалял месяцами, пока не начинала явно мешать).

Конечно, можно было сделать это и без staging. Например, позвать stash, повторить переименование (дублирование уже сделанной работы), закоммитить, сделать stash pop и разобрать неизбежные конфликты (вторая дополнительная работа, причём в сильно менее удобном виде, чем при add -e). И зачем себе лишнюю работу делать? Я этих граблей с CVS’ом настрадался.

и реально staging area, где файлы могут отличаться от того, что реально будет коммититься по моему запутывает ситуацию.

Не запутывает, если про неё помнить. Вас же не запутывает тот же stash (shelve)? Если нужно тестировать локально то, что предназначено для пуша, потребуется сохранить stash, на неизменённой копии проверить полученное, сделать stash pop для восстановления работы... Так и тут — просто надо знать и помнить свойства инструмента. А кто не помнит, git status покажет факт и просто локального изменения, и чего-то в staging.

Т е Вы допустим сделали изменения, готовитесь к commit, но commit не делаете а далее модифицируете файлы, понимаете что это коммититься пока не будете, и коммитите те, что лежат уже в staging? Или я как от не так понимаю?

Именно так. По частям комплектуется набор правок для конкретного коммита, имея возможность внимательно подумать перед фиксацией.

Работает только один вариант (для Git) — «add -e».
спасибище за наводку. знал только про -p вариант, но он не всегда работает нормально даже для разделенных чанков, не говоря уже о наложенных друг на друга изменениях

Для небольших комманд mercurial однозначно выигрывает простотой. git рулит в оупен сорсе. имхо habrahabr.ru/post/168675

Сферичне Le huite в вакуумі масою 1 кг і об’ємом 1 кубічний метр.

git checkout -b branchname origin/branchname — перейти в ветку
Емм, для переходу в гілку достатньо написати:
git checkout branchname

git checkout -b branchname — це створення гілки і перехід в неї в скороченій формі, повна форма:
git branch branchname
git checkout branchname

Так PM ж не пише код. Код пишуть програмісти. То може нехай вони і вибирають?

Ветка может быть удалена
На своей машине можешь удалить всё, что хочешь. Но в главном репозитории, который находится на GitHub/GitLab, право имеешь только на пулл-реквест и ждать, когда кто-то с правами его примет. А тот, кто ответственный за приём пулл-реквестов, может уже и к коду требования выставлять, и к тексту коммита, и к количеству коммитов на фичу.

В защищённую ветку в GitLab пушить может только мастер. Можно разрешить пушить в неё девелоперам, но не нужно. А удалить такую ветку не может вообще никто (сначала нужно снять с неё защиту, для чего нужно быть мастером или овнером)
Вот скриншот интерфейса, в котором это настраивается c2n.me/3qagXfE

Удачи с выгребанием говнищща после force push в паблик репо.

Еще можно тему goto раскрыть в рамках коммерческой разработки, — вполне могут быть неожиданные открытия.

Категорически согласен, вот в таком (или тут) виде оно даёт множество неожиданных открытий в рамках коммерческой разработки.

фигасебе, непредсказуемый GO TO

Изначально думал не тратить время на комментарий, но, сделав себе крепкого кофе, приступим:
1.

Мне поначалу было сложно понять, что за origin и почему надо указывать ветку.
Кто же Вас заставляет писать origin?
2.
Ветка может быть удалена
По-Вашему это нормально, когда 100500 фича-бренчей висят после использования?
3.
регулярно наблюдаю процентов 40-60% коммитов без метки таска
А вот представьте, есть такая штука как hook, в скрипте настройки энва она устанавливается и в итоге Вы просто не сможете закомитить без метки таска. На одном из проектом, где я был, было 100% камитов с [PROJECT_NAME-JIRA_ISSUE_NUMBER] MESSAGE
4.
для удаления ветки в git используется не очень понятная конструкция
WTF? stackoverflow.com/a/2003515
5.
вы, как PM, скорее всего, не сможете переубедить свои программистов
Как PM у Вас есть возможность устанавливать правила на проекте


Я пользовался и hg, и git. Мне кажется, что для конечного пользователя (программиста, девопса или тестировщика) разницы нет, это довольно простой (и мощный, конечно) инструмент в использовании. Намного распространённей git, поэтому смысла изучать hg не вижу.
А ещё, перед написанием такого рода статьи, надо самому пройти курс git’a
Как PM у Вас есть возможность устанавливать правила на проекте
Её нет, но в данном контексте, эта фраза — Silver Bullet

Конечно всё зависит от конкретной ситуации, но так как заказчик может поставить перед фактом, что используем «то и это», так и ПМ может «порекоммендовать» что-то использовать.

Та да, аутсорс тоже палка о двух концах. У нас на проекте — Perforce и это грустно, бо просвета нет )))

Небось и виндой заставляют пользоваться

Стандартная интерпрайз солянка win\linux\mssql\oracle

И перфорс, и гит вместе используем. Нормально. Per aspera ad astra!

По-Вашему это нормально, когда 100500 фича-бренчей висят после использования?

Да. Что сделано, то сделано. Это остаётся для истории, возможных поисков источников проблем потом. Use-cases: (1) или заказчик спрашивает «зачем сделано X», и почему то обычно время таких разборок наступает через 1-2 года с начала проекта, когда никто уже не помнит кто и зачем это делал, а программист давно может работать где то ещё, либо юсе-кейс номер 2, когда программист встречает кусок непонятной ему бизнес логики, которая мешает ему реализовать другую фичу, и ему необходимо понять с каким бизнес кейсом было иницировано изменние этого участка кода. В описанном мной workflow это сделать очень просто.

Если ветки мозолят глаза в hg есть механизм «скрыть» ветку, т е —close-branch. Такая ветка в истории останется, но не будет висеть в списке открытых веток.

Так зачем знать в какой ветке было сие чудо сотворено? В каждом каммите есть информация о таске

Нужна сответствующая культура, да и загружать коммиты будет бесполезной инфой. Я не спорю, можно ввести жёсткое правило писать номер таска в commit msg, но в git рекомендованная длинна и так невелика — 50. туда надо вместить суть изменения, если писать и номер таска, это неудобно

Вы хотите сказать, что у вас таск-бренчи, а не юзер-стори бренчи?

И система расшифровок тасков

рекомендованная длинна
Первая строка. Через пустую строку можно написать подробнее, и не одну строку. И это не технические ограничения, это «так принято» и на любом проекте может быть принято по-разному.
туда надо вместить суть изменения, если писать и номер таска, это неудобно

Длина commit message практически неограничена. Если кто-то сказал про 50 — Вас просто обманули. Вот не самый длинный пример из линуксового ядра:

commit 37e81a016cc847c03ea71570fea29f12ca390bee
Author: Hans-Werner Hilse <hwhilse at gmail.com>
Date: Mon Jun 29 11:50:32 2015 +0200

um: Do not rely on libc to provide modify_ldt()

modify_ldt() was declared as an external symbol. Despite the man
page for this syscall telling that there is no wrapper in glibc,
since version 2.1 there actually is, so linking to the glibc
works.

Since modify_ldt() is not a POSIX interface, other libc
implementations do not always provide a wrapper function.
Even glibc headers do not provide a corresponding declaration.

So go the recommended way to call this using syscall().

Signed-off-by: Hans-Werner Hilse <hwhilse at gmail.com>
Signed-off-by: Richard Weinberger <richard at nod.at>

Бывают и длиннее (например, с трейсами, дампами регистров...)

И написание таких понятных сообщений — отдельная культура (если Ваши сотрудники всё укладывают в 5 слов в одной строке, это само по себе очень плохо).

Никто не настаивает на заносе ticket id в первую строку. Технически он может быть выловлен откуда угодно (у нас допускались, btw, несколько таких id).

Ограничение в 50 символов в первой строке сообщения это только для удобства некоторых стандартных тулзей вроде gitk, и оно регулярно нарушается по необходимости. Первая строка для сжатой сути, достаточной для чтения писем, но не для полного описания:)

у нас допускались, btw, несколько таких id)
мы указываем сразу story ID + task ID. плюс, бывает, несколько багов зафикшены одной правкой.

Про механизм скрытия не знал, но смысл сохранять старые ветки всё равно не вижу.

ли заказчик спрашивает «зачем сделано X», и почему то обычно время таких разборок наступает через 1-2 года с начала проекта, когда никто уже не помнит кто и зачем это делал
на самом деле, спасут только нормальные сообщения сообщения.
например, к вашей иллюстрации: в рамках фиче-бранчи «12457-мастер-регистрации» в очередном коммите удалили баннер. почему? какая связь? а если в стори 12457 не указано? а если, на самом деле, это удаление — рефакторинг по переносу в другое место, побочная операция ради улучшения структуры?

+100 — надо указывать такие важные подробности, как тип изменения (функциональность добавлена/удалена, стиль, рефакторинг, etc.) и не смешивать(!) разные типы в одном коммите; стилевые желательно делать до всех прочих, включая рефакторинг (это сокращает количество попыток поиска источника по blame/annotate).

мають ж люди, куди даремно тратити свій час і писати таке...

Якби не було витрачєно набагато більше часу на пошук деяких розбіжностей між бізнес вимогами та написаним кодом, я б цього не писав. Але є проблема, можливо дехто зумів ії побороти, буду вдячний за вказівку. Але якщо ні, ця стаття повинна мати сенс для інших PM.

Может я слепой, но я не нашёл НИЧЕГО полезного в Вашей статье. И не потому-что я такой весь умный, а потому-что ни один аргумент, для меня, не стоит ни гроша.

Жаль конечно. Не поделитесь секретом, как Вы обошли те проблемы, которые волнуют автора статьи? Т е связку бизнес требование и кода. Или не пытались решить такую проблему?

Я выше уже описал отдельным комментарием.

Предлагаю рассмотреть следующие отличия git vs. mercurial в контексте их удобства для PM и коммерческого проекта в целом:
— невозможность удаления веток, коммитов, т.е. изменения истории репозитория;
Как можно ставить в преимущества невозможность сделать что-то? Ну не надо оно вам — договоритесь в команде не удалять и не править историю и делов-то. Как-то же договариваются о других вещах, а не ищут VCS с наперед вшитым шаблоном описания коммита или с принудительным созданием фич-бранчей.
Как можно ставить в преимущества невозможность сделать что-то?
На этот вопрос ответить легко такой вот аналогией — вначале кодили на чистом PHP, не разделяя код программы и код HTML. А что: подход мощный, можно реализовать любые причуды. Только потом время показало что логичное ограничение и разделение кода на templates и код поограмы, упростило работу HTML кодеров в первую очередь, да и программисту стало полегче.

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

Как можно ставить в преимущества невозможность сделать что-то?

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

жду статью «двойные кавычки vs одинарные кавычки в javascript в комерческой разработке»

Сначала будет статья про пробелы vs табы

Я думал за табы давно бьют по рукам 3юнитовым сервером

Есть полно мест, где утверждённым стилем являются именно табы. Например, это классические юниксовые компоненты вроде ядер, coreutils и т.п.

Я справді дуже люблю hg, і для своїх особистих проектів надаю йому перевагу, а не git, проте з часом я маю все ж деякі розчарування стосовно нього. З ходу можу назвати наступне:

  • Відсутність staging area. В git її наповнювати можна в імперативній формі, і згодом видалити із неї файли, випадково туди занесені. Писати hg commit із складним фільтром для комміта важко, і виправляти такий комміт незручно або важко (як і через hg commit —amend, так і через hg strip —keep).
  • Імена гілок у hg вічні. Якщо планується якась експериментальна гілка, яку планується назвати «experimental», дуже бажано подумати ще раз, чи вартує їй давати саме таке ім’я, оскільки навіть з hg commit —close-branch створити нову гілку із таким іменем більше не можна буде. Ніколи. Навіть через два роки. Смішно, але тут навіть svn ліпше виглядає.
  • Закладки (bookmarks), які концептуально трохи ближчі до git-ових гілок, в hg випиляти інколи також складно (якщо можливо).
  • Субрепозиторії в hg мені особисто здаються «дикішими» за субмодулі в git, оскільки hg при коміті в батьківському репозиторії оновляє .hgsubstate, якщо, знову ж таки, в hg commit не вказати правильний фільтр.
  • .hgignore лише, по ходу, в кореневій директорії. Якщо субдиректорії мігрують з місця на місце з часом, це також означає, що шляхи в одному .hgignore також потрібно поправити вручну.

HG не идеален, статья вовсе не ставила целью показать что hg круче, скорее наоборот. Мне тоже не хватает опциональный работы с локальными ветками. Но всё таки, в определённом смысле, после ~5-6ми лет работы с Mercurial, хотел поделиться тем чувством комфорта которое он привнёс в нашу работу, и определённой обеспокоенностью тем, что git не везде идеален. Возможно в будущем мы увидим что то, что объединит в себе преимущества обоих систем.

і виправляти такий комміт незручно або важко
MQ Patch

До речі, та, забув, але це не «first-class citizen», як і rebase, який з нуля в hg відсутній.

Мушу додати все ж коментар і визнати деяку некомпетентність стосовно вічності гілок в hg. Як мені сьогодні підказали, «вічно» також можна трактувати по-різному. Так, зокрема, у моєму випадку «вічно» слід розглядати як те, що гілка навічно залишається історії і залишає за собою ексклюзивне право на своє ім’я. Проте, існує можливість «затінити» існуючу гілку (щоправда, перевіряв лише на закритій), додавши просто ключ «-f» у виклик команди «hg branch». Таким чином, нова гілка матиме таке ж ім’я, як і попередня. «hg up» оновлюватиме до останньої гілки із таким іменем.

Пожалуйста, выпилите эту статью. Неокрепшие умы могут подумать, что она правдива

Зашивать номер таски в бранч? А что если опечатался? =)

Я думал уже все перешли на Continuous Integration и пишут код в одной ветке под названием dev.

Я пользовался обоими системами и могу сказать что разница невелика, но Гит лучше =) Просто в Гите все продумано, поєтому и бранчи там нормальніе. А Меркуриал віглядит как неудачній клон Гита — все віглядит похоже, но что-то недоделано в нем...

Зашивать номер таски в бранч? А что если опечатался? =)
Тогда всё пропало, шеф ;-)))
Я думал уже все перешли на Continuous Integration и пишут код в одной ветке под названием dev.

Ну и нафига Вам ветки в таком случае вообще? При таком подходе можно и с SVN жить спокойно. Назывется он centralized workflow.

Но расскажите мне как в таком случае эти *все* пишут несколько фич в параллель? Ведь имплементация одной может занимать месяцы, нескоторых дни, некоторых часы. И вполне возможно CI отработает, только никто не будет ставить наполовину или на треть рабочую фичу в релиз. Именно потому задуман Feature Branch Workflow, самые лучшие иллюстрации работы которого описаны тут: www.atlassian.com/...lows/centralized-workflow

Ну и нафига Вам ветки в таком случае вообще?

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

Вероятно, под ветками вы подразумеваете «feature branches» — концепт, представленный в статье «A successful Git branching model». Неиспользование «feature» веток не означает, что ветки не нужны вообще. Просто другие люди используют ветки для другой цели — для длительной поддержки определенного набора версий — stable, staging, development. А для того, чтобы фича не растягивалась на месяцы, пытаются разбить ее на куски, закрывая их под общим «feature» флагом. И это не значит, что такой способ единственно возможный.

VCS — это инструмент, который не навязывает какой-либо способ использования. И если какой-то инструмент «заточен» под определенный способ — это не значит, что другой инструмент «кривой» и «громоздкий».

Я думал уже все перешли на Continuous Integration и пишут код в одной ветке под названием dev.
Да, багато хто перейшов вже. З zip-архіва.

Вброс на тему Г@вно vs Конфетка.
Натыкаясь на подобные статьи, понимаешь что «23-й кто-то там» это состояние души.
...
ТС перестаньте.
Я понимаю, что некоторое количество знаний у Вас перешло в качество.
Но не надо экстраполировать его на новые домены, в которых Вы не совсем эксперт.
Ещё и в ультимативной форме.
...
Команды в гите для вас не очень логичные!
А вас не смущает, что есть кран подъёмный и кран водопроводный?!
Это жизнь, она многообразнее всех вместе взятых проекций реального мира, под названием — люди.
...

Тогда как, например, в open source моделях разработки, обычно цели ставит перед собой отдельный разработчик, а этапность их исполнения и привязка к бизнес требованиям никого не интересует.
Это уже отметили. Это говорит человек, который скорее всего не контрибьютил ни в один опенсоурс проект.
...
Повторюсь, не пытайтесь экстраполировать ограниченный набор знаний на всевозможные домены, методики, механики, инструменты, модели.
...
Вам нравится Mercurial, бога ради. Решили поделиться опытом, как Вы зашиваете имя таски в имя ветки, а так как Mercurial не позволяет их удалять, у вас всё хорошо. Спасибо.
Но подход я Д’Артаньян все п..@.@.ы, никому не к лицу )))

Команды действительно нелогичные и немного криптованные и отрицать это — отрицать реальность. Но свыкнуться с этим можно. Можно поподробнее насчёт доменов, в которых я не эксперт? Потому как я бы не писал статью если бы не было реальных жизненных ситуаций, многократно повторяющихся, где я сталкиваюсь с ситуациями отрыва бизнес требований от реально написанного кода. Это статья для PM или тех лида. Также мне было бы очень интересно как реально решаются проблемы отслеживаемости (трассировки) изменений у Вас на проекте? Я не пытался отписаться в стиле

Д’Артаньян все п..@.@.ы
, наоборот с уважением отношусь к разным методологиям, но у меня свои, возможно неинтересные Вам проблемы, которые я пока не смог продуктивно и быстро решить на git. Будьте добры, подскажите, решается ли это простым образом в git, или надо переформатировать flow, и забыть о привязке требований к коду? Я буду рад подсказкам. Потому как сейчас приходится рыться в git blame, потом искать последний merge commit и пытаться экстраполировать информацию о том, какая фича была задумана в этом коммите.
Команды действительно нелогичные и немного криптованные и отрицать это — отрицать реальность
Никто не отрицает. Это технический долг, возвращать который уже наверное нет смысла.
Такие моменты — суть следствия существования ПО как такового.
Посмотрите как развивались git submodules или svn externals c их mergeinfo. Все это вращается вокруг extensibility и reusability программных систем.
Но это так, офтоп.
...
Теперь по сути.
но у меня свои, возможно неинтересные Вам проблемы
Проблемы одни и те же, просто называют их все по-разному.
Белой ниткой через статью проходит боль (без сарказма) — необходимость такого себе реверс инжиниринга: замапить фичу на уже созданный код. Могу предположить, что это частая проблема, много косяков и надо находить кто их сделал (чтобы потом наказывать :))
...
Как правильно заметили, git commit -m"#321 done" нормально сопряжёт бизнес требования и комит.
Если кто-то начнёт коллапсить комиты или менять историю, то это явный признак личностных\межличностных моментов.
И тут мы приходит к, эмпирически мной наблюдаемому на протяжении многоих лет, соотношению:
в 80% — виноваты процессы
в 20% — люди, саботаж, неприязнь и пр.
...
Тоесть необходимо предупреждать «неправильные» комиты, а не лечить их «следствия»
Как всегда Proactive vs Reactive.
...
Заливают бинарные файлы — ставьте хуки на формат файлов и\или размер.
Выпиливают банеры — запускайте тесты регрессии перед комитом и проверяйте что div с таких id был сгенерирован
и т.д. и т.п.
...
«Очень давно, я писал на Delphi, а файлы мы передавали через шаренные каталоги и мерджили руками» :)
...
Инструменты только позволяют создавать процессы.
А именно процессы являются определяющий моментом эффективности любого рода деятельность, в том числе и разработки ПО.
Так что Mercurial/Git/Perforce/TFVC/SVN/CVS не есть ключ к захвату Вселенной ).
Команды действительно нелогичные и немного криптованные и отрицать это — отрицать реальность
Как раз для этого и есть alias-ы в гите, которые позволяют сделать из
git log —graph —all —decorate
 — git glog указав что это алиас для строки выше — git-scm.com/...v2/Git-Basics-Git-Aliases.

Имхо, этот аргумент вообще высосан из пальца...

Для новичка в Unix и «chmod 755» — криптованно и нелогично. «И зачем эту всю муть придумали? Всегда использую 777 и не парюсь.»

Git ауже стандарт де-факто, Hg пролетает также как остальные JavaScript либы во времена jQuery

Где-то я это уже видел. А... когда-то так писали о преимуществах Дельфи перед C++. И учить проще, и иде-шечка продвинутые, да оно возможно даже так и было на самом деле.

А если Delphi заменить на Java?

Java евангелисты немного позже появились, когда дельфисты слились, но и их уже увольняют dou.ua/forums/topic/14818

И с++ заменить на с#

Удаление ветки в Гите не удаляет комиты, или я что-то путаю.

Всё правильно. Но как потом понять к разработке какой конкретной фичи этот коммит относился? Если ветку удалили, то видимо из содержания самого сообщения commit, а оно часто малоинформативно, типа «work in progress» , или «пофиксил баннер». Нет связки с бизнес требованием

Часто цепляют хук, который проверяет соответствие описания некому шаблону

Но как потом понять к разработке какой конкретной фичи этот коммит относился?
Можно в коментарии коммита номер таска писать :-).

Так я об этом в статье и пишу, что из за отсутствия в git неудаляемых веток крупные провайдеры рынка типа Atlassian начинают лепить подпорки, типа автосвязки тасков в Jira с номером таска указанного в commit. Ну это всё равно остаётся подпоркой, и пока я не нашёл способа заставить всех не забывать писать номер таска. Поставить хук на запрет коммитов без номера таска? Не будет ли это слишком жестоко?

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

Вадим, это другой стиль разработки, где все в «одной песочнице». Увы, это неприемлемо если в параллель разрабатывается много фич, каждая из которых имеет свой срок реализации. Если Вы смогли организовать работу команды по всем фичам одновременно и не мешая друг другу в одной ветке, могу только позавидовать. Мы, чтобы люди друг другу не мешали разделяем фичи ветками, по типу Feature Branch Workflow

Feature branch <> task branch. Часто на одну фичу приходится несколько таск и над ней работает несколько человек.

Мрак. CI для того и нужен, что бы интеграция проходила безболезненно. Откладывать интеграцию — пиррова победа. Сколько вы времени потом тратите на интегрейшн поинт? Сколько это попаболи?
www.slideshare.net/...in/continuous-integration рекомендую

какая разница номер таски в имени ветки или в описании коммита.
у нас воркфлоу следующие: создается локальная ветка TT#6548_осмысленное_имя_ветки
когда делаешь git commit то в commit message хуком вставляется TT#6548. потом ветка отправляется на ревью, если ревьювер поставил +2 ветка мерджится в мастер прямо на вебе геррита. т.о. вся история коммитов сохраняется со ссылками на таски.

Поправка: на ревью отправляется не ветка, а набор зависимых друг от друга коммитов. Один коммит — одно ревью.

А в чем здесь подпорка? Достаточно удобно — вижу ОЧЕНЬ детально все изменения относящиеся к конкретному таску по всем девелоперам непосредственно из карточки таска Джиры. Только это сторонний маркетплейс-плагин из коробки не устанавливается.

Почему подпорка ответить просто — если уж мы девелопим фичу в ветке, то логично было бы делать выводы оттуда а не заставлять разраба писать в каждом коммите. Во первых надо сделить за дисциплиной, чтобы не забывали ставить, ну или как уже советовали сделать запрет на push изменений без подписей тасков. Мы так делали пока работали в svn, ну и сейчас это применяем в Jira + Git. Да, мою проблему этот подход решает, но называть его особенно удобным, имея рядом пример другой организации того же процесса я не могу.

Як правило, в merge commit фігурує ім’я видаленої гілки.

Тільки не зовсім зручно потім шукати по історіі. Але це можливо, без сумнівів.

то видимо из содержания самого сообщения commit, а оно часто малоинформативно
знаете, потенциально в commit message _можно_ поместить намного больше, чем в навзвание ветки.
В коммерческой разработке принято ставить конкретные цели и отслеживать этапы выполнения работы. Тогда как, например, в open source моделях разработки, обычно цели ставит перед собой отдельный разработчик, а этапность их исполнения и привязка к бизнес требованиям никого не интересует.
В первом абзаце и такой бред. Уже страшно дальше читать.

А по сути это всё control version systems и разница между современными только в личных предпочтениях, как то одному нравятся зеленые яблоки, а другому карсные.

Красные сорта яблок часто слаще зелёных))

Ты просто не те зеленые яблоки ел.

часто
Субъективный опыт

Подписаться на комментарии