Сохранение и совместное использование кода с помощью Git

Сохранение и совместное использование версий кода с командой — это наиболее распространенные действия при использовании управления версиями. Git имеет простой трехэтапный рабочий процесс для следующих задач:

1. Создайте новую ветвь для работы
2. Фиксация изменений
3. Отправьте ветвь, чтобы поделиться ею с командой

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

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

Создание ветви

Создайте ветвь на основе кода в текущей ветви, например mainпри запуске новой работы. Рекомендуется проверить, какая ветка выбрана с помощью git status перед созданием новой ветки.

Создайте ветви в Git с помощью git branch команды:

> git branch <branchname>

Команда для смены веток в репозитории git checkout. После создания ветви переключитесь на нее перед сохранением изменений.

> git checkout <branchname>

У Git есть сокращенная команда для создания ветви и переключения на нее одновременно:

> git checkout -b <branchname>

Узнайте больше о работе с филиалами Git в GitHub или Azure DevOps.

Сохранить изменения

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

Изменения стадии

Git отслеживает изменения файлов, внесенные в репозиторий по мере их появления. Он разделяет эти изменения на три категории:

• Неизмененные файлы не были изменены с момента последней фиксации.
• Измененные файлы содержат изменения с момента последней фиксации изменений, но не были подготовлены для следующей фиксации.
• Промежуточные файлы имеют изменения, которые будут добавлены в следующую фиксацию.

При создании коммита для снапшота используются только подготовленные изменения и неизмененные файлы. Неуправляемые изменения хранятся в файловой системе, но фиксация использует немодифицированный файл в его моментальном снимке.

Зафиксировать изменения

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

Этап изменений с git add добавлением измененных файлов, git rm удалением файлов и git mv перемещением файлов. Затем используйте git commit команду для создания коммита.

Как правило, разработчики хотят выполнить этап всех измененных файлов в репозитории:

> git add –all

Затем зафиксируйте изменения с кратким описанием:

> git commit -m "Short description of changes."

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

Узнайте больше о подготовке файлов и фиксации коммитов в Visual Studio или Visual Studio Code.

Предоставление общего доступа к изменениям

Независимо от того, работают разработчики в команде или просто хотят создать резервную копию своего кода, им необходимо делиться коммитами с репозиторием на другом компьютере. git push Используйте команду, чтобы принимать фиксации из локального репозитория и записывать их в удаленный репозиторий. Git настраивается в клонированных репозиториях для подключения к источнику клонирования, который также называется origin. Запустите git push, чтобы перенести локальные фиксации из вашей текущей ветви в другую ветку (branchname) в этом репозитории origin. Git создает ветку с именем на удаленном репозитории, если она не существует.

> git push origin

Если вы работаете в репозитории, созданном в локальной системе git init, необходимо настроить подключение к серверу Git команды, прежде чем можно будет отправить изменения. Дополнительные сведения о настройке удаленных и отправке изменений в Visual Studio или Visual Studio Code.

Обмен ветками

Отправка локальной ветви в общий репозиторий команды делает изменения доступными для остальной части команды. При первом git push запуске, добавление параметра -u указывает Git начать отслеживание локальной ветви по имя ветви из репозитория origin. После однократной настройки сведений об отслеживании участники команды могут использовать git push чтобы быстро и легко обновлять информацию.

> git push origin <branchname>

Дальнейшие шаги

Дополнительные сведения о ветвях в GitHub или Azure DevOps.

Дополнительные сведения о отправке фиксаций и ветвей в Visual Studio или Visual Studio Code.