Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Git
Code

Фокусируемся на командном рабочем процессе в Git Фокусируемся на командном рабочем процессе в Git

by
Difficulty:BeginnerLength:ShortLanguages:
Sponsored Content

This sponsored post features a product relevant to our readers while meeting our editorial guidelines for being objective and educational.

Russian (Pусский) translation by Anna k.Ivanova (you can also view the original English article)

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

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

При этом для вас это обеспечит осязаемый командный рабочий процесс Git. Следующий пример основан на очень популярном рабочем процессе Git, разработанном Винсент Дриссеном по имени Git-Flow, хотя он отличается некоторыми ключевыми способами. В Интернете есть несколько популярных рабочих потоков Git - я предлагаю прочитать столько, сколько вы можете, затем ваша команда может выбрать набор правил, который лучше всего подходит для него.

Давайте начнем ваши исследования со следующего рабочего процесса:

Правило выше всего остального

master всегда развертывается. Всегда.

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

Во-вторых, master показывает текущее состояние проекта. Если необходимо предоставить исправления, то понятно с какой ветки нужно ответвлиться.

Наконец, развертываемый master является защитной сетью. Если master всегда доступен для развертывания, мы можем развернуть его без проблем. Беспокойство вызывает стресс, а стресс вызывает диспепсию. А это никому не нужно.

Стратегии ветвления

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

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

Что с именами?

Не существует никаких жестких правил по наименованию веток, особенно для ветвей с фичами. Если ветка является исправлением, вероятно, лучше всего добавить «fix» к ней. Если ветка является релизом, обычно рекомендуется, чтобы ветка выполняла этот формат: «release-X.X.X».

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

Вы говорите « Merge», я говорю « Rebase»

Как только ваша новая потрясающая фича закодирована, пришло время вернуть ее в общую ветку (предположим, что мы сливаемся в develop). Но прежде чем мержить в develop, убедитесь, что ваша ветка имеет последние изменения от develop, потому что могут быть конфликты.

Все разрешения конфликтов должны происходить в вашей ветке. Если вы ответвляетесь, чтобы сделать небольшое изменение/исправление, и вы не запушили ветку в удаленный репозиторий, сделайте rebase develop в вашу ветку, а затем смержите вашу ветку с develop. Делайте пуш и смело удаляейте свою локальную ветку с фичей.

Если вы запушили свою ветку, то сперва смержите develop в свою ветку (разрешая конфликты), а затем смержите свою ветку в develop. Делайте пуш и удаляйте как локальную так и удаленную ветку с фичей.

Делая rebase, всегда помните что это деструктивное действие. А это значит ... будьте осторожны! Rebase действительно полезен для очистки истории комитов, но не нужно переписывать историю, которую вы еще с кем-то делите.

Вот несколько правил, которые помогут вам при rebase:

  • Никогда не делайте rebase с тем, что было уже запушено. Ветка на который вы сейчас является только локальной? Тогда можно делать rebase. В противном случае rebase делать нельзя.
  • Rebase общих веток нужно делать в локальных ветвях. develop - это общая ветвь. my-awesome-feature - это локальная ветка. Теперь я готов смержить мою my‑awesome‑feature в develop, но я хочу убедиться, что все изменения, которые произошли в develop, сначала смержены в мою ветку с фичей:

Ревью

Допустим мы ответвлились, закодили, смержили/сделали reabse с develop, и теперь мы готовы смержить наш новый код назад в develop. Но должны ли мы? Возможно, кто-то должен сначала пересмотреть наши изменения ...

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

Именно здесь удобно использовать пул реквесты Git (и интерфейс Bitbucket). (Для обновления при открытии и управлении запросами в Bitbucket ознакомьтесь со второй частью этой серии, Используем Пул Реквесты и Ревью) Пул реквесты - на самом деле гораздо больше, чем просто ревью измененного кода. Запросы могут стать тредами для обсуждения и совместной работы по отдельным функциям. Вы можете вставлять фотографии для совместного использования дизайна, комментировать прямо на строках кода и даже использовать GIF и emojis, чтобы повеселиться.

Когда дело доходит до слияния запросов, предпочтительно, чтобы слияние было сделано тем же разработчиком, который открыл запрос, потому что это, скорее всего, человек, который написал новый код. Чтобы добиться этого, рецензенты должны оставить комментарий, одобряющий новый код, но при этом не нажав кнопку слияния. После того, как товарищ по команде одобряет код (либо фигурально, либо буквально с помощью :thumbsup: emoji), создатель запроса может его смержить. Ревью плюс чистые логи - по истине замечательная вещь!

Люблю выкатывать свой код

Как только ветка develop будет готова к релизу, мы мержим ее в master.

Обратили внимание на флаг --no-ff? Это гарантирует, что слияние не будет быстрой перемоткой вперед, поэтому оно создаст новую фиксацию изменений. Зачем на это? Потому что мы сможем добавить тег! Добавляем комиту тег, как новая версия:

Затем сливает master обратно в develop так, чтобы develop имела коммит с версией.

Говоря о версиях, мы должны использовать семантическое управление версиями. То есть MAJOR.MINOR.PATCH. В общем, MAJOR - это целый номер версии - он используется для массовых изменений и / или этапов. Разрешено нарушать совместимость. MINOR используется для новых функций. Он не должен нарушать совместимость. PATCH предназначен для небольших изменений и исправлений и не должен нарушать совместимость. Мы должны быть в предварительном релизе (0.x.x), пока не запустимся.

Хот фиксы

Мы никогда не должны выкладывать ошибки.

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

Чтобы сделать исправление, откройте master, сделайте исправление, затем выполните не- fast-forward слияние в master. Сделайте тег, а затем слейте master обратно в develop (потому что мы хотим чтобы в develop тоже появился фикс). Не стесняйтесь удалять ветвь исправления.

Пришло время для комитов

Давайте поговорим о сообщениях Git commit. Соблюдение общего формата значительно облегчит просмотр наших логов. Вот несколько хороших правил:

  • Сообщения должны быть написаны в настоящем (императивном) времени: «Исправить ошибку ...» вместо «Исправлена ошибка ...» или «Исправляю ошибку ...».
  • Первая строка (или строка темы) должна содержать краткое резюме фиксации (предпочтительно 50 символов или менее) с первым заглавным словом.
  • Если итоговая строка нуждается в пояснении, вы можете, после пустой строки, написать описание. Описание должно быть в форме абзаца с надлежащей капитализацией и пунктуацией.
  • Сообщения должны быть размещены на 72 столбцах, чтобы логи в наших терминалах выглядели красиво.

Если вы хотите прочитать больше о правильном написании сообщений Git, взгляните на пост Tim Pop.

Сделай сам

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

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

Ознакомьтесь с некоторыми альтернативами рабочего процесса Git-Flow в руководстве по рабочим потокам Atlasian's Git.



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

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

При этом для вас это обеспечит осязаемый командный рабочий процесс Git. Следующий пример основан на очень популярном рабочем процессе Git, разработанном Винсент Дриссеном по имени Git-Flow, хотя он отличается некоторыми ключевыми способами. В Интернете есть несколько популярных рабочих потоков Git - я предлагаю прочитать столько, сколько вы можете, затем ваша команда может выбрать набор правил, который лучше всего подходит для него.

Давайте начнем ваши исследования со следующего рабочего процесса:

Правило выше всего остального

master всегда развертывается. Всегда.

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

Во-вторых, master показывает текущее состояние проекта. Если необходимо предоставить исправления, то понятно с какой ветки нужно ответвлиться.

Наконец, развертываемый master является защитной сетью. Если master всегда доступен для развертывания, мы можем развернуть его без проблем. Беспокойство вызывает стресс, а стресс вызывает диспепсию. А это никому не нужно.

Стратегии ветвления

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

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

Что с именами?

Не существует никаких жестких правил по наименованию веток, особенно для ветвей с фичами. Если ветка является исправлением, вероятно, лучше всего добавить «fix» к ней. Если ветка является релизом, обычно рекомендуется, чтобы ветка выполняла этот формат: «release-X.X.X».

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

Вы говорите « Merge», я говорю « Rebase»

Как только ваша новая потрясающая фича закодирована, пришло время вернуть ее в общую ветку (предположим, что мы сливаемся в develop). Но прежде чем мержить в develop, убедитесь, что ваша ветка имеет последние изменения от develop, потому что могут быть конфликты.

Все разрешения конфликтов должны происходить в вашей ветке. Если вы ответвляетесь, чтобы сделать небольшое изменение/исправление, и вы не запушили ветку в удаленный репозиторий, сделайте rebase develop в вашу ветку, а затем смержите вашу ветку с develop. Делайте пуш и смело удаляейте свою локальную ветку с фичей.

Если вы запушили свою ветку, то сперва смержите develop в свою ветку (разрешая конфликты), а затем смержите свою ветку в develop. Делайте пуш и удаляйте как локальную так и удаленную ветку с фичей.

Делая rebase, всегда помните что это деструктивное действие. А это значит ... будьте осторожны! Rebase действительно полезен для очистки истории комитов, но не нужно переписывать историю, которую вы еще с кем-то делите.

Вот несколько правил, которые помогут вам при rebase:

  • Никогда не делайте rebase с тем, что было уже запушено. Ветка на который вы сейчас является только локальной? Тогда можно делать rebase. В противном случае rebase делать нельзя.
  • Rebase общих веток нужно делать в локальных ветвях. develop - это общая ветвь. my-awesome-feature - это локальная ветка. Теперь я готов смержить мою my‑awesome‑feature в develop, но я хочу убедиться, что все изменения, которые произошли в develop, сначала смержены в мою ветку с фичей:

Ревью

Допустим мы ответвлились, закодили, смержили/сделали reabse с develop, и теперь мы готовы смержить наш новый код назад в develop. Но должны ли мы? Возможно, кто-то должен сначала пересмотреть наши изменения ...

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

Именно здесь удобно использовать пул реквесты Git (и интерфейс Bitbucket). (Для обновления при открытии и управлении запросами в Bitbucket ознакомьтесь со второй частью этой серии, Используем Пул Реквесты и Ревью) Пул реквесты - на самом деле гораздо больше, чем просто ревью измененного кода. Запросы могут стать тредами для обсуждения и совместной работы по отдельным функциям. Вы можете вставлять фотографии для совместного использования дизайна, комментировать прямо на строках кода и даже использовать GIF и emojis, чтобы повеселиться.

Когда дело доходит до слияния запросов, предпочтительно, чтобы слияние было сделано тем же разработчиком, который открыл запрос, потому что это, скорее всего, человек, который написал новый код. Чтобы добиться этого, рецензенты должны оставить комментарий, одобряющий новый код, но при этом не нажав кнопку слияния. После того, как товарищ по команде одобряет код (либо фигурально, либо буквально с помощью :thumbsup: emoji), создатель запроса может его смержить. Ревью плюс чистые логи - по истине замечательная вещь!

Люблю выкатывать свой код

Как только ветка develop будет готова к релизу, мы мержим ее в master.

Обратили внимание на флаг --no-ff? Это гарантирует, что слияние не будет быстрой перемоткой вперед, поэтому оно создаст новую фиксацию изменений. Зачем на это? Потому что мы сможем добавить тег! Добавляем комиту тег, как новая версия:

Затем сливает master обратно в develop так, чтобы develop имела коммит с версией.

Говоря о версиях, мы должны использовать семантическое управление версиями. То есть MAJOR.MINOR.PATCH. В общем, MAJOR - это целый номер версии - он используется для массовых изменений и / или этапов. Разрешено нарушать совместимость. MINOR используется для новых функций. Он не должен нарушать совместимость. PATCH предназначен для небольших изменений и исправлений и не должен нарушать совместимость. Мы должны быть в предварительном релизе (0.x.x), пока не запустимся.

Хот фиксы

Мы никогда не должны выкладывать ошибки.

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

Чтобы сделать исправление, откройте master, сделайте исправление, затем выполните не- fast-forward слияние в master. Сделайте тег, а затем слейте master обратно в develop (потому что мы хотим чтобы в develop тоже появился фикс). Не стесняйтесь удалять ветвь исправления.

Пришло время для комитов

Давайте поговорим о сообщениях Git commit. Соблюдение общего формата значительно облегчит просмотр наших логов. Вот несколько хороших правил:

  • Сообщения должны быть написаны в настоящем (императивном) времени: «Исправить ошибку ...» вместо «Исправлена ошибка ...» или «Исправляю ошибку ...».
  • Первая строка (или строка темы) должна содержать краткое резюме фиксации (предпочтительно 50 символов или менее) с первым заглавным словом.
  • Если итоговая строка нуждается в пояснении, вы можете, после пустой строки, написать описание. Описание должно быть в форме абзаца с надлежащей капитализацией и пунктуацией.
  • Сообщения должны быть размещены на 72 столбцах, чтобы логи в наших терминалах выглядели красиво.

Если вы хотите прочитать больше о правильном написании сообщений Git, взгляните на пост Tim Pop.

Сделай сам

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

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

Ознакомьтесь с некоторыми альтернативами рабочего процесса Git-Flow в руководстве по рабочим потокам Atlasian's Git.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.