Объяснение основ Git для начинающих

Как новичок, каждый борется с основами git и хочет, чтобы кто-то легко объяснил git. Я расскажу и объясню основы git и команды git в коротком рассказе. Вы увидите, что в конце концов сможете использовать git как профессионал. Давайте начнем!

Git борется

Как будто это было вчера, я до сих пор помню, когда мне пришлось коммитить свой первый код для назначенной групповой работы в университете. Боялся, что сделаю что-то не так и случайно удалю код. Когда я наконец зафиксировал свой код, никто не увидел мой код. Почему? Что я сделал не так? Ну, я не знал, что мне нужно протолкнуть свои коммиты. Git сбивает с толку со всеми этими терминами: клонирование, фиксация, слияние, отправка, сохранение и т. д.

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

Объяснение команд Git

Позвольте представить Аду, Бена, Кору и Диди. Четыре разработчика программного обеспечения с разным опытом работы и концентрацией внимания.

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

Фрагменты определяются как

• A (Прикладной уровень, также известный как Front End)
• B (Бизнес-логика, также известная как Back End)
• C (Контроллер, также известный как клей для взаимодействия между прикладным уровнем и бизнес-логикой)
• D (база данных, также известная как SQL-запросы, уровень сохраняемости)

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

Подождите, это было слишком быстро! Некоторые пояснения:

Удаленный репозиторий:

Код, который сохраняется на сервере компании для предотвращения удаления и используется в качестве резервной копии, называется репозиторием или репозиторием (сокращенно). Репозиторий — это место, где вы найдете текущий код. Почему тогда он называется удаленным репозиторием? Чтобы указать, что этот репозиторий является не локальным репозиторием на вашем компьютере, а удаленным на сервере (например, GitHub, GitLab).

Первоначальная фиксация:

Я более подробно объясню, что такое фиксация, в этой записи блога. Вы должны знать, что первоначальная фиксация — это «новый старт» проекта. Обычно это делается только один раз, и обычно это делает первый, кто начинает.

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

Git-клон

Ада, Бен и Кора должны получить копию исходного коммита от Диди. Для этого они набирают следующее:

git clone “https://github.com/path/to/remote/repository”

Совет. Вы можете использовать Bash Shell (Linux), Terminal (macOS) или просто Git для Windows (https://gitforwindows.org/). Кроме того, мы предполагаем, что вы выполняете все команды git в каталоге, в котором хотите работать над своим кодом, например, /home/programming/project/hello_world

С помощью этой команды git clone каждый получает полную копию кода локально. У всех одна и та же версия на жестком диске.

Осталось только позволить им начать работу над своим кодом.

Через некоторое время Ада первая заканчивает свой код, поэтому она решает зафиксировать все свои изменения. Как это работает?

Git Trio: Git Add, Git Commit, Git Push

Во-первых, Ада использует git add для выбора всех файлов, которые она хочет добавить в удаленный репозиторий. Все это происходит в так называемой «постановочной зоне», области, где вы все еще можете изменить все локально. Представьте промежуточную область как временное состояние для вашего коммита.

git add “C:\path\to\your\file\ApplicationForms.java”

Затем Ада должна закоммитить эти добавленные файлы в git. Для этого она пишет сообщение фиксации, передавая аргумент -m для «сообщения»:

git commit -m “add application code”

Совет: рекомендуется использовать настоящее время, например, добавить, обновить, очистить, реорганизовать в сообщениях о фиксации.

С сообщением фиксации (-m) Ада сообщает своим коллегам в очень коротком сообщении, что она сделала. После фиксации git изменения остаются только локально на вашем компьютере, но уже сохраняются git и его историей. С помощью git show или git log теперь вы можете увидеть свою фиксацию в истории git.

Совет. Нажмите Q для выхода, чтобы выйти из git show или git log view, и используйте J или K для прокрутки вверх или вниз.

Ада хочет, чтобы ее коллеги видели ее изменения в удаленном репозитории. Для этого нужна последняя короткая команда git:

git push

Теперь git отправляет последние коммиты (да, вы можете локально коммитить несколько раз), которые вы сделали, в удаленный репозиторий. Поздравляем, Ада закончила свою работу. Но как насчет Бена?

А как же Бен и Кора?

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

git pull

С помощью git pull Бен теперь получает все изменения Ады раньше него на свой локальный компьютер. Используя git pull, вы всегда будете в курсе последних коммитов вашей команды.

Теперь все, что Бену нужно сделать, это то же самое, что сделала Ада — вы уже знаете волшебное трио git: git add, git commit и git push:

git add “C:\path\to\your\file\BusinessLogic.java”
git commit -m “add business logic”
git push

Пока все хорошо — это просто, что может пойти не так? Ты помнишь Кору? Она может быть молодой, но очень опытной и быстрой разработчиком с короткой концентрацией внимания. Слушать руководителей проектов? Не ее вещь.

Кора выполнила несколько дополнительных заданий, написала код для C и D и отправила свои изменения в удаленный репозиторий — проект завершен! Что может пойти не так?

Didi не очень опытен в написании слоя сохраняемости для приложения, поэтому ему нужно дополнительное время, чтобы написать все модели базы данных, SQL-запросы, сопоставление и логику сохранения.

Закончив, он делает то же, что и все до него:

git add “C:\path\to\your\file\Mapping.java”
git add “C:\path\to\your\file\init_database.sql”
git add “C:\path\to\your\file\PersistenceLogic.java”
git commit -m “add sqls, mapping and persistence logic”
git push

БУМ!

Диди получает git-конфликт. Git не позволяет ему протолкнуть свои изменения. Но почему? Он был единственным, кто работал над уровнем базы данных. Этого не должно происходить.

Didi проверяет конфликтующие файлы и понимает, что произошло. Кто-то сделал за него его работу.

Теперь его конфликтующий локальный репозиторий выглядит так:

Git теперь имеет две версии D и не может решить, какая из них правильная (на картинке D желтый и фиолетовый одновременно). Теперь Didi должен решить для git, какой код следует закоммитить и разместить в удаленном репозитории. Git-конфликты могут быть очень утомительными и хлопотными. Если бы Диди сделал git push заранее, он, вероятно, не уберег бы себя от решения этого git-конфликта, но, по крайней мере, он смог бы увидеть ошибку Коры раньше и связаться с ней по этому поводу.

Git-конфликт

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

<<<<<<< HEAD
this is our code in our local main branch that we worked on
=======
this is the code we got from the remote repository and leads
to this conflict
>>>>>>> commit-hash e.g. 91b20382340h234bc323ee

Git вставляет ‹‹‹‹‹‹‹ HEAD, ======= и ›››››››, чтобы показать вам, где вы должны очистить свой код. Лучше всего изменить код на правильную версию. Если вы знаете, что ваш код правильный, вы должны удалить следующую часть:

=======
this is the code we got from the remote repository and leads
to this conflict
>>>>>>> commit-hash e.g. 91b20382340h234bc323ee

ну и конечно же:

<<<<<<< HEAD

Остается правильная версия вашего кода:

this is our code in our local main branch that we worked on

Теперь вам нужно еще раз сохранить и зафиксировать изменения:

git add -A (-A is the parameter to add all modified files) 
git commit -m “merged and resolved conflicts in database layer”

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

Да, есть второй способ.

Сразу после того, как он осознал свой git-конфликт и определил, что Кора допустила ошибку, он мог прервать пуллинг, который привел к конфликтам:

git merge --abort

С помощью git merge — — abort Диди может прервать операцию извлечения, подойти к Коре и рассказать ей, что произошло. После этого Кора может удалить все свои коммиты в D, чтобы Диди мог вносить свои изменения без конфликтов.

Хорошая коммуникация в команде важна для всех разработчиков, чтобы быть более продуктивными и предотвращать ошибки. Имейте это в виду. Вы разработаете неправильный продукт без надлежащей коммуникации, как это сделала Кора. Не будь как Кора.

Git не так уж и страшен

Теперь вы сможете без проблем маневрировать своими ежедневными командами git на работе и понимать основы git как новичок. Вы уже знаете наиболее часто используемые команды:

git clone
git add
git commit
git push
git pull
git merge --abort

И это еще не все. Мы не говорили подробно о ветвях и слияниях. Мы сделаем это в следующей статье, так что следите за обновлениями.

А пока спасибо за чтение и получайте удовольствие от всех основных команд git. Говно.

И нет, git gud — это не команда git.

Дополнительные материалы на PlainEnglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter, LinkedIn, YouTube и Discord .

Заинтересованы в масштабировании запуска вашего программного обеспечения? Ознакомьтесь с разделом Схема.