Продолжаю открывать для себя возможности системы Git и сервиса GitHub.
Уже сейчас, обладая минимальными базовыми знаниями Git и владея учетной записью на сервере GitHub, я не представляю, как я мог жить раньше без обоих этих вещей. Это действительно удобно и надежно!
Благодаря им я знаю, что у меня никогда и ничто не потеряется; и все, что нужно - у меня всегда под рукой. На работе поработал над чем-либо - отправил на GitHub; домой пришел - “стянул” наработки с GitHub и продолжил работу с прерванного места.
Вот на последнем я хотел бы остановиться подробнее. Конечно, веб-разработчик, давно и хорошо знакомый с Git и GitHub, может только улыбнуться насчет того, чем я собираюсь поделиться. Настолько все это просто и понятно. Но это просто и понятно для него, опытного web-разработчика. А для начинающего веб-программиста - это новое и неизведанное. Впрочем, достаточно лирики - переходим к практике.
GitHub - команда push
В предыдущей статье я познакомился с возможностью создания репозитория на сервисе GitHub. И возможностью клонирования этого репозитория на локальную машину - “GitHub и Git - создание и работа с репозиторием”.
Напомню, что в том примере было произведено клонирование репозитория с помощью команды:
Другими словами, было произведено копирование существующего репозитория с удаленного сервера на локальную машину. Причем, копирование как есть - полностью весь репозиторий, со всеми его файлами, коммитами, индексами и тому подобным.
После внесений изменений в локальный репозиторий - индексации и фиксации - необходимо было отправить произведенные изменения на удаленный сервер, на GitHub.
Для этой цели существует (и я ею воспользовался) команда
(отправить). К примеру, давайте я внесу еще кое-какие изменения в локальном репозитории, затем проиндексирую и зафиксирую их, а затем отправлю на GitHub:1
push
Вот - все наработки, которые я сделал на домашнем компьютере, оказались с считанные секунды помещенными на сервере GitHub, под бдительным оком Git.
GitHub - команда pull
Продолжим логическую картину моего рабочего процесса (workflow). На следующий день я прихожу на работу и у меня есть время и возможность поработать над своим проектом. Естественно, я хочу продолжить с того места, на котором остановился дома. Для этого я воспользуюсь командой
, чтобы “стянуть” с GitHub последние изменения.1
pull
В данном случае команда
будет выглядеть так:1
pull
В выводе консоли (на картинке) видно, что было произведено добавление одного измененного файла по имени README.md, в котором были добавлены две строки.
Обратите внимание на разницу между командами
и 1
clone
в данном случае. Команда 1
pull
копирует весь репозиторий целиком, как есть - со всеми его файлами. Команда 1
clone
копирует разницу между удаленным и локальным репозиторием. Эту разницу можно назвать дельта или patch.1
pull
В результате вышеприведенной команды в считанные секунды я получаю на рабочем компьютере точную копию того проекта, над которым работал дома. И могу продолжать с того места, на котором остановился.
GitHub - команда fetch
Существует разновидность команды
- это команда 1
pull
. И одна, и вторая команда выполняют одинаковые задачи - получение patch удаленного репозитория. Но делают они это по разному.1
fetch
Команда
получает patch репозитория и автоматически производит слияние удаленной и локальной ветвей репозитория. Если произойдет конфликт слияния, то только в этом случае слияния не произойдет и решать конфликт придется вручную.1
pull
Команда
также производит получение patch удаленного репозитория. Но при этом автоматического слияния ветвей удаленного и локального репозиториев не происходит:1
fetch
На картинке выше показано, что была выполнена команда
после того, как на стороне сервиса GitHub было произведено редактирование файла README.md. Однако, последующая команда 1
git fetch
показала, что изменения есть, но они не слиты с локальной ветвью репозитория. И порекомендовала выполнить команду 1
git status
, чтобы произвести такое слияние.1
git pull
Помимо этого, имеются изменения в локальном репозитории, которые не проиндексированы и не зафиксированы. Что же, исправляю ситуацию - последовательно ввожу команды:
Производить слияние и разрешение конфликтов при слиянии я еще не умею, поэтому вопрос, как произвести слияние ветвей после команды
я опущу в данной статье.1
git fetch
Вернувшись к вышесказанному, можно сделать вывод, что команда
более универсальная, нежели команда 1
pull
. Именно команду 1
fetch
имеет смысл применять в практической работе.1
pull