Эта публикация от Мэтта Шелтона из Nuance Healthcare — первая статья из серии, где он описывает, как его команда переходила из Subversion в Git, почему было принято такое решение и с чем пришлось столкнуться в процессе перехода. Мэтт уже выступал на эту тему на конференции Atlassian Summit 2015. В этой серии статей он подробно расскажет обо всех темах, которые не успел затронуть в получасовом докладе.
Работа с зависимостями Maven при переходе на Git
Итак, мы переходим на Git и довольны моделью Git-flow. Что дальше? Время тестировать! Моя замечательная команда разработчиков составила список «подопытных» в Confluence: в него вошли рабочие процессы, которые используются сегодня, и те, которые могут понадобиться для реализации всяких странных идей в будущем. После этого мы создали идентичную структуру проекта (но без кода, просто файл pom.xml) и опробовали в ней каждый рабочий процесс.
Git: автоматическое слияние с помощью серверных хуков (вы останетесь довольны!)
Корпоративные рабочие процессы с распределенными системами управления входят в привычку, а методы работы становятся все более четкими. Git дает командам безграничную гибкость, поэтому даже в пределах одной компании разные команды могут использовать уникальные подходы к обмену кодом и совместной работе.
Форки и вышестоящие репозитории в Git: инструкции и интересный совет
Есть целый вагон и маленькая тележка полезных руководств о том, как обновлять форки
по вышестоящим
репозиториям (а если вас интересует, зачем в корпоративной среде могут понадобиться форки, вот несколько причин). В этой публикации я расскажу кое-что о том, как форки взаимодействуют с вышестоящими ветками
. Вас ждут основы, рассказ о подводных камнях, интересный совет, а в заключение — сильная зависть или сильный энтузиазм; выбор за вами. Стало интересно? Читайте далее.
Что нового в Git 2.1
Всего два с половиной месяца назад вышла версия git 2.0.0, а теперь нас порадовали промежуточной версией git 2.1.0 с массой захватывающих новых функций!
Основные идеи, рабочие процессы и советы
Использование подмодулей при разработке в Git позволяет включать в базу кода другие проекты: их история хранится в отдельном месте, но синхронизируется с вашей. Это удобный способ решения проблем с зависимостями и библиотеками от поставщиков. Как и в случае со многими другими вопросами, касающимися git
, насчет этого подхода есть разные мнения. Чтобы умело им пользоваться, нужно немного его изучить. О подмодулях и так уже полным-полно хорошей, подробной
информации, поэтому пересказывать ее я не буду. Вместо этого я поделюсь кое-какими интересными приемами, позволяющими использовать эту функцию максимально эффективно.
Рабочие процессы команды в Git: слияние или перебазирование?
Вопрос несложный: если команда по разработке ПО использует git
и функциональные ветки, как лучше всего включать готовую работу обратно в основную линию разработки? Это одна из тех постоянно возникающих дискуссий, где обе стороны имеют твердое мнение, и вести осмысленный разговор бывает непросто (другие примеры горячих споров легко найти в Интернете).
Мастерство запросов pull: навык получения открыт!
Сегодня для внесения исправлений в проект достаточно создать форк (чтобы в свое удовольствие возиться с полной удаленной копией проекта), выбрать нужный файл, нажать Edit (Правка) и сделать коммит с изменениями.
Git и зависимости проекта
Задумайтесь над следующими вопросами. Как вы обрабатываете зависимости проекта с помощью git
? Наш проект состоит из нескольких взаимозависимых репозиториев. Сейчас мы управляем ими с помощью svn:externals
. Как лучше всего обрабатывать их с помощью git
? Как разбить очень большой репозиторий на более мелкие компоненты с помощью git? Вот несколько примеров вопросов, которые нам чаще всего задавали на европейском этапе нашего недавнего тура Как использовать Git правильно.
Простой рабочий процесс в Git — это просто
Многие команды уже перешли на git
, многие переходят прямо сейчас. Помимо обучения отдельных разработчиков и назначения ответственных исполнителей для помощи во внедрении, крайне важно выбрать удобный, понятный и притом не слишком сложный метод совместной работы над кодом. Последнее особенно важно, потому что с помощью git
можно соорудить и очень сложные рабочие процессы — я видел такие своими глазами.
Как использовать Git, даже если ваша команда этого не делает: советы и рекомендации по git-svn
До прихода в Atlassian я работал над различными проектами, где в качестве системы управления версиями все еще использовали Subversion (SVN). Я же к тому времени давно перешел на Git и хотел пользоваться этой системой везде, где только можно.