Доктор Баннер (Халк), разговаривающий с Древним об альтернативных сроках в отношении Камня Бесконечности в «Мстителях: Конец игры», является прекрасным примером ветвления в Git. Но вместо исходного кода они говорили о путешествиях во времени и альтернативных реалиях. Ветвление — очень полезная тема в управлении версиями программного обеспечения, и я полагаю, что большинство людей знают об этой идее, даже если они не имеют опыта разработки программного обеспечения.
Ветвление в Git очень мощное, но в то же время может быть огромным. Разветвление Git охватывает множество рабочих процессов и сценариев. В этой статье я постараюсь познакомить вас с очень простой настройкой, которую вы сможете использовать, чтобы начать работу с ветвлениями, а также намного позже.
Ветви Git по сути являются указателем на снимок ваших изменений.
Вам также может понравиться:
Лучшие 20 команд Git с примерами .
Локальный и удаленный филиал
В этом посте я сосредоточусь на локальных ветвях (ветвях, которые находятся на вашей машине разработки), но концепции одинаковы для удаленных ветвей. Обычно, когда вы начинаете разработку задачи, исправления ошибки или новой функции, вы можете создать новую ветвь для этого действия, выполнить всю вашу работу в этой ветке, зафиксировать изменения в этой ветке и, после этого, объединить эти изменения обратно в мастер ветви. Итак, давайте посмотрим, как мы можем начать с этой базовой настройкой ветвления.
Шаг 1. Создайте новую локальную ветвь
Команда git branch -v, — это один из способов перечисления всех веток для вашего хранилища. В нашем случае у нас только одна основная ветка. Допустим, мы хотим начать работу над новой функцией в программном обеспечении, которую мы назовем «feature1». Мы можем создать новую ветку для этой функции, как показано ниже:
Оболочка
1
git checkout -b feature1
Эта команда создает новую ветвь с именем «feature1» и делает эту ветвь нашей активной ветвью .
Шаг 2: Изменения кода, коммиты и т. Д.
Теперь мы разрабатываем нашу функцию, вносим изменения в код, делаем коммиты и т. Д., И все, что происходит в этой ветви функций. Я моделирую эту работу, добавляя текстовый файл с именем «feature1», но это может быть целая куча файлов (HTML, CSS, JavaScript и т. Д.).
Шаг 3: Вернуться в мастер ветку
Когда вы закончите с изменениями для «feature1», вы можете переключиться обратно в главную ветку с помощью следующей команды:
Оболочка
xxxxxxxxxx
1
git checkout master
Необязательно, это также хорошо, если мы выполняем, git pull origin masterчтобы получить какие-либо изменения из удаленного хранилища.
Шаг 4: объединить ветвь объекта с мастером
Теперь наши изменения на «feature1», и мы переключились на master . Мы можем использовать git merge feature1, и это объединит изменения из ветви «feature1» в master .
Шаг 5: Удалить ветвь компонента
Как только мы успешно слили изменения в master, мы можем удалить нашу локальную ветку, и все. Целью этой ветки было сделать изменения кода изолированно. После того, как эти изменения были ящики, можно удалить с помощью ветви с помощью следующей команды: git branch -d feature1.
Шаг 6: Нажмите Изменения в Master (Remote)
Этот шаг также необязателен. Если нам нравится, в этот момент мы можем перенести изменения в master (remote), чтобы другие коллеги также могли вытащить эти изменения.
Резюме
git checkout -b feature1(создайте новую ветку, названную «feature1»).git checkout master(переключиться обратно в главную ветку).git pull origin master(вытащить изменения из мастера, необязательно).git merge feature1(объединенная ветка «feature1» обратно в ветку master ).git branch -d feature1(удалить локальную ветвь после слияния, необязательно).git push origin master(нажмите изменения на удаленный мастер , необязательно).
Вышеупомянутые шаги — все, что вам нужно, чтобы начать с ветвления Git. Я предлагаю вам адаптироваться к этой стратегии для каждого изменения кода, исправления ошибок или новой функции. Создайте отдельную ветку для этого локально. Это упростит вам многое.
Когда вы почувствуете себя комфортно, вы можете изучить другие сложные темы, связанные с ветвлением Git Есть хорошая статья Винсента Дриссена, которая позволяет вам лучше контролировать и охватывать некоторые предварительные варианты использования. Я предложу такой подход, если вы имеете дело со сложными рабочими процессами. Вы можете получить доступ к статье на https://nvie.com/posts/a-successful-git-branching-model/ .
Если вам нужна дополнительная информация или если что-то неясно, не стесняйтесь спрашивать, и я постараюсь ответить. До следующего раза, счастливого кодирования!