Евгений Гундоров
front-end
Я программирую уже не один год и каждый день имею дело с git. Я писал код один и в команде, для себя и по работе. На основе своего опыта хочу поделиться с вами крайним минимумом, который вам стоит знать и уверенно использовать, чтобы говорить "я умею работать с git".
Для начала определимся. Во-первых, если вы считаете, что git вам не нужен, то вы крупно ошибаетесь. Если вы планируете писать код не один день, даже если вы будете делать это в одиночку, то вам точно нужен git. Во-вторых, не стоит рассматривать эту статью как руководство. Я не буду расписывать подробности каждого ключа и т.п. Все подробности по той или иной команде вы легко сможете найти в поисковике, в том числе на русском. В-третьих, не важно, планируете вы использовать git череж консоль или через интерфейс, принцип остается одинаковым. Приступим.
Репозиторий на вашем диске обычно появляется двумя путями. Либо вы его инициализируете сами командой git init, либо же вы
его клонируете из удаленного репозитория (например из Github) командой git clone <your remote repo url>.
Ваша ежедневная рутина при работе с git - это команды status, add, commit, pull и push. Для начала опеределимся с первыми тремя.
Одно из ключевых понятий git - это коммит. Еще иногда люди, которые все хотят перевести на русский, называют их фиксациями, но
я не люблю эту терминологию. Коммит - это как шаг. Вы всегда можете откатиться на один или несколько коммитов назад и
все будет так, как в тот момент, когда вы его создали. В этои прелесть git. Но прежде чем чем создать коммит нужно обозначить
изменения из каких файлов вы хотите зафиксировать. Вот тут то нам и понадобится комманды status и add. Команда status выведет вам
список файлов, в которых в текущий момент присутствуют изменения. Определите изменения в каких файлах вы хотите зафиксировать и просто
вводите названия файлов через пробел (если вы не хотите фиксировать все файлы), либо же просто используете ., чтобы добавить все файлы,
в которых сейчас есть изменения.
# Хотим зафиксировать изменения в file1.txt и file2.json
git add file1.txt file2.json
# Или добавляем все разом
git add .
Остался последний шаг. При помощи комманды git commit -m 'Мой первый коммит' вы создаете коммит. К каждому коммиту прикрепляется
сообщение, которое поясняет что за изменения были произведены. В принципе, оно заполняется в свободной форме, но обычно у команд есть
свои правила по их оформлению.
Рано или поздно, вы захотите опубликовать свой код в репозитории (своей команды или в открытом виде на github), тогда-то вам и понадобятся
команды pull и push. Правда, стоит сказать, что прежде чем публиковать свой код стоит определиться куда он будет отправляться. Если вы
клонировали свой репозиторий, то у вас уже есть ссылка на удаленный репозиторий из которого вы получили код. Он обозначется как origin.
Если же вы создали репозиторий сами, то вам стоит добавить эту ссылку вручную при помощи команды git remote add origin <my repo url>.
В конце концов, вам станут доступны команды pull и push. Первая git pull получает из текущей ветки все коммиты, а вторая git push
оправляет в удаленную ветку ваши коммиты.
Ветки - это еще одна классная штука git. Предствьте, что вы шли с другом одним путем, след в след, к светлому комунизму, но в какой-то момент
он решил, что у него будет чучхе. Вот это и есть ветка. В самом начале, после иницилизации репозитория создаете главная ветка master.
Но вы всегда можете пойти другим путем. Для этого вам нужно выполнить git branch chuchkhe. Новая ветка будет иметь все те же коммиты, которые
были в master (или в другой ветке, от который вы взяли ветку), но все последующие коммиты из ветки master сюда не попадут. Переключиться
из одной ветки в другую можно при помощи команды git checkout <branch-name>. Но обратите внимание! Все незафиксирпованые изменения из
текущей ветки будут применены к новой. В случае же, если ваши изменения будут конфликтовать с другой веткой, то переход будет отменен и вам
предложат решить что делать с текущими изменениями. В данном случае у вас есть два пути: отменить свои изменения или зафиксировать их.
Сбросить свои изменения вы можете командой git checkout -- file1.txt file2.json или же использовать ., тут работает та же логика, как и при add.
Конфликты - вещь очень частая. Они возникают когда изменения в одной ветке не совпадают с изменениями в другой. Причем ваша ветка на вашем
компьютере и на удаленном сервере - это тоже разные ветки и они могут конфликтовать. Некоторые из них могут быть разрешены автоматически,
некоторые же придется решить в ручную. Обычно они возникают когда вы с коллегой сделали очень похожие изменения, а затем вы решили загрузить
изменения из удаленного репозитория себе на диск командой git pull. Выглядят конфликты примерно так.
<<<<<<< HEAD
<a href="/my-pics">Мои картинки</a>
=======
<a href="/my_pics">Мои картинки</a>
>>>>>>> master
Что вам нужно сделать? Просто выбрать тот вариант, который вы считаете правильным и удалить все лишнее. Когда вы разрешите все конфликты, то
добавьте те файлы, где были конфликты и сделайте коммит, но в этот раз используйте комануду git commit без агрументов. В таком случае git
автоматически создаст сообщение, в тотором будет сказано, что этот коммит содержит решение конфликтов и укажет файлы, в которых эти конфликты были.
Такая ситуация, когда изменения конфликтуют, может возникнуть еще в одном случае. Если вы захотите встроить изменения из другой ветки в свою,
то вам нужно будет произмести merge. Чтобы его выполнить укажите ветку, из которой вы хотите получить изменения командой git merge <название другой ветки>.
После этого git проверит, нет ли конфликтов между вашей и указаной веткой. Если нет, то автоматически создасться merge commit, в противном же
случае вы получите сообщение, что есть конфликты. Файлы, в которых есть конфликты вы можете посмотреть при помощи команды git status.
Конечно, это далеко не полный список того, что вы можете сделать при помощи git, но владея этим минимумом вы можете уже начать полноценно работать со своим кодом.