10 техник Git, которые вы должны знать, прежде чем присоединиться к команде — SitePoint

        

Вы использовали Git в течение некоторого времени, но никогда в командной среде? Вы знакомы с основами Git, но не знаете, как большие команды используют Git на работе?

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

1. Клонирование: начало работы в команде

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

Чтобы клонировать репозиторий, введите команду git clone после чего укажите путь к репозиторию:

  git clone / path / to / repo
 

Если ваш источник не находится в той же системе, вы можете подключиться по SSH к удаленной системе и клонировать тоже:

  имя пользователя git clone @ remote_system_ip: / путь / к / repo / on / remote
 

Если вы клонируете из источника в Интернете, вы можете просто добавить URL:

  git clone https://github.com/sdaityari/my_git_project.git
 

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

2. Управление Remotes в Git

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

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

  git remove -v
 

Чтобы добавить пульт, вы можете использовать команду git remote add :

  git remote добавить имя_удаления remote_address
 

Вы можете удалить пульт с помощью команды git remote remove :

  git remote remove remote_name
 

Если вы хотите изменить адрес пульта, вы можете использовать команду set-url :

  git remote set-url имя_удаления new_remote_address
 

3. Ветвление в Git

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

Если вы работали над собственным проектом, возможно, вы никогда не использовали сознательно ветки. По умолчанию Git использует ветку master для разработки. Любые новые коммиты добавляются в эту ветку.

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

Чтобы проверить список ветвей и текущую активную ветвь, выполните следующую команду:

  git branch
 

Чтобы создать новую ветку, выполните следующую команду:

  git branch new_branch
 

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

  git checkout new_branch
 

Чтобы создать новую ветку и изменить активную ветку, выполните следующую команду:

  git checkout -b new_branch
 

Чтобы переименовать текущую ветку, введите следующую команду:

  git branch -m new_renamed_branch
 

Используйте опцию -D чтобы удалить ветку:

  git branch -D new_renamed_branch
 

Вот подробное руководство по ветвлению в Git.

4. Обновите ваш локальный репозиторий: слияние

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

  git checkout base_branch
git merge new_branch
 

Хотя это может показаться простым процессом, слияние — потенциально самый трудоемкий процесс в Git, поскольку он может привести к конфликтам.

5. Обработка конфликтов

Представьте, что вы работаете с файлом в новой ветке. После того, как вы внесете изменения, вы просите Git объединить вашу новую ветку с вашей базовой веткой. Однако та же часть того же файла в базовой ветви была обновлена ​​с момента создания новой ветви. Как Git решает, какие изменения оставить, а какие отказаться?

Git всегда пытается не потерять какие-либо данные в процессе слияния. Если изменения в одном и том же файле были сделаны в разных частях файла, вы могли бы избежать, сохранив оба набора изменений. Однако, если Git не может решить, какие изменения сохранить, возникает конфликт.

Когда возник конфликт, при запуске git status в вашем хранилище отображается список файлов, которые были изменены в обеих объединяемых ветвях. Если вы откроете какой-либо файл с конфликтом, вы заметите следующий набор строк:

  <<<<<<< < HEAD
...
...
========
...
...
> >>>>>>> new_branch
 

Часть файла между <<<<<<<< HEAD и ======== содержит этот код, который присутствует в базовой ветви. Строки кода между ======== и >>>>>>>> new_branch присутствуют в ветви new_branch . Разработчик, который объединяет код, обязан решить, какую часть кода (или сочетание обеих частей) следует включить в слияние. После редактирования удалите три показанных набора строк, сохраните файл и зафиксируйте изменения.

6. Синхронизировать изменения с пультом

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

  git pull remote remote_branch: local_branch
 

Команда git pull сначала загружает данные с удаленного компьютера, а затем объединяется с локальной веткой, как указано в команде. Конфликты могут возникать и при извлечении изменений с пульта. В таком случае последняя строка в файле конфликта будет содержать >>>>>>>> commit_hash вместо >>>>>>>> new_branch где commit_hash будет идентифицирующим хешем для коммита, добавляемого в вашу ветку.

Чтобы опубликовать изменения на пульте после слияния с последним кодом с пульта, используйте команду git push :

  git push remote local_branch: remote_branch
 

7. Git on the Cloud: Форкинг

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

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

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

8. Обзоры кода через Pull Requests

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

9. Знать о рабочих процессах Git

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

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

Рабочий процесс Git, охватывающий широкий спектр ситуаций, — это рабочий процесс Gitflow. Он имеет отдельные ветки для разработки, функций, релизов и исправлений.

Вот подробное руководство по рабочим процессам Git.

10. Обработка больших файлов: Git LFS

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

Решение состоит в том, чтобы использовать Git Large File Storage, который обрабатывает большие двоичные файлы через Git. Этот инструмент хранит эти файлы в облаке и заменяет их текстовыми указателями. Вот реализация использования Git LFS для отслеживания файлов дизайна Photoshop.

Дальнейшее чтение

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

Для более глубокого понимания Git, ознакомьтесь со следующими ресурсами:

• Jump Start Git: краткое руководство, которое поможет вам разогнаться за выходные.
• Профессиональный Git: более глубокое погружение, которое приведет вас на путь к мастерству Git.