Расширенные рабочие процессы и использование Git

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

Git рабочие процессы

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

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

Затем появился git-flow, и я принял его в качестве своей стратегии. Я до сих пор помню ощущение, будто я заглядывал за какую-то занавеску туда, где были замечательные разработчики. Теперь я понял, как они работают, и мог стать одним из них.

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

git-поток

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

Давайте посмотрим, что такое git-flow.

Если вы хотите увидеть полное подробное объяснение с диаграммами и командами Git для Git Flow, вам следует прочитать этот пост.

В git-flow две ветки имеют бесконечное время жизни. Во-первых, main, который должен отражать код, готовый к развертыванию в вашей реальной/производственной среде.

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

Помимо двух основных ветвей, есть три типа вспомогательных ветвей.

1. Особенность

Функциональная ветка может быть создана только из ветки разработки. Он должен быть объединен обратно в ветку разработки. Имя может быть любым, описывающим функцию, над которой вы работаете.

Когда работа готова к следующему релизу, она снова объединяется с веткой разработки, где ожидает времени релиза.

2. Отпустите

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

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

3. Исправление

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

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

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

Стандартный git-flow не предназначен для этого.

Гитхаб Поток

Второй вариант, который используют многие, — это Github Flow.

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

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

Когда ваши изменения готовы, вы создаете запрос на извлечение.

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

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

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

Как я использую рабочие процессы Git с клиентскими проектами

В моей работе с клиентами я обычно единственный, кто ежедневно пишу код для проекта. Мой клиент может обновлять плагины WordPress или изменять некоторые CSS, но они не выполняют никакой серьезной работы по кодированию. Это означает, что если бы я пошел с потоком Github, я бы просматривал свои запросы на вытягивание, которые только создавали бы дополнительные головные боли для управления. Давайте посмотрим на систему, которую я использую, которая имеет некоторое сходство как с git-flow, так и с Github.

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

Каждая ветка создается из основной ветки. Новым функциям дается такое имя: feature/32-new-feature. В данном контексте число 32 соответствует номеру тикета в нашей системе управления проектами, а слова после него — это краткое описание того, над чем ведется работа. Исправления ошибок называются аналогичным образом, bug/20-bug-name.

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

# объединить фичу в промежуточную ветку

функция слияния git / 32-новая функция

# развернуть и протестировать функцию

git касса главная

функция слияния git / 32-новая функция

# развернуть функцию на работающем сайте

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

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

Расширенные команды Git, которые я использую

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

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

Добавление изменений по строке

Единственная команда, которая заставила меня использовать Git через щелчок терминала, была git add -p. Пока я не изучил эту команду, я использовал приложения с графическим интерфейсом, потому что я вносил изменения в свой код, но хотел разбить определенные строки на разные коммиты, чтобы я мог объяснить, почему я внес изменение. Для этого я использовал графический интерфейс для выбора строк, но git add -p проведет вас через интерактивный интерфейс, чтобы добавить изменения в куски.

Я использую это много раз каждый день.

Отслеживание удаленной ветки Git

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

Есть несколько способов сделать это.

# Устанавливаем апстрим при отправке на удаленку

git push -u постановка источника

# Установить апстрим

# предполагает, что вы находитесь в той ветке, которую хотите отслеживать удаленно

git ветка -u источник/постановка

ветка git --set-upstream-to=origin/staging

# Если вы находитесь не на той ветке, которую хотите отслеживать, укажите ветку в конце

git branch --set-upstream-to=origin/staging

Сохранить изменения, не фиксируя их

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

Получить конкретный коммит Git

Иногда вам нужно включить определенный коммит в вашу текущую работу. С чистым HEAD (вы еще не внесли никаких изменений) вы можете получить конкретную фиксацию с помощью git cherry-pick. Вы можете найти полную документацию по git cherry-pick здесь.

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

Выбросьте изменения, которые вам не нужны

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

git сброс --hard

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

Чтобы сделать еще один шаг вперед, мы можем удалить любые файлы или каталоги, которые еще не отслеживались в git, с помощью команды git clean.

git clean -fd: флаги f и d говорят git выбрасывать файлы и каталоги, которые не отслеживаются.

Удалить ветки

Каждую неделю или две я смотрю на результаты команды git status и обнаруживаю, что у меня слишком много веток, чтобы разумно понять, что происходит в моем репозитории. Это означает, что я могу удалить любые ветки, соответствующие заявкам, которые были разрешены с помощью следующих команд.

# удаляет локальную версию

git ветка -d $ имя ветки

#удаляет ветку на моем пульте

git push $remotename --удалить $branchname

Используйте контроль версий

Хотя вы можете не быть экспертом во всех командах Git, которые вы будете использовать, важно помнить одну важную вещь: вы должны использовать контроль версий . Даже если вы единственный человек, работающий над проектом, использование Git и рабочего процесса Git поможет вам организовать свои проекты. Вам не нужно будет нажимать CTRL + Z, пока вы не сбросите свою работу после написания кода, который не работал.

Вы сможете доверять своей системе и продолжать работать над своими проектами.

Попробуйте полностью управляемый хостинг WordPress

Нужен хостинг, оптимизированный для WordPress? Ознакомьтесь с полностью управляемыми планами хостинга WordPress от Nexcess уже сегодня.