Pull to refresh
  • by relevance
  • by date
  • by rating

Branching Guidance от Microsoft

Version control systems *
Добрейшего.

Набрёл на неплохой текст от команды Microsoft Team Foundation Server: Branching Guidance
Будущим и нынешним пользователям обозначенной системы предлагается:
  1. проникнуться важностью ветвления и слияния изменений для работы больших команд;
  2. узнать, какие типы веток бывают и как строить изоляцию работы на их основе;
  3. посмотреть на практических примерах как надо правильно отращивать и мёржить изменения.
Что пишут?
Total votes 17: ↑11 and ↓6 +5
Views 908
Comments 2

UTP — Выпуск 3

Lumber room
Завершение разговора о распределенных системах

— немного об установке
— самую малость о GUI
— побольше про ветки и слияние

* Запись на выезде с соотв. качеством

** Этот выпуск тоже потерялся в момент выхода. В порядке исправления — выкладываю как только вспомнил

подписка на utp.umputun.com
Total votes 28: ↑23 and ↓5 +18
Views 234
Comments 0

Удачная модель ветвления для Git

Git *
Translation
Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

Читать дальше →
Total votes 180: ↑171 and ↓9 +162
Views 860K
Comments 105

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

Git *Version control systems *Mercurial *
Translation
Некоторое время назад я опубликовал очень многословное сочинение, где пытался объяснить, почему Git серьёзно поломан, и почему всем следует вместо этого пользоваться Mercurial, до тех пор, пока разработчки Git его не починят. Ну ладно, я был не настолько груб, но близок к этому.

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

Ниже я нарисовал упрощёный граф истории репозитория Git с тремя созданными ветками: «master», «release» и «topic». До того, как энтузиасты Git начнут ругаться, что я исхитрился показать нереально плохой случай запутанности истории, позвольте мне заверить вас, что это на самом деле ещё упрощённый пример. У меня есть доступ к реальному репозиторию Git, где создано шесть рабочих веток релизов, около сорока рабочих тематических веток и несколько сотен ранее существовавших веток, которые уже удалены с центрального сервера.
Читать дальше →
Total votes 103: ↑87 and ↓16 +71
Views 59K
Comments 130

Проблемы релиз-менеджмента maven проектов при CI подходе к разработке ПО

Version control systems *
Sandbox
Прочитав статью
«Простой релиз-менеджмент средствами Git»
захотелось поделиться парой своих мыслей по поводу релиз-менеджмента maven проектов.

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

В кратце: главная проблема релиз-менеджмента maven проектов — это сам maven, который, не был разработан с учетом требований CI (Continuous Integration) подхода к разработке ПО.
Парадигма SNAPSHOT версий устарела с тех пор, как CI стало стандартным подходом к разработке ПО.

Более подробно далее.
Читать дальше →
Total votes 7: ↑6 and ↓1 +5
Views 7.7K
Comments 26

Основы использования бранчинга для параллельной разработки

Programming *Version control systems *
Sandbox
Вступление

Как справедливо заметил Fred Brooks, серебряной пули, способной поразить зверя разработки программного обеспечения, не существует. Пока возникают новые требования, идеи и находятся новые баги, программы живут и изменяются. Путь, который проходит код от версии к версии, может быть крайне сложен и извилист. К его созданию причастно много людей: разработчики, тестировщики, бизнес-аналитики, заказчики и т.п. Несмотря на то, что существует много разных видов разработки – аутсорсинг, продуктовая разработка, open-source и т.п., проблемы, стоящие перед командой, остаются примерно одинаковыми. Программное обеспечение – вещь сложная, потребитель хочет получить его как можно быстрее (и дешевле). Качество при этом должно быть приемлемым. Перед командой разработки стоит серьезная задача – наладить эффективное взаимодействие. Одним из самых главных средств коллаборации внутри команды разработчиков является сам код, который они пишут.

Читать дальше →
Total votes 37: ↑31 and ↓6 +25
Views 30K
Comments 72

Моделирование истории в централизованных и распределенных системах управления версиями

Programming *Version control systems *

Вступление


В своей практике мне довелось участвовать в миграции проекта (codebase имел 5+ лет истории) с централизованной системы управления версиями (centralized VCS — SVN) на распределенную (distributed VCS — Mercurial). Подобные активности часто сопровождаются определенным количеством FUD (fear, uncertainty and doubt) среди команды, вовлеченной в этот процесс. Если технические моменты конвертации (структура новых репозиториев, инструментальная поддержка, работа с большими бинарными файлами, кодировки и т.п.) по большему счету будут решены в определенный момент, то вопросы, связанные с преодолением кривой обучения для команды для эффективного использования новой системы, на момент перехода могут только начинаться.

При таких переходах важно измение взгляда на новую систему контроля версий и ее использование (mindset shift). Тут очень помогает хорошее понимание принципов, на которых основаны VCS. Если разобраться в основах, использование системы заметно упрощается. Соответственно, данный материал будет посвящен различиям в моделировании истории между централизованным и децентрализованным системами управления версиями.
Читать дальше →
Total votes 7: ↑7 and ↓0 +7
Views 6K
Comments 2

FeatureBranch

Git *
Translation
С распространением распределенных систем управления версиями (DVCS), таких как Git и Mercurial, я все чаще вижу дискуссии на тему правильного использования ветвления(брэнч) и слияния(мердж), и о том, как это укладывается в идею непрерывной интеграции (CI). В данном вопросе есть определенная неясность, особенно когда речь заходит о feature branching (ветвь на функциональность) и ее соответствие идеям CI.

Простой (изолированный) Feature Branch

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

Я проиллюстрирую свои мысли следующим рядом диаграмм. В них основная линия разработки (trunk) отмечена синим, и двое разработчиков, отмеченные зеленым и фиолетовым (Reverend Green и Professor Plum).

image

Читать дальше →
Total votes 40: ↑38 and ↓2 +36
Views 20K
Comments 27

GitHub Flow: рабочий процесс Гитхаба

Git *GitHub
Translation
Краткое предисловие переводчика.
Захватывающе интересная статья одного из разработчиков «GitHub Inc.» о принятом в компании рабочем процессе потребовала употребить пару специальных терминов при переводе.

То понятие, для которого на английском языке достаточно одного слóва «workflow», на русский приходится переводить словосочетанием — «рабочий процесс». Ничего лучше не знаю ни сам я, ни при помощи гуглоперевода так что и мне, и читателям придётся с этим мириться, хотя бы и поневоле.

Другое понятие, «deploy», на русский часто переводят словом «развёртывание», но в моём переводе я решил вспомнить оборот из советского делопроизводства — «внедрение инноваций на производстве» — и стану говорить именно о «внедрении» новых фич. Дело в том, что описанный ниже рабочий процесс не имеет «выпусков» (releases), что делает несколько неудобными и речи о каком-либо «развёртывании» их.

К сожалению, некоторые переводчики бывают склонны грубо убивать сочную метафору «иньекции» (или даже «впрыскивания», если угодно), содержающуюся в термине «code injection», так что и его также переводят словосочетанием «внедрение кода». Эта путаница огорчает меня, но ничего не могу поделать. Просто имейте в виду, что здесь «внедрением кода» я стану назвать внедрение его именно в производство (на продакшен), а не в чей-нибудь чужой код.

Я стремился употреблять словосочетание «в Гитхабе» в значении «в компании GitHub Inc.», а «на Гитхабе» — в значении «на сайте GitHub.com». Правда, иногда разделять их сложновато.

Проблемы git-flow


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

Однако и у git-flow есть проблемы. Я не раз слыхал мнения людей, выражавших неприязнь к тому, что ветви фич отходят от develop вместо master, или к манере обращения с хотфиксами, но эти проблемы сравнительно невелики.

Для меня одной из более крупных проблем git-flow стала его сложность — бóльшая, чем на самом деле требуется большинству разработчиков и рабочих групп. Его сложность ужé привела к появлению скрипта-помощника для поддержания рабочего процесса. Само по себе это круто, но проблема в том, что помощник работает не из GUI Git, а из командной строки, и получается, что те самые люди, которым необходимо действительно хорошо выучить сложный рабочий процесс, потому что им вручную придётся пройти все шаги его — для этих-то людей система и недостаточно удобна для того, чтобы использовать её из командной строки. Вот что становится крупною проблемою.

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

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

Рабочий процесс Гитхаба


Читать дальше →
Total votes 111: ↑105 and ↓6 +99
Views 117K
Comments 47

Модель ветвления и управления модулями git для большого проекта

РЕЛЭКС corporate blog Git *Version control systems *
Без малого два года назад мы начали использовать в разработке нашего флагманского проекта СУБД ЛИНТЕР новую модель ветвления и управления подмодулями git-а. Десятки тысяч коммитов, сделанные за это время группой разработчиков, позволяют с определенной долей уверенности считать нововведения успешными. Эта статья — краткий обзор принципов организации хранилища исходных кодов в большом проекте на базе альтернативной реализации модулей git, сложившейся стратегии ветвления и инструментария linflow.


Читать дальше →
Total votes 29: ↑26 and ↓3 +23
Views 34K
Comments 8

Trunk Based Development и Spring Boot, или ветвись оно все по абстракции

Java *Git *DevOps *
Sandbox
Tutorial

Всем привет!

Закончилась осень, зима вступила в свои законные права, листья уже давно опали и перепутанные ветви кустарников наталкивают меня на мысли о моём рабочем Git репозитории… Но вот начался новый проект: новая команда, чистый, как только что выпавший снег, репозиторий. "Тут все будет по другому" - думаю я и начинаю "гуглить" про Trunk Based Development.

Если у вас никак не получается поддерживать git flow, вам надоели кучи этих непонятных веток и правил для них, если в вашем проекте появляются ветки вида "develop/ivanov", то добро пожаловать в под кат! Там я пробегусь по основным моментам Trunk Based Development и расскажу о том, как реализовать такой подход, используя Spring Boot.

Читать далее
Total votes 9: ↑9 and ↓0 +9
Views 5.3K
Comments 14