Эта публикация от Мэтта Шелтона из Nuance Healthcare — первая статья из серии, где он описывает, как его команда переходила из Subversion в Git, почему было принято такое решение и с чем пришлось столкнуться в процессе перехода. Мэтт уже выступал на эту тему на конференции Atlassian Summit 2015. В этой серии статей он подробно расскажет обо всех темах, которые не успел затронуть в получасовом докладе.

Итак, мы переходим на Git и довольны моделью Git-flow. Что дальше? Время тестировать! Моя замечательная команда разработчиков составила список «подопытных» в Confluence: в него вошли рабочие процессы, которые используются сегодня, и те, которые могут понадобиться для реализации всяких странных идей в будущем. После этого мы создали идентичную структуру проекта (но без кода, просто файл pom.xml) и опробовали в ней каждый рабочий процесс.

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

Есть целый вагон и маленькая тележка полезных руководств о том, как обновлять форки по вышестоящим репозиториям (а если вас интересует, зачем в корпоративной среде могут понадобиться форки, вот несколько причин). В этой публикации я расскажу кое-что о том, как форки взаимодействуют с вышестоящими ветками. Вас ждут основы, рассказ о подводных камнях, интересный совет, а в заключение — сильная зависть или сильный энтузиазм; выбор за вами. Стало интересно? Читайте далее.

Всего два с половиной месяца назад вышла версия git 2.0.0, а теперь нас порадовали промежуточной версией git 2.1.0 с массой захватывающих новых функций!

Использование подмодулей при разработке в Git позволяет включать в базу кода другие проекты: их история хранится в отдельном месте, но синхронизируется с вашей. Это удобный способ решения проблем с зависимостями и библиотеками от поставщиков. Как и в случае со многими другими вопросами, касающимися git, насчет этого подхода есть разные мнения. Чтобы умело им пользоваться, нужно немного его изучить. О подмодулях и так уже полным-полно хорошей, подробной информации, поэтому пересказывать ее я не буду. Вместо этого я поделюсь кое-какими интересными приемами, позволяющими использовать эту функцию максимально эффективно.

Вопрос несложный: если команда по разработке ПО использует git и функциональные ветки, как лучше всего включать готовую работу обратно в основную линию разработки? Это одна из тех постоянно возникающих дискуссий, где обе стороны имеют твердое мнение, и вести осмысленный разговор бывает непросто (другие примеры горячих споров легко найти в Интернете).

Сегодня для внесения исправлений в проект достаточно создать форк (чтобы в свое удовольствие возиться с полной удаленной копией проекта), выбрать нужный файл, нажать Edit (Правка) и сделать коммит с изменениями.

Задумайтесь над следующими вопросами. Как вы обрабатываете зависимости проекта с помощью git? Наш проект состоит из нескольких взаимозависимых репозиториев. Сейчас мы управляем ими с помощью svn:externals. Как лучше всего обрабатывать их с помощью git? Как разбить очень большой репозиторий на более мелкие компоненты с помощью git? Вот несколько примеров вопросов, которые нам чаще всего задавали на европейском этапе нашего недавнего тура Как использовать Git правильно.

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

До прихода в Atlassian я работал над различными проектами, где в качестве системы управления версиями все еще использовали Subversion (SVN). Я же к тому времени давно перешел на Git и хотел пользоваться этой системой везде, где только можно.