Руководство выжившего по Git

Руководство выжившего по Git

или Как испечь торт с помощью Git

Git - это сложно. Git устрашающий. Это гигантская кривая обучения. И для инженеров-программистов это очень важно.

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

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

Я ненавидел каждую минуту изучения Git. Было трудно найти ресурсы для абсолютных новичков, а те немногие, что я нашел, были плохо написаны или особенно ясны. Часто они предполагают определенный уровень знаний, которого у вас может не быть (я не знал). Поэтому я хочу предоставить ресурс для людей, готовящихся к своей первой технической работе, или для инженеров, которые уже работают и испытывают «ох черт», как и я.

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

Что, черт возьми, такое Git?

Git - это программное обеспечение, которое вы устанавливаете на свой компьютер. Если вы еще не установили его, давай, сделай это.

Что отличает Git от, скажем, iTunes или Minesweeper (даже больше, чем его функциональность), так это то, что Git не имеет графического пользовательского интерфейса (или GUI). Графические интерфейсы - это то, что произвело революцию в вычислениях и сделало Стива Джобса и Билла Гейтса богатыми. До появления GUI вам приходилось взаимодействовать с программами через командную строку. Поскольку у Git нет графического интерфейса, вы также взаимодействуете с ним через командную строку (по крайней мере, иногда - подробнее об этом позже).

$ git checkout -b [branch name] origin/[branch name]

Когда вы видите что-то подобное на учебном сайте, это команда командной строки, которую нужно запускать в Терминале на Mac, в командной строке в Windows или в оболочке в Linux.

Вот одна из тех вещей, о которых люди думают, что вы знаете: $ обозначает весь мусор перед знаком доллара в терминале. Вот мой:

Kevins-MacBook-Pro-2:~ kevinmiller$

Когда вы видите $ в учебнике, вы просто вводите текст справа от него. [], {} Или ‹› означает, что вы должны указать свою собственную информацию. Вот как выглядит эта команда при вводе в терминал:

Kevins-MacBook-Pro-2:~ kevinmiller$ git checkout -b master origin/master

Подробнее о командах мы поговорим позже. Переходим к следующему логичному вопросу:

Но что он делает?

Хороший вопрос. Git - это инструмент для управления версиями (иногда его называют контролем версий). Он отслеживает изменения в файлах и позволяет нескольким людям совместно работать над одним и тем же файлом или набором файлов. Если у вас когда-либо было несколько файлов Microsoft Word с именами «Paper-Draft.docx» «Paper-Final.docx» «PaperFinal2.docx» «PaperFinalFinal.docx» «PaperTHISISTHERIGHTONE.docx», то вы понимаете необходимость контроля версий. Вы можете увидеть, как это может действительно выйти из-под контроля, если у вас есть пять, пятьдесят или, в случае большой компании, тысячи людей, работающих над одним и тем же документом. Git часто используется для разработки программного обеспечения, но может использоваться для отслеживания изменений практически в любом наборе файлов.

Звучит круто ... Как это сделать?

Git делает снимки вашей работы, которые называются коммитами. Возвращаясь к нашей аналогии с кошмаром в Microsoft Word (™), вы можете думать о фиксации, как если бы вы распечатали каждую версию своей курсовой работы и поместили ее в картотеку. Git делает это для каждого файла в вашем репозитории. Каждый раз, когда файл изменяется, создается новая копия. Репозиторий - это просто модное слово для обозначения «всех файлов, которые Git отслеживает для вас».

Как несколько человек могут сотрудничать, не наступая друг другу на ногу? Чаще всего люди будут работать в собственном филиале.

Согласно Atlassian

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

Это немного густо. Представьте, что вы начали курсовую работу с партнером. Вы отвечаете за написание статей на одну тему, а ваш партнер - за другую. Вы написали вводный абзац вместе, но теперь каждый из вас должен работать самостоятельно. Вы оба начнете с одного и того же документа «Paper-Intro.docx», но затем каждый из вас получит свой собственный картотечный шкаф! Вы сможете работать и отслеживать собственные версии независимо, но вы оба начали с одного и того же. В процессе работы каждый раз, когда вы переходите к версии, которую хотите сохранить (зафиксировать), вы распечатываете ее и храните в картотеке. Ваш партнер сделает то же самое со своим картотечным шкафом.

Многие учебники используют метафору дерева для описания ветвей; исходную ветвь (называемую главной) можно представить себе как ствол дерева. Каждая ветка на дереве идет от ствола, но отделяется сама по себе. Однако мне нравится думать об этом как о шоссе - скажем, у вас есть шоссе с одной полосой движения. Это ваша основная ветка. Если вы создадите еще одну ветку, шоссе превратится в двухполосное шоссе. Когда вы меняете ветки, это как будто переулок разветвляется на собственный выезд. Вы можете уехать и делать на нем все, что хотите, так как он отделен от шоссе. В конце концов, он снова выйдет на шоссе.

Поскольку у вас есть запись всех внесенных вами изменений (если вы решили их зафиксировать), легко сотрудничать, возвращаться к старым версиям, комбинировать версии и т. Д. Возможности безграничны. У проекта, скорее всего, будет несколько ветвей или несколько серий версий. По мере развития все эти ветви будут объединены, чтобы создать готовый продукт.

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

Но как Git?

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

Я сделал на своем компьютере папку «Список покупок». Сделайте то же самое, где-нибудь вы сможете это найти.

Хорошо, у нас есть папка. На данный момент у нас нет ни списка, ни Git. Итак, давайте превратим нашу папку в репозиторий Git. В командной строке выполните следующую команду:

$ cd <path_to_folder>

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

Kevins-MBP-2:gittutorial-ios kevinmiller$ cd /Users/kevinmiller/Developer/Shopping\ List

Что это сделало? Он изменил мой текущий каталог (cd) с моего старого (мой текущий рабочий проект) на тот, в котором мы хотим наш репозиторий Git. Итак, как только мы в нем, запустите эту команду:

$ git init

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

Хорошо, теперь давайте составим список покупок. Давайте упростим и создадим файл .txt (с помощью любого текстового редактора или с помощью командной строки, если вам нравится) под названием ShoppingList.txt. Добавим три ингредиента:

Eggs
Flour
Sugar

Теперь у нас есть основные ингредиенты для торта. Может быть, не наворочено, но все же может быть хорошо.

Помните, мы составляем простой список покупок для ясности и простоты понимания, но часто это код… Git работает одинаково для обоих!

Сохраните файл и введите:

$ git status

Вот что вы должны увидеть:

On branch master
No commits yet
Untracked files:
 (use "git add <file>..." to include in what will be committed)
	ShoppingList.txt
nothing added to commit but untracked files present (use "git add" to track)
Kevins-MBP-2:Shopping List kevinmiller$

Все идет нормально! Если вы видите что-то иное, откажитесь от всякой надежды и откажитесь от попыток. Просто шучу. Возможно, вы находитесь в неправильном каталоге, возможно, Git не установлен или вы забыли сохранить файл.

Прежде чем мы расскажем о том, что было сказано выше, давайте поговорим о графическом интерфейсе пользователя. Для Git существует несколько хороших оболочек с графическим интерфейсом. Я использую SourceTree и очень рекомендую его. Однако вы не можете бояться командной строки. Все можно сделать из командной строки, и в какой-то момент вам придется ее использовать. Графические интерфейсы могут многое, но не все. Это действительно вопрос личных предпочтений. В конечном счете, как только вы знаете, что вы хотите делать с Git, как вы это делаете (через командную строку или графический интерфейс) не имеет значения.

Выше мы спросили о нашем статусе и получили сообщение от Git. Он сообщил нам нашу ветку (нашу историю снимков, помните?), Которая является главной. В этом есть смысл. Мастер - это имя по умолчанию для первой ветви, так как это «главная копия».

Теперь там написано «без коммитов». Это тоже имеет смысл. Мы еще не сказали ему делать какие-либо коммиты.

Вот тут и становится интересно. Он говорит:

Untracked files:
 (use "git add <file>..." to include in what will be committed)
	ShoppingList.txt
nothing added to commit but untracked files present (use "git add" to track)

Git заметил, что мы создали новый файл - и это файл, который мы создали. Прохладный! Он также сообщает нам, что еще не отслеживает этот файл для нас. Мы этого хотим. К счастью для нас, в нем рассказывается, как это сделать с помощью $ git add ‹file›… что, как мы теперь знаем, означает $ git add ShoppingList.txt. Давай, сделай это.

Прохладный. Что теперь? Сделайте $ git status еще раз.

On branch master
No commits yet
Changes to be committed:
 (use "git rm --cached <file>..." to unstage)
	new file:  ShoppingList.txt

Ok! Теперь он говорит, что у нас есть некоторые изменения! да. Мы перешли от отсутствия файла к файлу ShoppingList.txt с тремя элементами. Git сообщает нам, что будет в следующем коммите. Но мы еще не приказали ему совершить. Давайте сделаем это.

$ git commit -m "Created shopping list for cake"

Что это -м? Это ярлык для ввода сообщения фиксации. Никогда не выполняйте фиксацию без сообщения фиксации, но никогда не выполняйте фиксацию с общим сообщением фиксации, например WIP. Вы хотите быть краткими, но описательными в своих сообщениях о коммитах. Это может показаться немного болезненным, но подумайте об этом: вся причина, по которой мы используем Git, - это отслеживать изменения в наших файлах. Четкие сообщения о фиксации имеют решающее значение, если (когда) вам нужно просмотреть историю своих файлов или просмотреть чужую работу. Обратитесь к этой статье, чтобы ознакомиться с примерами лучших практик написания сообщений о фиксации.

Поздравляю! Вы сделали свою первую фиксацию. Сделаем еще.

Этот торт немного скучноват. Давайте добавим немного начинки и разложим по частям. Мы также хотим заменить муку на масло, так как мука у нас уже есть дома. (Можете ли вы представить себе этот список в виде кода? Каждый «рецепт» может быть функцией.)

--- Cake ---
Eggs
Butter
Sugar
--- Toppings ---
Strawberries
Raspberries
Chocolate

Хорошо, давайте сделаем то же самое, что и раньше:

$ git status
On branch master
Changes not staged for commit:
 (use "git add <file>..." to update what will be committed)
 (use "git checkout -- <file>..." to discard changes in working directory)
	modified:  ShoppingList.txt
no changes added to commit (use "git add" and/or "git commit -a")

Итак, теперь у нас есть кое-что другое. «Изменения, не предназначенные для фиксации…», что это значит? Это означает, что мы внесли некоторые изменения, но они еще не были зафиксированы или «сохранены».

Вкратце о том, как работает Git: я упоминал ранее, что Git сохраняет снимки или фиксирует весь ваш проект. Если вы сделаете копии каждого файла и в вашем проекте будут тысячи коммитов и тысячи файлов (в моем текущем проекте - 2446), он станет действительно большим и очень быстро. Итак, как Git справляется с этим? Он создает новую копию файла только в случае внесения изменений. В противном случае он ссылается на старую копию файла. Здесь он сравнивает последнюю копию имеющегося файла с новой и говорит: «Привет! Они разные, что ты хочешь делать? »

Посмотрим, что это за изменения ...

diff --git a/ShoppingList.txt b/ShoppingList.txt
index b61f001..774565b 100644
--- a/ShoppingList.txt
+++ b/ShoppingList.txt
@@ -1,3 +1,9 @@
+--- Cake ---
 Eggs
 -Flour
+Butter
 Sugar
+
+--- Toppings ---
+Strawberries
+Raspberries
+Chocolate

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

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

$ git add ShoppingList.txt
$ git commit -m "Added ingredients for fruit torte, removed flour"

Потрясающие! Теперь список покупок выглядит неплохо. Но перед тем, как отправиться за покупками, Пол Голливуд и Мэри Берри хотят добавить несколько товаров в список покупок. Давайте создадим для них новые ветки, чтобы они могли добавлять элементы в список.

(Поиграйте здесь… мы собираемся сделать все это сами, но представьте, что вы действительно сотрудничаете с коллегами, которым нужно работать над одним и тем же файлом.)

Давайте создадим ветвь для Пола и ветвь для Марии:

$ git branch pauls-branch
$ git branch marys-branch

Все в порядке! Теперь мы создали ветки, чтобы Пол и Мэри работали отдельно. Хотя это не совсем точно, вы можете думать о создании ветки как о создании новой копии проекта. Затем Пол и Мэри внесут изменения в свои собственные копии, а не в основную копию (ветвь). Они (мы) собираемся внести изменения. Сначала сделайте следующее:

$ git branch

Вот что вы должны увидеть:

marys-branch
* master
pauls-branch

У нас есть три ветки: две, которые мы только что создали, и исходная, master. Продолжая метафору с шоссе из начала статьи, теперь у нас есть трехполосное шоссе. Одна из этих полос собирается съехать.

Итак, давайте проверим ветку и начнем составлять список покупок:

$ git checkout pauls-branch

Если хотите, запустите $ git branch еще раз, и вы увидите, что теперь звездочка находится на pauls-branch. Извлечение ветки делает ее вашей активной рабочей копией. Любые изменения, которые вы вносите в свои файлы, будут зафиксированы в этой ветке.

Хорошо, пора добавить что-нибудь в список покупок Пола. Откройте список покупок и внесите следующие изменения:

--- Cake ---
Eggs
Unsalted Butter
Sugar
--- Toppings ---
Blackberries
Raspberries
Chocolate

Пол претенциозен и любит несоленое масло, поэтому он сменил масло. Он также заменил клубнику на ежевику. Сохраните файл, и давайте подготовим и зафиксируем эти изменения.

$ git add -A

Что это? Это просто ярлык для размещения всех файлов, которые были изменены. В Git есть несколько способов сделать то же самое.

$ git commit -m "Added ingredients for summer fruit genoise"

Нам нужен только один список покупок, поэтому давайте объединим его в главный. Сначала кассир (помните, это главная магистраль).

$ git checkout master

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

Теперь мы собираемся объединить ветку Пола обратно в наш исходный список покупок:

$ git merge pauls-branch

Не так уж и плохо, правда? Теперь изменения Павла должны быть отражены в нашем списке! Откройте его и проверьте. Давайте проверим ветку Мэри и добавим в нее кое-что.

$ git checkout marys-branch

Откройте список покупок. Вы увидите, что он вернулся к тому состоянию, из которого мы вышли. Давайте внесем изменения Мэри. (Замени клубнику на чернику.)

--- Cake ---
Eggs
Butter
Sugar
--- Toppings ---
Blueberries
Raspberries
Chocolate

Ok. Сохраните файл, затем подготовьте и зафиксируйте изменения.

$ git add -A
$ git commit -m "Added ingredients for blueberry cake"

Ok! Давайте объединим это в главную ветку.

$ git checkout master
$ git merge marys-branch

Ой ой! Что-то пошло не так!

CONFLICT (content): Merge conflict in ShoppingList.txt
Automatic merge failed; fix conflicts and then commit the result.

Так что здесь происходит? Как вы уже догадались, это было сделано намеренно. Это называется конфликтом слияния, и как в жизни конфликты случаются постоянно.

Когда я только начинал, слова конфликт слияния наполнили меня ужасом. Давай попробуем разобраться, чтобы они не боялись. Что вызывает конфликт слияния? Согласно Справке Github, конфликты слияния возникают, когда вы сливаете ветки, в которых есть конкурирующие коммиты. Давайте разберемся с этим немного. Пол и Мэри разошлись одновременно, а это значит, что они начали с одной и той же версии списка покупок. Пол внес некоторые изменения, а Мэри внесла некоторые изменения. Мы объединили изменения Пола в наш главный список покупок, и теперь мы пытаемся объединить версию Мэри в.

Несмотря на то, что это был не исходный файл, с которого мы начали, Git все равно попытается внести изменения. Он знает, что в строке 6 мы пытаемся изменить strawberries -> blueberries, но у нас blackberries вместо strawberries, потому что Пол изменил его. У нас есть «конкурирующие коммиты». Git не знает, что здесь делать, и ему нужно руководство. Вот где мы и вступаем.

Откройте файл ShoppingList.txt. Вы увидите там кое-что новенькое:

--- Cake ---
Eggs
Unsalted Butter
Sugar
--- Toppings ---
<<<<<<< HEAD
Blackberries
=======
Blueberries
>>>>>>> marys-branch
Raspberries
Chocolate

‹‹‹‹‹‹ и ======= называются маркерами конфликта. Они показывают вам конфликты между двумя файлами, которые необходимо разрешить. HEAD - это ваша рабочая ветка или ветка, с которой вы пытаетесь слиться. В данном случае ГОЛОВА говорит, что малина. В ветке Мэри написано черника, что мне делать?

Если бы мы хотели сказать: «Нет, Пол, ежевика сейчас слишком дорога», мы бы удалили ежевику. Однако мы продолжим и оставим и то, и другое. Вот почему Git не просто заменил ежевику на ›чернику; нам может понадобиться и то, и другое - что мы и делаем. Удалите маркеры конфликта, отредактируйте файл и сохраните.

Теперь вы можете спросить себя, почему не было конфликта с маслом? В ветке Мэри было обычное масло, а в ветке Пола - несоленое? Что ж, Мэри не пыталась менять масло, поэтому Гит выбрал сдачу Пола, которая уже была у мастера.

--- Cake ---
Eggs
Unsalted Butter
Sugar
--- Toppings ---
Blackberries
Blueberries
Raspberries
Chocolate

Большой! Мы разрешили конфликт. Однако нам еще предстоит завершить слияние. Помните, что выше было сказано исправить конфликты, а затем зафиксировать результат.

$ git add -A
$ git commit -m "Merged marys list"

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

Когда все идет хорошо, рабочий процесс Git довольно прост:

1. Оформить заказ в филиале
2. Вносить изменения
3. Сценические изменения
4. Зафиксировать изменения
5. Вернуться к 1

Удаленное или локальное

Все, что мы делали в этом руководстве, было локальным, что означает, что наши компьютеры отслеживают все эти файлы на нашем компьютере, и они больше нигде не существуют. Это не очень полезно, если вы сотрудничаете с коллегами и хотите делать очень разумные вещи, например использовать разные компьютеры. Ну так что ты делаешь? Отслеживайте эти изменения в Интернете с помощью удаленного репозитория. Часто это будет размещено на веб-сайтах, таких как BitBucket или GitHub, что означает, что ваша база кода (в нашем случае, наш список покупок) будет храниться где-то еще, на чужом компьютере.

Итак, если код хранится где-то еще, как нам внести в него изменения? Во-первых, нам нужно клонировать этот репозиторий.

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

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

push означает принятие внесенных вами изменений и отправку их на пульт (место, где хранится ваша кодовая база). Помните, когда Мэри внесла изменения в рецепт торта? После этого ей нужно будет отправить свои изменения на пульт, например:

$git push origin marys-branch

Если ветка еще не существовала, ей пришлось бы использовать:

git push -u origin marys-branch

-U - это сокращение от –set-upstream, которое указывает Git на создание «восходящей» или удаленной ветки. Мэри Берри, конечно, знает это, поскольку она эксперт по Git.

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

$ git pull master получает все изменения, которые были сделаны с тех пор, и обновляет локальную ветку.

На мой взгляд, запрос на вытягивание - очень запутанное название. Допустим, Мэри отвечает за хранилище кодов списка покупок. Пол отделился от мастера, внес некоторые изменения и перенес эти изменения на пульт. Теперь он хочет, чтобы эти изменения были объединены в мастер. Что ж, поскольку Мэри отвечает и должна утвердить эти изменения, он отправляет так называемый запрос на вытягивание или для краткости PR. Он просит, чтобы Мэри перетащила его ветку в главную ветку. Видеть? Думаю, это натянуто. Он действительно просит Мэри объединить его ветку с мастером.

Запрос на вытягивание осуществляется через сервис типа BitBucket или Github. Помимо размещения вашего репозитория, они предоставляют возможность коллегам отправлять и просматривать запросы на вытягивание друг друга (это называется проверка кода). Мэри просто войдет в Github, чтобы посмотреть PR Пола. Она увидит изменения, которые он просит внести, и получит возможность комментировать и запрашивать изменения, прежде чем утвердить или отклонить.

Git: последний рубеж

В реальном мире ваш проект будет более сложным, чем этот. У вас будут более длинные файлы, больше файлов и больше веток (надеюсь, не слишком много). Обычно это ветвь master, ветка develop и несколько веток feature. Основная ветвь обычно представляет собой производственный код (например, действующий веб-сайт или приложение в iTunes Store). Разработка представляет собой код, который находится в разработке. Обычно разработчики создают новые ветви разработки для каждой функции, над которой они работают, а затем объединяют их обратно в разработку по завершении. Когда новая версия будет протестирована, станет стабильной и будет готова к выпуску, разработка будет объединена с master.

Хотите верьте, хотите нет, но рабочий процесс для Git почти такой же, как для простого списка покупок, приведенного выше, и для реального мира. Давайте посмотрим на процесс, который мы сделали, и сравним его с реальным рабочим процессом.

Требуется работа. В нашем случае нам нужно было добавить ингредиенты для торта. Реальным примером может быть добавление метода в ваш объект службы данных для подключения к API.

Кто-то приступает к работе. Выше Пол и Мэри сделали ветки, чтобы добавить свои ингредиенты. В реальном мире вы можете отделиться от разработки и создать ветку под названием «feature / integration-all-recipes-API».

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

func getRecipesWith(ingredients: [String],
                        success: @escaping (([Recipe]) -> Void),
                        failure: @escaping ((APIError) -> Void)) {
        let endpoint = "\(DataStore.ingredientFilterEndpoint)"
        requestManager.request(withEndpoint: endpoint,
                               method: .GET,
                               params: [DataStore.ingredientsKey: ingredients.commaDelimitedComponents],
                               success: { responseObject in
                                guard
                                    let json = responseObject as? JSON,
                                    let recipeList = RecipeList(json: json),
                                    let recipes = recipeList.recipes else {
                                        failure(APIError(failingURL: endpoint,
                                                         message: "Cannot parse Recipe from JSON"))
                                        return
                                }
                                success(recipes)
        }, failure: { error in
            if let error = error {
                failure(error)
            }
        })
    }

Изменения поэтапные. Мы инсценировали все изменения в этом руководстве, но если бы мы написали что-то, что мы не хотели фиксировать, например, тестовую функцию, такую ​​как:

func generateFakeRecipe() -> Recipe

Мы могли бы решить не инсценировать это.

Изменения зафиксированы. Мы подтверждаем изменения, которые хотим сохранить. Один из высказываний Пола был «Добавлен фрукт для летнего генуаза», реальный мир мог бы быть «Добавлен метод в хранилище данных для получения массива рецептов, отфильтрованного по ингредиентам».

Изменения внесены. По окончании работы ветка будет переведена на удаленную.

Изменения рассматриваются. коллеги просматривают и комментируют / запрашивают изменения.

Изменения объединены. Ветка объединена!

Это все, что нужно знать о Git? Отнюдь не. Возможно, вам придется провести дополнительные исследования самостоятельно, прежде чем вы почувствуете себя комфортно. Вам обязательно придется попрактиковаться, облажаться и еще немного попрактиковаться. Старайтесь не слишком пугаться - почти все можно отменить. Git очень безопасен. Не бойтесь просить о помощи; большинство разработчиков помнят, каково было изучать Git.

Я надеюсь, что вы смогли извлечь из этой статьи то, чего у меня не было: консолидированное место для изучения самых основ Git в простой для понимания форме, без каких-либо предположений. Удачи и удачного кодирования!