Отправка изменений на сервер

Сейчас самое время переслать наш локальный коммит на сервер. Этот процесс происходит каждый раз, когда мы хотим обновить данные в удаленном репозитории.
Команда, предназначенная для этого — push. Она принимает два параметра: имя удаленного репозитория (мы назвали наш origin) и ветку, в которую необходимо внести изменения (master — это ветка по умолчанию для всех репозиториев).

1 2 3 4 5 6

$git push origin master Counting objects: 3,done. Writing objects: 100% (3/3),212bytes | 0bytes/s,done. Total3(delta0),reused0(delta0) Tohttps://github.com/tutorialzine/awesome-project.git * [newbranch]master ->master

В зависимости от сервиса, который вы используете, вам может потребоваться аутентифицироваться, чтобы изменения отправились. Если все сделано правильно, то когда вы посмотрите в удаленный репозиторий при помощи браузера, вы увидете файл hello.txt

Клонирование репозитория

Сейчас другие пользователи GitHub могут просматривать ваш репозиторий. Они могут скачать из него данные и получить полностью работоспособную копию вашего проекта при помощи команды clone.

1	$git clonehttps://github.com/tutorialzine/awesome-project.git

Новый локальный репозиторий создается автоматически с GitHub в качестве удаленного репозитория.

Запрос изменений с сервера

Если вы сделали изменения в вашем репозитории, другие пользователи могут скачать изменения при помощи команды pull.

1 2 3 4

$git pull origin master From https://github.com/tutorialzine/awesome-project * branch master ->FETCH_HEAD Already up-to-date.

Так как новых коммитов с тех пор, как мы склонировали себе проект, не было, никаких изменений доступных для скачивания нет.

Ветвление

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

• Уже рабочая, стабильная версия кода сохраняется.

• Различные новые функции могут разрабатываться параллельно разными программистами.

• Разработчики могут работать с собственными ветками без риска, что кодовая база поменяется из-за чужих изменений.

• В случае сомнений, различные реализации одной и той же идеи могут быть разработаны в разных ветках и затем сравниваться.

• Структура хорошего git репозитория выглядит следующим образом:

• Ветка master – содержит в себе стабильно-работающие релизы

• Ветка dev – основная рабочая ветка проекта. Основное требования к коммитам в этой ветке – код в ней должен всегда компилироваться

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

•

• Стандартный алгоритм работы над какой-либо задачей выглядит так:

•

• 1. Создаётся ветка, основывающаяся на последней копии master или dev ветки. Название новой ветки содержит краткое описание задачи

• 2. Все изменения производятся внутри этой ветки. При каждом атомарном логическом изменении (например, добавили плагин – закоммитили добавление; поправили API одной функции во всех местах – закоммитили и тп) создаётся свой коммит. Это позволяет разделять какие были изменения, упрощается чтение и проверка на ошибки процесса разработки.

• 3. После того как код в ветке сделан и отлажен, все изменения закоммичены, данная ветка сливается с веткой dev

6. Разработчик удаляет локальную ветку задачи после того как задача была закрыта и изменения попали в master или dev.

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

Основная ветка в каждом репозитории называется master. Чтобы создать еще одну ветку, используем команду branch <name>

1	$git branch amazing_new_feature

Это создаст новую ветку, пока что точную копию ветки master.

Переключение между ветками

Сейчас, если мы запустим branch, мы увидим две доступные опции:

1 2 3

$git branch amazing_new_feature * master

master — это активная ветка, она помечена звездочкой. Но мы хотим работать с нашей “новой потрясающей фичей”, так что нам понадобится переключиться на другую ветку. Для этого воспользуемся командой checkout, она принимает один параметр — имя ветки, на которую необходимо переключиться.

1	$git checkout amazing_new_feature

Слияние веток

Наша “потрясающая новая фича” будет еще одним текстовым файлом под названием feature.txt. Мы создадим его, добавим и закоммитим:

1 2	$git add feature.txt $git commit -m"Newfeature complete.”

Изменения завершены, теперь мы можем переключиться обратно на ветку master.

1	$git checkout master

Теперь, если мы откроем наш проект в файловом менеджере, мы не увидим файла feature.txt, потому что мы переключились обратно на ветку master, в которой такого файла не существует. Чтобы он появился, нужно воспользоваться merge для объединения веток (применения изменений из ветки amazing_new_feature к основной версии проекта).

1	$git merge amazing_new_feature

Теперь ветка master актуальна. Ветка amazing_new_feature больше не нужна, и ее можно удалить.

1	$git branch -dawesome_new_feature

Дополнительно

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