A3.5 Приложение C: Команды Git — Совместная работа и обновление проектов
Не так уж много команд в Git требуют сетевого подключения для своей работы, практически все команды оперируют с локальной копией проекта. Когда вы готовы поделиться своими наработками, всего несколько команд помогут вам работать с удалёнными репозиториями.
git fetch
Команда git fetch связывается с удалённым репозиторием и забирает из него все изменения, которых у вас пока нет и сохраняет их локально.
Мы познакомились с ней в разделе Получение изменений из удалённого репозитория — Fetch и Pull главы 2 и продолжили знакомство в разделе Удалённые ветки главы 3.
Мы использовали эту команду в нескольких примерах из раздела Участие в проекте.
Мы использовали её для скачивания запросов на слияние (pull request) из других репозиториев в разделе Ссылки на запрос слияния главы 6, также мы рассмотрели использование git fetch для работы с упакованными репозиториями в разделе Создание пакетов главы 7.
Мы рассмотрели тонкую настройку git fetch в главе и Спецификации ссылок.
git pull
Команда git pull работает как комбинация команд git fetch и git merge , т. е. Git вначале забирает изменения из указанного удалённого репозитория, а затем пытается слить их с текущей веткой.
Мы познакомились с ней в разделе Получение изменений из удалённого репозитория — Fetch и Pull главы 2 и показали как узнать, какие изменения будут приняты в случае применения в разделе Просмотр удаленного репозитория главы 2.
Мы также увидели как она может оказаться полезной для разрешения сложностей при перемещении веток в разделе Меняя базу, меняй основание главы 3.
Мы показали как можно использовать только URL удалённого репозитория без сохранения его в списке удалённых репозиториев в разделе Извлечение удалённых веток главы 5.
И наконец мы показали как проверять криптографические подписи полученных коммитов, используя опцию —verify-signatures в разделе Подпись коммитов главы 7.
git push
Команда git push используется для установления связи с удалённым репозиторием, вычисления локальных изменений отсутствующих в нём, и собственно их передачи в вышеупомянутый репозиторий. Этой команде нужно право на запись в репозиторий, поэтому она использует аутентификацию.
Мы познакомились с этой командой в разделе Отправка изменений в удаленный репозиторий (Push) главы 2. Там мы рассмотрели основы обновления веток в удалённом репозитории. В разделе Отправка изменений главы 3 мы подробнее познакомились с этой командой, а в разделе Отслеживание веток главы 3 мы узнали как настроить отслеживание веток для автоматической передачи на удалённый репозиторий. В разделе Удаление веток на удалённом сервере главы 3 мы использовали флаг —delete для удаления веток на сервере, используя git push .
На протяжении раздела Участие в проекте мы показали несколько примеров использования git push для совместной работы в нескольких удалённых репозиториях одновременно.
В разделе Публикация изменений подмодуля главы 7 мы использовали опцию —recurse-submodules чтобы удостовериться, что все подмодули будут опубликованы перед отправкой проекта на сервер, что может быть реально полезным при работе с репозиториями, содержащими подмодули.
В разделе Прочие хуки на стороне клиента главы 8 мы поговорили о триггере pre-push , который может быть выполнен перед отправкой данных, чтобы проверить возможность этой отправки.
Наконец, в разделе Спецификации ссылок для отправки данных на сервер главы 10 мы рассмотрели передачу данных с полным указанием передаваемых ссылок, вместо использования распространённых сокращений. Это может быть полезным если вы хотите очень точно указать, какими изменениями хотите поделиться.
git remote
Команда git remote служит для управления списком удалённых репозиториев. Она позволяет сохранять длинные URL репозиториев в виде понятных коротких строк, например «origin», так что вам не придётся забивать голову всякой ерундой и набирать её каждый раз для связи с сервером. Вы можете использовать несколько удалённых репозиториев для работы и git remote поможет добавлять, изменять и удалять их.
Эта команда детально рассмотрена в разделе Работа с удалёнными репозиториями главы 2, включая вывод списка удалённых репозиториев, добавление новых, удаление или переименование существующих.
Она используется практически в каждой главе, но всегда в одном и том же виде: git remote add <имя> <URL> .
git archive
Команда git archive используется для упаковки в архив указанных коммитов или всего репозитория.
Мы использовали git archive для создания тарбола ( tar.gz файла) всего проекта для передачи по сети в разделе Подготовка релиза главы 5.
git submodule
Команда git submodule используется для управления вложенными репозиториями. Например, это могут быть библиотеки или другие, используемые не только в этом проекте ресурсы. У команды submodule есть несколько под-команд — add , update , sync и др. — для управления такими репозиториями.
Практическое руководство по использованию Git. Часть 3
Перевод третьей части статьи «How to Use Git and Git Workflows – a Practical Guide».
Photo by Sigmund on Unsplash
В первой части статьи мы рассмотрели установку Git, создание нового репозитория на GitHub и его клонирование на локальную машину. Также мы разобрали тему веток, научились проверять статус проекта и делать коммиты. Во второй части мы запушили наш коммит на GitHub, поближе познакомились со стейджингом, научились просматривать разницу между коммитами, создавать ветки отдельных функций и пушить их в репозиторий.
В этой части мы рассмотрим:
Совместная работа в Git
Вставить нашу Главу 2 в ветку main локально и на GitHub можно двумя разными способами. Выбор зависит от проекта и принятых в коллективе процедур.
Давайте рассмотрим оба варианта.
Первый — самый простой:
- Слить изменения из chapter-2 в локальную ветку main .
- Запушить локальную ветку main в origin/main .
Второй способ немного сложнее:
- Запушить нашу локальную ветку chapter-2 в origin (это создаст в origin новую ветку — origin/chapter-2 ).
- Слить origin/chapter-2 в origin/main на GitHub.
- Вытащить новые изменения из origin/main в нашу локальную ветку main .
Первый подход определенно проще. Если бы я работал над проектом один, без коллег, то, безусловно, выбрал бы его.
Но работая совместно с другими людьми, я бы предпочел не пушить свою локальную ветку напрямую в ветку main . Таким образом я бы изменил историю проекта и взял бы ее под контроль лично своих изменений — без ревью и какого-либо участия коллег.
Поэтому, если над одним проектом работает несколько человек, я предпочту второй способ, потому что для команды такая процедура лучше.
В этом руководстве мы рассмотрим оба варианта. Начнем с первого, как менее сложного.
Как слить (смержить) ветку в Git
Если вы хотите соединить содержимое двух веток в одной, вы можете сделать это разными способами. Первый и, вероятно, самый простой — сделать merge (слияние).
Как и следует из названия, merge пытается влить содержимое одной ветки в другую.
В нашем случае мы хотим взять содержимое ветки chapter-2 и слить (смержить) их в main . Иными словами, мы хотим взять текущее состояние main и добавить в него наши изменения из ветки chapter-2 .
Мы можем это сделать при помощи команды git merge , а потом оценить результаты.
Первое, что нам нужно сделать, это оказаться в той ветке, куда мы хотим сливать изменения. Поскольку мы хотим, чтобы main вобрала в себя изменения из chapter-2 , нам нужно оказаться в ветке main .
Чтобы переключиться обратно в ветку main , мы можем применить команду git checkout и указать имя ветки — main . Теперь мы не будем добавлять флаг -b , как делали в прошлый раз, потому что переключаемся в уже существующую ветку, а не создаем новую:
Мы вернулись в ветку main и получили короткое сообщение о статусе: наша ветка полностью соответствует origin/main .
Теперь давайте смержим chapter-2 в main :
Посмотрим результат в логе:
Мы видим, что в нашей ветке main теперь содержится новый коммит из chapter-2 , а наш origin по-прежнему стоит на предыдущем коммите (поскольку мы его еще не обновляли).
Наконец, давайте отправим (запушим) наши изменения в origin/main :
Мы успешно смержили нашу ветку chapter-2 и запушили наши изменения на GitHub!
Финальный шаг: нам нужно удалить ветку функции chapter-2 , поскольку она уже слита в main :
Примечание. Команда git branch без указания ветки в качестве аргумента выведет список всех веток, которые есть в вашем локальном проекте. Добавление флага -d и имени ветки позволяет удалить указанную ветку.
Процедура пул-реквестов
Чтобы изучить командную работу над проектом, давайте повторим действия, которые мы уже совершали, создавая Главу 1 и 2, и создадим новую ветку с Главой 3 — chapter-3 . Не упустите возможность попробовать сделать это самостоятельно!
Итак, у нас есть новый коммит в новой ветке chapter-3 .
Давайте повторим наш план действий. Мы собираемся смержить эти изменения в main , но при этом самостоятельно не трогать main . Для этого мы:
- запушим нашу локальную ветку chapter-3 в origin (это создаст в origin новую ветку — origin/chapter-3 );
- смержим origin/chapter-3 в origin/main на GitHub;
- вытащим новые изменения из origin/main в нашу локальную ветку main .
В общем, будет пара дополнительных шагов, но ничего сверхъестественного.
Первый шаг — запушить новую ветку на GitHub. Поскольку этой ветки в нашем удаленном репозитории еще не существует, GitHub создаст для нас новую ветку — копию той, которую мы отправили:
Теперь, когда наша ветка есть на GitHub, мы можем создать пул-реквест (pull request), чтобы его просмотрели наши коллеги.
GitHub даже предоставляет нам URL, чтобы мы могли посмотреть результат своих действий: https://github.com/johnmosesman/practical-git-tutorial/pull/new/chapter-3.
Пара примечаний. В следующей части будет обсуждаться процесс работы с пул-реквестами в пользовательском интерфейсе GitHub, но в других сервисах (GitLab, Bitbucket и т. п.) все происходит аналогичным образом.
Также имейте в виду, что я использую собственный репозиторий, так что URL-ы, которые вы здесь увидите, могут отличаться от ваших.
Перейдя по указанному выше адресу, мы попадаем на страницу для открытия нового пул-реквеста.
Мы видим несколько вещей:
- место для указания имени пул-реквеста (предложение с указанием темы, позволяющее легко определить, о чем этот пул-реквест)
- блок для описания, где мы можем объяснить сделанные нами изменения и дать любой необходимый контекст (также можно добавить изображения, гифки или видео)
- под всем этим — список файлов, которые мы изменили, и самих изменений ( diff ).
Открываем новый пул-реквест
Обратите внимание, что UI показывает base: main <- compare: chapter-3 . Таким образом GitHub сообщает нам, что мы составляем пул-реквест для вливания chapter-3 в main .
Под описанием пул-реквеста мы видим diff внесенных изменений:
diff пул-реквеста
Можно заметить, что нам показан только файл chapter-3.txt. Это потому, что только он у нас изменился.
В настоящее время в нашем проекте есть и другие файлы (chapter-1.txt, chapter-2.txt), но они не менялись, так что показывать их нет нужды.
Мы видим одну строку, которую вставили в chapter-3.txt, перед которой стоит знак плюс, а также видим зеленый фон, означающий добавление контента в файл.
После нажатия «Create Pull Request» («Создать пул-реквест») мы попадаем в новый, только что созданный PR (пул-реквест).
На этом этапе мы можем назначить нашему PR ревьюера и вступить с ним в обсуждение нашего кода. Обсуждение идет путем добавления комментариев к отдельным строкам в diff . После проверки кода (код-ревью) и внесения всех нужных изменений мы можем смержить наш код.
В этом руководстве мы пропустим процедуру ревью и просто кликнем большую зеленую кнопку merge:
Смерженный пул-реквест
После этого наш пул-реквест вольется в main !
Как обновить локальный репозиторий
Итак мы внесли изменение в origin/main безопасным и контролируемым способом, а наши изменения прошли код-ревью.
Но наш локальный репозиторий ничего не знает об этих изменениях. Локально Git все еще думает, что мы находимся в ветке chapter-3 , которая не слита в main :
git log показывает, что origin/main указывает на предыдущий коммит, начинающийся с 741822. Чтобы обновить наш локальный репозиторий, нам нужно вытянуть новую информацию из нашего origin .
Как получить данные из удаленного репозитория
В Git зачастую одну и ту же задачу можно выполнить разными способами, и этот случай — не исключение.
Для целей этой статьи мы рассмотрим самый простой способ, который работает в большинстве случаев.
Для начала давайте переключимся обратно на нашу локальную ветку main :
Git думает, что эта ветка полностью соответствует origin/main , потому что со времени клонирования удаленного репозитория мы пока не получали из него новую информацию.
Репозитории Git не обновляются в режиме реального времени. Это лишь снимки истории на определенные моменты времени. Чтобы получить новую информацию о репозитории, нам нужно запросить ее заново.
Для запроса новой информации мы используем команду git fetch (англ. fetch — делать выборку):
В выводе мы видим, что origin/main сейчас указывает на коммит, начинающийся с 10630f2. Этот префикс совпадает с SHA коммита, по которому мы делали пул-реквест.
Есть несколько способов смержить две ветки (одну в другую), и один из них — создать merge commit. Это здесь и произошло.
merge commit нашего PR
Теперь наш локальный репозиторий знает о наличии новых коммитов, но мы пока ничего с ними не делали.
Запуск git fetch ничего не меняет в наших файлах. Мы просто загрузили из удаленного репозитория новую информацию о его статусе.
Теперь наш локальный репозиторий знает о статусе каждой ветки (но эти ветки локально не изменены и не обновлены). Давайте еще раз проверим статус проекта:
Наш локальный Git теперь знает, что локальная ветка main отстает от origin/main на 2 коммита (коммит из ветки chapter-3 и merge commit пул-реквеста).
Он также подсказывает нам использовать git pull для обновления локальной ветки:
Команда git pull — это, собственно, сокращенная форма запуска двух команд: git fetch , за которой сразу идет git merge .
Команда git fetch не вносит никаких изменений в локальный репозиторий. Поэтому она полезна для проверки того, соответствуют ли наши ветки веткам в удаленном репозитории (мало ли — может, мы пока вообще не хотим мержить свои изменения). Также эта команда удобна для вытаскивания новых веток, существующих в удаленном репозитории, но пока отсутствующих на нашей локальной машине.
Когда мы делаем выборку (fetch) новой ветки из удаленного репозитория, она загружается на нашу локальную машину. Поскольку до сих пор такой ветки у нас не было, любые конфликты исключены.
Мы могли бы изначально сделать git pull и обойтись без git fetch , но я хотел познакомить вас с git fetch , потому что это очень полезная команда.
После запуска git pull запустим еще раз git status , чтобы посмотреть, все ли обновилось.
Вот и все! Мы вытащили наши изменения из удаленного репозитория и обновили локальный!
Как исправлять конфликты слияния в Git
И последняя важная тема, которую мы рассмотрим, — как быть с конфликтами.
Пока что Git просто чудесно справлялся со всеми обновлениями файлов. Чаще всего так и происходит. Но бывают случаи, когда Git не знает, как скомбинировать изменения, и это создает конфликт.
Конфликт происходит при попытке слить два изменения, касающиеся одной и той же строки в файле. Если два коммита изменили одну строку, Git не знает, какие именно изменения применить. Тут выбор придется делать вам.
Чтобы смоделировать такой сценарий, мы создадим еще одну ветку на GitHub — chapter-3-collaboration . Представим, что наш коллега уже начал работать над этой веткой и попросил нас принять участие в завершении Главы 3.
Поскольку это новая ветка, которой у нас нет на локальной машине, мы можем получить информацию о ней из удаленного репозитория при помощи git fetch , а затем перейти в эту ветку при помощи git checkout :
Мы вытащили новую ветку в свой локальный репозиторий и переключились на нее. В настоящее время в этой ветке в файле chapter-3.txt есть следующий текст:
Это название главы и одно предложение. Давайте изменим название, например, назовем главу «Chapter 3 — The End Is Only The Beginning».
Теперь содержимое файла chapter-3.txt выглядит так:
После коммита этих изменений мы можем попытаться их запушить, но получим следующее сообщение:
Наш коллега уже сделал какие-то коммиты до нас и запушил их в удаленную ветку. Наша локальная ветка теперь отстает от удаленной. Поэтому GitHub не будет принимать наш push, пока мы не смержим изменения, внесенные нашим товарищем:
В сообщении также есть подсказка, как это сделать: воспользоваться git pull .
А после применения команды git pull мы получаем конфликт слияния (название раздела как бы намекало на это).
Git попытался автоматически влить изменения, сделанные нашим коллегой, в наши. Но в файле было место, которое он не смог смержить автоматически: мы оба изменили одну и ту же строку.
Git остановился посреди мержа и сообщил, что прежде чем он сможет завершить, нам нужно разрешить конфликты слияния. Давайте посмотрим статус проекта в настоящее время:
Наша ветка и удаленная ветка отличаются друг от друга на 1 коммит. Git также сообщает, что у нас есть некоторые «размерженные пути» («unmerged paths»), т. е., мы выполнили слияние наполовину и должны разрешить конфликты.
Нам показано, что файл chapter-3.txt изменен. Давайте посмотрим на его содержимое:
Git добавил в файл маркеры, показывающие, где именно случился конфликт. И мы, и наш коллега изменили название главы, поэтому наши варианты окружены маркерами конфликта — стрелками <<< и >>> — и разделены линией === .
Верхняя строка — «Chapter 3 — The End Is Only The Beginning» — помечена <<<<<<< HEAD . Это изменение, которое внесли мы. Git показывает, что это строка, на которую в настоящее время указывает HEAD. Т.е. это изменение в нашем текущем коммите.
Строка ниже — «Chapter 3 — The End But Not The Ending» — помечена >>>>>>> 2f6874f650a6a9d2b7ccefa7c9618deb1d45541e . Это строка и номер коммита нашего коллеги.
В общем, Git спрашивает: «Какую из этих строк (или какую их комбинацию) вы хотите сохранить?»
Обратите внимание, что строка внизу файла не помечена маркерами. Она ни с чем не конфликтует, так как не была изменена сразу двумя коммитами.
Нам нужно разрешить конфликт, удалив одну из строк или скомбинировав две строки в одну (еще нужно не забыть удалить лишние маркеры, вставленные Git).
Я собираюсь скомбинировать строки, чтобы итоговый вариант выглядел так:
Чтобы завершить этот мерж, нам нужно просто закоммитить наше разрешение конфликта:
В результате git status сообщает нам, что наша локальная ветка опережает ветку в origin на 2 коммита ( is ahead of ‘origin/chapter-3-collaboration’ by 2 commits ).
Лог подтверждает это:
Итоговая история коммитов содержит оба коммита в этой ветке и наш merge commit сверху.
Нам остается лишь запушить наши изменения в удаленную ветку:
Теперь, чтобы мержить в новые изменения, нашему коллеге нужно будет сделать git pull .
В идеале мы сообщим ему, что мы запушили новое изменение. Так он сможет сначала вытянуть эти изменения на свою машину, а уж потом продолжить редактирование. Это снизит вероятность того, что теперь уже ему придется разрешать конфликт слияния.
Ответвления веток
Мы также могли бы создать нашу собственную ветку, сделав ответвление от chapter-3-collaboration . Это позволило бы нам работать, не беспокоясь о конфликтах слияния до самого конца работы.
Завершив работу в нашей отдельной ветке, мы могли бы смержить нашу ветку в ветку коллеги, а затем в main .
Как видите, по мере появления новых веток и параллельной работы над ними структура становится все более сложной.
Из-за этого в целом считается здравой идеей делать маленькие изолированные ветки и стараться мержить их как можно быстрее.
Это позволяет избежать многих болезненных конфликтов слияния.
Повторение: как начать рабочий процесс над новым функционалом
Давайте быстренько повторим, как начать работать над новой задачей и какие команды для этого потребуются.
Допустим, вам на вашей новой работе выдали первый тикет. Нужно исправить маленький баг в продукте вашей команды.
Первое, что нужно сделать, это вытащить репозиторий на свою локальную машину при помощи команды git clone <URL> .
Затем нужно создать ветку для своей работы (feature branch). Вы делаете ответвление от main, используя команду git checkout -b <имя_ветки> . После этого вы исправляете баг и делаете коммит изменений при помощи git add и git commit .
Возможно, решение проблемы потребует нескольких коммитов. Также может случиться, что вы сделаете несколько коммитов в безуспешных попытках решить проблему, прежде чем вам это наконец удастся. Это нормально.
После итогового коммита вы делаете push своей новой ветки в origin ( git push origin <имя_ветки> ) и создаете пул-реквест. После прохождения код-ревью ваша ветка будет слита (ура!).
Вы успешно выполнили порученную вам задачу. Пора переключиться назад в main (при помощи git checkout main ), применить git pull , чтобы вытянуть последние изменения (как свои, так и чужие) и начать все заново в новой ветке.
Итоги
Как я говорил в начале статьи, в Git одинаковые задачи можно решать по-разному. В нем также много невидимой «магии» (т. е. кода, который запускается, хотя вы его пока не понимаете). Со временем вы научитесь многим другим приемам работы.
Я провел первые годы своей карьеры, просто пользуясь заученными командами и процедурами. Это работало. Встречаясь с проблемами и работая вместе с коллегами, я учился все новым приемам, и в результате мои навыки работы с Git улучшились.
Со временем и вы всему научитесь. Но в самом начале не усложняйте себе жизнь без необходимости!
Git, как обновить проект ?
Недавно начал работать с Git и столкнулся со следующей ситуацией:
У себя на локальном сервере я разработал проект и залил его в репозиторий. Далее я зашел на сервер, клонировал проект, установил и настроил его.
Спустя время я продолжил разработки проекта на локальном сервере и снова обновил репозиторий. Теперь хотелось бы обновить проект на продакшине так сказать.
Как я понял удалять заново устанавливать и настраивать все файлы не вариант. Подскажите пожалуйста что нужно сделать ?
- Вопрос задан более трёх лет назад
- 73258 просмотров
- Вконтакте
- Вконтакте
Вам нужен центральный репозиторий, в который вы сможете загружать ваши новые правки с помощью git push (с любого компьютера), и из которого сможете загружать их в любое место, где у вас этот репозиторий склонирован, с помощью git pull. См. раздел о работе с удалёнными репозиториями в документации по Git.
Вообще говоря, git позволяет работать и в полной децентрализации, но это в общем случае менее удобно.
Так вот. Самое простое — воспользуйтесь услугами Github, хранить у них репозитории получается надёжно и недорого.
Или, если вы готовы сами отвечать за резервирование и прочее, то разместите так называемый bare-репозиторий прямо у себя же на сервере.
На практике последовательность действий, которые вам нужно совершить, описана здесь.
Вкратце — создаёте bare-репозиторий, загружаете на сервер, и указываете его адрес в качестве origin у себя в локальном репозитории (а также в любых других местах, где есть этот репозиторий — например, у вас же на сервере):
Кроме того, тот же самый адрес репозитория можно использовать для того, чтобы клонировать его на других компьютерах:
При этом remote при клонировании выставляется автоматически.
А вообще, настоятельно рекомендую прочитать документацию по git, прогуглить интересующие вопросы, пройти вот такое короткое введение, и, поверьте, станет резко проще и понятнее.
update my repository on github
I just went up to github the project that was working locally on my computer. everything went well and I could upload all my files .. now I would like to know how I can update my repository if I make some changes to my project locally try the following commands:
I think I’m forgetting something, or I’m using the commands incorrectly, what would be the correct way?
2 Answers 2
Your work flow for ensuring that your changes are added correctly to your remote github repo in «normal» cases should follow these stages ..
Will always tell you what is uncommitted and what needs to be «added» (staged) for committing to your local repo. In fact git will hint to you what it thinks is the next step in your work flow
Works in Windows if use the Windows git-bash.exe It uses mingW64 emulator to simulate linux environment. It’s very good at it.
You need to commit whatever changes yout want to keep — locally before you can «push» your changes to your github repo remotely ie only after you have told git where your remote git repo is .
Usually the default name for your remote repo on github is given as «origin». But I have been using specific alias branch names which in your case is «myGitHubOrBitBucketRepo»
This command will push your committed changes (aka snap shots in git speak) to YourGitAppRepo.git on github.com onto the master branch and if master on your remote repo is not ahead of your local branch and it is just a couple of commits behind — github.com will accept this push
The -u is the same as —track which means that your local branch positioned @ HEAD will be tracking the master branch at your remote alias myGitHubOrBitBucketRep
In steps 4 & 5 you will have to use a userId and passWord to interact with your remote repo on GitHub.com
From now on git status will actually tell you whether you are behind or ahead of your remote github repo because of the —track (ing) option you had done in your push
Another useful command to use from this point onwards will be
Over here bitbucketFrmWin is my alias for my remote bitbucket repo AsOf16Jan2018 is a branch that I am no longer interested master is my current main branch which I push my changes to from my local repo.
The —all option will also display your local & your «remotes»
Of note is the following * CurrAsOf18Jan2018 50d1fc6 [remotes/bitbucketFrmWin/master: behind 5]
The asterik * that is the HEAD of my local branch or at which commit on that branch I am on. Usually it is always at the tip or the HEAD i.e. why it is called the «head»
CurrAsOf18Jan2018 is my local main branch and importantly it is saying that my local is already ahead of my remote branch by 5 commits — it is out of date so I need to update my remote with a «git push»
For now that is just one side of this story. If your remote repo goes ahead then another work-flow would be
That is altogether another post.
And here is a succinct image which I found courtesy Oliver Steele that displays another version of the basic git workflow life-cycle of versioning 