Должен ли я создать ветку для отдельных коммитов?

Question

Я новичок в Git и в ветвлении. В нашей команде есть несколько сайтов, которые требуют простого обслуживания (добавление новой страницы, исправление некоторых ссылок и т. Д.). Коммиты обычно содержат все запрошенные функции. Я не уверен, стоит ли нам создавать ветку или мы можем просто взять на себя обязательство освоить? В конце концов, коммиты названы и дают понять, что мы сделали. Я чувствую, что ветви на самом деле создают больше сложности для таких простых задач. Или я ошибаюсь?

Answer 1

В качестве приблизительного указания:

Существуют коммиты для обновления состояния ветви, а ветви существуют как альтернативные представления вашей кодовой базы.

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

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

В этом отношении Git похож на любой SCM.Что отличает Git от ветвления, так это то, что ветки очень легко создавать и (несколько) легко объединять.Это означает, что обычным рабочим процессом является добавление мастера в незавершенное производство для новой функции, а затем внесение изменений.Когда вы будете удовлетворены, вы можете объединить свою ветку с мастером.Это просто улучшение по прямым коммитам - вы создаете «альтернативную реальность» нестабильного мастера, улучшаете его, затем объединяете его с реальным мастером - но чистый эффект тот же: ваши коммиты в альтернативномреальность в конечном итоге приземляется в мастере, как будто вы всегда делали их там .Конечная цель всего этого обхода состоит в том, что ваши коммиты показывают линейный марш во времени изменений.

Answer 2

Вот мой способ работы. Вы также можете увидеть некоторые хорошие комментарии от Мартина Фаулера и других. Хорошее обсуждение: https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

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

Branch-за Feature

Большое ПОЧЕМУ: быстрая, гибкая, качественная и уверенная разработка / развертывание / тестирование и т. Д. Это делает бизнес счастливым.

В форме точки, неорганизованной и грубой:

Особенности маленькие

Ветвь за особенность старой школы означала, что ветви были большими и долгоживущими, чтобы избежать необходимости интеграции, потому что это было больно. Это был замкнутый круг, так как объект будет все дальше и дальше расходиться с другими объектами или основной линией. Функции должны быть как можно более атомарными, и ваш процесс разработки должен соответствовать принципу открытого закрытия. Черты должны быть маленькими.

Неустанно интегрируйся

Они должны быть интегрированы в интеграционную ветвь почти так же часто, как вы их делаете. Это дает обратную связь немедленно. У вас есть какой-то CI, запущенный из ветви интеграции, чтобы сообщить вам, не влияют ли ваши изменения на другую работу. Это дает вам немедленную обратную связь по интеграции на основе соединительных линий, сохраняя при этом вашу работу организованной и гибкой.

Не делать обратных слияний

Или, по крайней мере, избегать их. Обратное слияние - это то, где вы хотите использовать что-то из ветви интеграции, чтобы помочь вам выполнить работу с этой функцией. Это запах, что у вас нет независимых историй. Разумная середина - сбор вишни. Успешно подобранный коммит не вызовет проблем при слиянии в будущем.

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

Вовлечение QA с самого начала

Это уже не должно быть спорным вопросом. Мы все знаем, насколько важны тесные петли обратной связи. Не должно быть отдела QA с сотрудниками QA. QA должна быть шапкой, которую носят разные или одни и те же люди в разное время.

Знание ваших Критериев принятия и того, как вы будете их доказывать с самого начала, является неотъемлемым условием получения большого количества полезных вещей, в том числе успешного полка с ответвлением за элемент.

В основе этого лежит надлежащий DSL на языке повсеместного распространения (см. Проект, управляемый доменом). Инструментом, который лучше всего связывается с владельцем продукта, регрессионным тестированием / тестированием спецификаций и обратной связью, в настоящее время является StoryTeller. Одна вещь, которую он предлагает, что никакие другие инструменты не предлагают, - это сообщение человеку, пишущему приемочные испытания, о том, что система способна делать с наименьшим количеством трения, вызванного технологией. Вы просто выбираете, что хотите сделать, нажимая на ссылки, заполняя текстовые поля и выбирая из выпадающих. Нет никаких предположений относительно того, как инструмент может интерпретировать ваш текст произвольной формы с его регулярным выражением и английским совершенством.

Поделитесь своей тяжелой работой

При слиянии будут конфликты. Это факт жизни, когда работа выполняется более чем одним человеком. Когда вы часто интегрируете свою функцию в ветку интеграции, конфликты, которые вы решаете, следует помнить. Это делается с помощью grererere, но может быть смоделировано в других системах без особых усилий. Ключ заключается в том, чтобы настроить способ передачи этих конфликтов автоматического разрешения остальным членам команды.

Теперь любой, кто попытается интегрировать эту функцию и столкнется с этим конфликтом, не должен будет ее разрешать. Для сборки не требуется dev. Это ручной раздел прямо сейчас, если это необходимо. Я должен был опубликовать сценарий примерно через неделю, который делает это за кулисами. Если вы хотите сделать это самостоятельно, посмотрите не дальше, чем в папку .git / rr-cache в вашем хранилище. Простая синхронизация между всеми разработчиками - это необходимый минимум.

Извлечение функций более эффективно, чем их добавление

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

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

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

Нет конфликтов. Помните rerere и тому подобное? Любой должен быть в состоянии сделать это, если вы следовали приведенным здесь практикам. Вот почему «тяжелая работа» должна быть разделена.

Ключ в том, что мы "выбросили" все предыдущие слияния и должны их переделать. Но, вспоминая наши разрешения конфликтов, это теперь тривиальный вопрос. Если вы сомневаетесь, мы на самом деле не выбросили их, они все еще там, чтобы ссылаться или использовать. Функциональность Git pick-ax позволяет действительно легко находить определенные изменения кода, если вы не знаете, где искать.

Гигантские рефакторинги

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

Любые трудности, с которыми вы можете столкнуться, будут смягчаться тем фактом, что вы неуклонно делитесь своими решениями конфликтов и постоянно интегрируетесь. ПРАВИЛЬНАЯ ОТРАСЛЕВАЯ ФУНКЦИЯ НАХОДИТСЯ НА НЕПРЕРЫВНОЙ НЕПРЕРЫВНОЙ ИНТЕГРАЦИИ

Тогглы - это хак

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

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

Это Git Flow Улучшено

Большая часть этого способа работы началась с отличного поста под названием «Git Flow - успешная стратегия ветвления». Важным дополнением к этому процессу является идея, что все элементы в итерации запускаются из общей точки. Это будет то, что вы выпустили для последнего. Это дает нам детальную, элементарную, гибкую природу, которую должны продемонстрировать функции, чтобы мы могли максимально эффективно работать с ними.

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

Будет плохо, если вы используете старые инструменты

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

Надеюсь, это поможет!

Answer 3

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

• Вы можете создать ветку для каждого изменения или вообще не создавать ее.
• Вы можете использовать удаленные ветви, общие для разработчиков, или только локальные ветви.
• Вы можете объединить ветви и оставить ветви видимыми, или вы можете сильно перебазировать и слить вперед, чтобы ваша история никогда не показывала одну параллельную линию.

Все, что мы вам здесь скажем, будет вопросом личных предпочтений. Лично я предпочитаю всегда создавать локальную ветвь для любого типа изменений. Это потому что:

• У меня включен no-ff, и легко отменить изменение или серию изменений, если у них есть связанный коммит слияния.
• Легко предотвратить смешивание нескольких изменений. Я могу быть в середине несрочного изменения, когда сталкиваюсь с срочным. Вы можете использовать git stash для хранения ваших изменений, но я нахожу отдельные ветви менее запутанными. (Часто я проверяю свою работу с сообщением коммита «РАБОТАЕТ В ПРОГРЕССЕ». Затем, когда я возвращаюсь к ветви, я делаю git reset HEAD~1, чтобы отменить этот последний коммит [но сохранить изменения] и продолжить работу.)
• Наличие ветки побуждает меня создавать меньшие коммиты (меньше изменений), что упрощает их правильное объединение позже.

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

Answer 4

Могу ли я предложить взглянуть на поток Git?http://nvie.com/posts/a-successful-git-branching-model/

https://github.com/nvie/gitflow

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

Answer 5

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