Руководство по ci/cd в gitlab для (почти) абсолютного новичка

Исходная позиция: что имеется и чего хочется

Имеем:

Хотим:

• автоматическую сборку и тестирование для каждого merge request,
• сборку пакетов для каждого merge request и пуша в мастер при условии наличия в сообщении коммита определённой строки,
• отправку собранных пакетов в приватный фид в Azure DevOps,
• сборку документации и публикацию в GitLab Pages,
• бейджики!11

Описанные требования органично ложатся на следующую модель пайплайна:

• Этап 1 — сборка
• Этап 2 — тестирование
• Этап 3 — отправка
  • Задача 1 — собираем nuget-пакет и отправляем в Azure DevOps
  • Задача 2 — собираем сайт из xmldoc в исходном коде и публикуем в GitLab Pages

Приступим!

Шаг 1: Зарегистрируйтесь и установите!

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

Теперь зайдите в свой терминал и представьтесь Git! Чтобы установить ваше имя пользователя длякаждый репозиторийна вашем компьютере введите

git config --global user.name "<your_name_here>"

заменяя «»С вашим собственным именем в цитатах. Вы можете использовать любое имя или ручку, которую хотите. Если вы хотите установить свое имя только для одного хранилища, оставьте слово «глобальный» »

Теперь вы можете указать Git свой адрес электронной почты и убедиться, что это тот же адрес электронной почты, который вы использовали при регистрации в GitHub.

git config --global user.email "<>"

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

Теперь вы готовы начать использовать Git на своем компьютере!

фотоМэтти АдамнаUnsplash

Для начала вы можете создать новый репозиторий на сайте GitHub или выполнитьсоздать новый репозиторий из каталога вашего проекта.

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

Совмещение веток

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

Слияние

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

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

После открытия таких файлов вы увидите похожие маркеры разрешения конфликта:

Замените в этом блоке всё на версию, которую вы хотите оставить, и подготовьте файл. После разрешения всех конфликтов можно использовать для завершения слияния.

Перемещение

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

Для перемещения используется команда , которая воспроизводит изменения тематической ветки на основной; HEAD тематической ветки указывает на последний воспроизведённый коммит.

Перемещение vs. слияние

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

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

Представим сценарий:

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

Поэтому вот совет:

Перемещайте изменения только на вашей приватной локальной ветке — не перемещайте коммиты, от которых зависит ещё кто-то.

Откат коммитов — revert и reset

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

Важно отметить, что это также означает, что вы больше не сможете вернуться обратно к этим изменениям, например, если вы всё-таки решите, что отмена коммита была лишней. Чище — не значит лучше!

Видео

Install Git on Mac

Most versions of MacOS will already have installed, and you can activate it through the terminal with . However, if you don’t have Git installed for whatever reason, you can install the latest version of Git using one of several popular methods as listed below:

Install Git From an Installer

1. Navigate to the latest macOS Git Installer and download the latest version.
2. Once the installer has started, follow the instructions as provided until the installation is complete.
3. Open the command prompt «terminal» and type to verify Git was installed.

Note: is a popular and recommended resource for downloading Git on a Mac. The advantage of downloading Git from is that your download automatically starts with the latest version of Git. The download source is the same macOS Git Installer as referenced in the steps above.

Install Git from Homebrew

Homebrew is a popular package manager for macOS. If you already have Homwbrew installed, you can follow the below steps to install Git:

1. Open up a terminal window and install Git using the following command: .
2. Once the command output has completed, you can verify the installation by typing: .

Коммиты

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

Команда откроет текстовый редактор для ввода сообщения коммита. Также эта команда принимает несколько распространённых аргументов:

• позволяет написать сообщение вместе с командой, не открывая редактор. Например ;
• переносит все отслеживаемые файлы в область подготовленных файлов и включает их в коммит (позволяет пропустить перед коммитом);
• заменяет последний коммит новым изменённым коммитом, что бывает полезно, если вы неправильно набрали сообщение последнего коммита или забыли включить в него какие-то файлы.

Несколько советов, к которым стоит прислушаться:

• Коммитьте часто: вы не сможете откатить изменения, если откатывать не к чему.
• Одно изменение — один коммит: не помещайте все не связанные между собой изменения в один коммит, разделите их, чтобы было проще откатиться.
• Формат сообщений: заголовок должен быть в повелительном наклонении, меньше 50 символов в длину и должен логически дополнять фразу (this commit will fix bugs — этот коммит исправит баги). Сообщение должно пояснять, почему был сделан коммит, а сам коммит показывает, что изменилось. Здесь подробно расписано, как писать сообщения для коммитов.
• (Опционально) Не коммитьте незначительные изменения: в большом репозитории множество небольших коммитов могут засорить историю. Хорошим тоном считается делать такие коммиты при разработке, а при добавлении в большой репозиторий объединять их в один коммит.

Ветвление

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

Это ведёт нас к ключевой особенности Git — ветвлению, возможности работать над разными версиями проекта. Это значит, что вместо одного списка с упорядоченными коммитами история будет расходиться в определённых точках (что делает её похожей на дерево). Каждая ветвь в Git содержит легковесный указатель HEAD на последний коммит в этой ветке, что позволяет без лишних затрат создать много веток. Совет: называйте ветку в соответствии с разрабатываемой в ней функциональностью. Ветка по умолчанию называется master.

Итак, у нас есть общий указатель HEAD и HEAD для каждой ветки. Таким образом, переключение между ветками предполагает только перемещение HEAD в HEAD соответствующей ветки.

Стандартные команды:

• — создаёт новую ветку с HEAD, указывающим на HEAD. Если не передать аргумент , то команда выведет список всех локальных веток;
• — переключается на эту ветку. Можно передать опцию , чтобы создать новую ветку перед переключением;
• — удаляет ветку.

Как наш локальный репозиторий, так и удалённый, могут иметь множество ветвей, поэтому когда вы отслеживаете удалённый репозиторий, на самом деле отслеживается удалённая ветка ( привязывает вашу ветку master к ветке origin/master удалённого репозитория).

Привязывание к удалённой ветке:

• — привязывает текущую ветку к указанной удалённой ветке;
• — аналог предыдущей команды;
• — создаёт новую локальную ветку и начинает отслеживать удалённую;
• — показывает локальные и отслеживаемые удалённые ветки;
• — создаёт локальную ветку с таким же именем, как у удалённой, и начинает её отслеживать.

В общем, связан с изменением места, на которое указывает HEAD ветки, что похоже на то, как перемещает общий HEAD.

Прятки и чистка

Есть одна тонкость — при переключении веток Git требует, чтобы рабочее состояние было чистым, то есть все изменения в отслеживаемых файлах должны быть зафиксированы.

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

Однако порой у вас есть незавершённые изменения, которые нельзя фиксировать. В такой ситуации их можно сохранить и «спрятать» с помощью команды . Чтобы вернуть изменения, используйте .

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

Ummmmm … что? Могу ли я сделать это на сайте?

Вы можете!

GIF черезGIPHY

Один из способов сделать это — просто проверить кнопку, о которой мы упоминали ранее, когда редактировали файл README. Супер просто!

Вы также можете в любое время создать новую ветку прямо на веб-сайте, перейдя в свой репозиторий, щелкнув раскрывающееся меню в левой и средней части экрана с надписью «Branch: master», введя имя ветви и выбрав Ссылка «Создать ветку» (или нажмите Enter на клавиатуре). Теперь у вас есть две ветви, которые выглядят одинаково! Это отличное место для внесения изменений и их тестирования, прежде чем вы захотите, чтобы они повлияли на основную ветку.

Создание ветки

Если вы работаете с отдельной веткой, ваши изменения влияют только на эту ветку.

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

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

• Нажмите вкладку запроса на извлечение рядом с верхним центром экрана.
• Нажмите зеленую кнопку «Новый запрос на извлечение»
• Перейдите в поле «Примеры сравнений» и выберите ветку, которую вы сделали, чтобы сравнить с исходной веткой.
• Посмотрите свои изменения, чтобы убедиться, что они действительно то, что вы хотите зафиксировать.
• Затем нажмите большую зеленую кнопку «Создать запрос на извлечение». Дайте ему название и напишите краткое описание ваших изменений. Затем нажмите «Создать запрос на извлечение!»

Новый запрос на извлечение
Создать пул-запрос

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

Если вы участвуете в проекте, у людей в команде (или у рецензента) могут возникнуть вопросы или комментарии. Если вам нужно что-то изменить, это время! Если все хорошо, они могут развернуть изменения прямо из ветки для окончательного тестирования перед тем, как объединить их. И вы можете развернуть свои изменения, чтобы проверить их в производстве.

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

GitOps — плохой и злой

Перевод

Эксперт OTUS — Владимир Дроздецкий приглашает всех желающих на бесплатный вебинар, в рамках которого он подробно расскажет о программе курса «DevOps практики и инструменты» и ответит на интересующие вопросы. А прямо сейчас, по устоявшейся традиции, делимся с вами интересным переводом.

Недавно я общался с разработчиками из Humanitec (это Continuous Delivery-платформа для Kubernetes). Humanitec интересен тем, что вопреки современным тенденциям, он не основан на GitOps.

Лично я большой фанат GitOps, потому что он позволяет строить CI/CD без сложных инструментов с использованием только Git и декларативного описания конфигураций. Но несмотря на то, что я недавно написал статью «11 Reasons for Adopting GitOps» (11 причин для внедрения GitOps), в своей практике я неоднократно сталкиваюсь с ограничениями этого подхода. Беседа с ребятами из Humanitec побудила меня написать об этом негативном опыте для того, чтобы предоставить вам более объективную картину GitOps и поговорить об альтернативных подходах.

Я не знаю, что вы только что сказали (Вариант 2)

Я собираюсь предположить, что любой, кто интересуется вариантом 2, является новичком во всем этом и, возможно, имеет папку, полную файлов (или вы планируете иметь один), который вы хотите поместить на GitHub, и вы просто не знаете как это сделать.

Давайте сделаем это!

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

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

Это хорошая идея, чтобы включитьПРОЧТИ МЕНЯфайл с информацией о вашем проекте. Вы можете создать один в то же время, когда вы создаете свой репозиторий, щелкнув флажок.

• Перейдите на веб-сайт GitHub, посмотрите в верхнем правом углу, нажмите знак +, а затем нажмите «Новый репозиторий».
• Назовите репозиторий и добавьте краткое описание.
• Решите, хотите ли вы, чтобы это был публичный или частный репозиторий
• Нажмите «Инициализировать этот репозиторий с помощью README», если вы хотите включить файл README. (Я определенно рекомендую сделать это! Это первое, на что люди обратятся, когда проверят ваш репозиторий. Это также отличное место для размещения информации, которая вам необходима, чтобы понять или запустить проект.)

Новый репозиторий
Создание вашего нового хранилища

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

Есть два способа внести изменения в ваш проект. Вы можете вносить изменения в свои файлы / записные книжки на своем компьютере, а также вносить изменения прямо на GitHub.

Допустим, вы хотите внести некоторые изменения в свой файл README прямо на GitHub.

• Сначала зайдите в свой репозиторий.
• Нажмите на имя файла, чтобы вызвать этот файл (например, нажмите «README.md», чтобы перейти к файлу readme).
• Нажмите значок карандаша в верхнем правом углу файла и внесите некоторые изменения.
• Напишите короткое сообщение в поле, которое описывает сделанные вами изменения (и расширенное описание, если хотите).
• Нажмите кнопку «Подтвердить изменения»

Редактирование вашего файла на GitHub
Передача ваших изменений

Теперь изменения были внесены в файл README в вашем новом хранилище! (Я хочу обратить ваше внимание на маленькую кнопку, которую вы можете отметить на изображении выше, которая позволит вам создать новую ветку для этого коммита и запустить запрос на извлечение. Мы поговорим об этом позже!). Довольно легко, правда?

Довольно легко, правда?

Я предпочитаю работать с файлами на своем локальном компьютере, а не пытаться заставить все работать с веб-сайта GitHub, поэтому давайте настроим это сейчас.

Install Git on Windows

1. Navigate to the latest Git for Windows installer and download the latest version.
2. Once the installer has started, follow the instructions as provided in the Git Setup wizard screen until the installation is complete.
3. Open the windows command prompt (or Git Bash if you selected not to use the standard Git Windows Command Prompt during the Git installation).
4. Type to verify Git was installed.

Note: is a popular and recommended resource for downloading Git for Windows. The advantage of downloading Git from is that your download automatically starts with the latest version of Git included with the recommended command prompt, . The download source is the same Git for Windows installer as referenced in the steps above.

Устанавливаем SSH-ключи

Git установлен, профиль на GitHub создан. Осталось добавить SSH-ключ и можно приступать к работе с проектом.

Что такое SSH-ключ и зачем он нужен?

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

Каждый SSH-ключ содержит пару: открытый (публичный) и закрытый (приватный) ключ. Открытый ключ отправляется на сервер, его можно не прятать от всех и не переживать, что кто-то его увидит и украдёт. Он бесполезен без своей пары — закрытого ключа. А вот закрытый ключ — секретная часть. Доступ к нему должен быть только у вас.

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

Чтобы пройти авторизацию по SSH-ключу, его надо сгенерировать или найти уже ранее созданный ключ на своём компьютере.

Сначала проверим, есть ли уже на компьютере ключ. По умолчанию SSH-ключи хранятся в каталоге , поэтому нужно проверить содержимое этого каталога.

1. Открываем консоль.

2. Вводим , чтобы перейти в нужный каталог.

   Переходим в нужную директорию.

3. Используем , чтобы увидеть список всех файлов в каталоге.

   Открываем список файлов в директории.

   Ищем пару файлов с названиями вида и . Обычно имя — , , или . Файл с расширением — ваш публичный ключ, а второй — ваш приватный, секретный ключ.
   Если таких файлов или даже каталога у вас нет, вы можете их сгенерировать. Для этого делаем следующее.

   • Открываем консоль и вводим команду:

     ssh-keygen -t rsa -b 4096 -C "your_mail@example.com"

     Указываем тот адрес электронной почты, который вводили при регистрации на GitHub.

     Генерируем ключ.

   • Далее нужно указать расположение файла для сохранения ключа. Если вы не введёте путь до файла и просто нажмёте Enter, ключ сохранится в файле, указанном в скобках.

   • Теперь нужно установить пароль к вашему ключу и дважды ввести его. Если вы не хотите вводить пароль каждый раз, когда используете ключ, пропустите этот шаг, нажав «Enter», и ничего не вводите.

     Указываем расположение ключа и вводим пароль.

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

   Добавляем ключ в shh-agent. Несколько важных примечаний:

   • Если вы захотите переименовать ключ, могут возникнуть проблемы. Их можно решить, добавив в связь ключа с доменом.
   • Если у вас Windows и вы пользуетесь программой Cmder, возможны проблемы с командой . Может появиться такое сообщение об ошибке:
     «eval не является внутренней или внешней командой, исполняемой программой или пакетным файлом».

     В Сmder для запуска можно использовать команду .

     Если проблема осталась, рекомендуем работать в Git Bash.

   • Если у вас macOS Sierra версии 10.12.2 и выше, нужно изменить ваш файл, чтобы автоматически загрузить ключи в и хранить пароли.

     Host *
      AddKeysToAgent yes
      UseKeychain yes
      IdentityFile ~/.ssh/id_rsa

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

   • Если у вас Linux, может понадобится переназначить для ~/.ssh права доступа командой
5. После того как создан ключ, его нужно добавить на GitHub. Для этого копируем его содержимое с помощью одной из следующих команд:
   • Если вы на Windows
   • Для пользователей macOS
   • На Linux используйте , чтобы установить необходимый для копирования пакет , а затем введите

   Можно пойти другим путём, открыть файл прямо в папке и просто скопировать содержимое оттуда.

6. Переходим на страницу для работы с ключами в вашем профиле на GitHub.

   Страница с настройками ключей в вашем профиле.

   Нажимаем кнопку New SSH key (новый SSH-ключ). Вводим имя ключа (можно придумать абсолютно любое) в поле Title (название), а в Key (ключ) вставляем сам ключ из буфера обмена. Теперь нажимаем Add SSH key (добавить SSH-ключ).

   Добавляем в свой профиль SSH-ключ.

   Если всё сделано верно, в списке появится новый ключ.

   Успешно добавленный ключ.

Теперь, наконец-то, мы можем начать работу с самим проектом.

Автоматизация миграций баз данных с помощью контейнеров и Git

Перевод

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

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

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

Эта статья берет за основу SQL Server, но эти методы также поддерживаются Postgres и MySQL.

Используйте временные коммиты вместо stash при переходе между ветками

Скорее всего, Вы сталкивались хотя бы раз с ситуацией, когда надо срочно переключиться с одной ветки на другую, бросив всё в разобранном состоянии. Очень вероятно, что Вы знаете про (от англ. «тайник»), который позволяет «спрятать» Ваши текущие изменения. Однако во время его использования Вы можете столкнуться со следующими вещами:

• Если коммитами Вы пользуетесь постоянно и все часто встречающиеся параметры типа можете написать с закрытыми глазами, имеет несколько перпендикулярный интерфейс. Чтобы сохранить его надо сделать (при этом может быть опущен). А чтобы восстановить — есть (применяет последний стеш из всех) и (применяет стеш и удаляет его из стека). Соответственно, когда придёт внезапная необходимость переключиться, Вы можете не сразу вспомнить, а что собственно надо вводить и что от команды ожидать.
• Если -ить буквально пару строчек, то можно вообще не вспомнить, что делал , и потом сидишь и удивляешься, куда делись изменения.
• по умолчанию распространяется только на изменённые (modified) файлы и не включает в себя неотслеживаемые (untracked). Соответственно, не зная этого, при переключении веток можно потерять их, если, например, они авто-генерируемые.

Что же делать, если не ? Наиболее простое решение — взять и закоммитить всё с комментарием (распространённая аббревиатура от «Work In Progress»). Не надо морочить себе голову, вспоминать названия команд и искать потом, в который из стешей сохранены изменения.

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

Как пользоваться Git?

Дальше я буду предполагать, что вы выполнили установку и базовую настройку git. Кроме установки, вам нужно указать правильный адрес электронной почты и имя пользователя для доступа к серверу Git, например, на GitHub. Если вы этого еще не сделали смотрите инструкцию установка Git в Ubuntu 16.04.

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

Создание проекта

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

Эта команда создаст нужную структуру папок и переводит текущий каталог в только что созданный. Теперь создадим первый файл нашего проекта:

Проект готов, но система контроля версий git еще не знает об этом.

Настройка проекта в git

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

После того как репозиторий будет создан, вам нужно добавить свои файлы в него. Каждый файл нужно добавлять отдельно или сказать утилите, что необходимо добавить все файлы явно. Пока вы не добавите файл сам он не будет отслеживаться. Новые файлы в будущем тоже нужно добавлять, они не добавляются автоматически.  Сначала добавим текущую папку:

Если все прошло хорошо, то команда ничего не выведет.

Фиксация изменений

Изменения тоже автоматически не отслеживаются. Фиксация изменений выполняется с помощью команды commit. Вам нужно указать что было изменено с помощью небольшого комментария, буквально в несколько предложений. Хорошая практика выполнять фиксацию перед каждым серьезным изменением.

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

Команде необходимо передать два параметра, первый — это -m, ваш комментарий, второй -a, означает, что нужно применить действие ко всем измененным файлам. Для первого раза используется этот параметр, но обычно вам нужно указать измененные файлы или каталоги. Например, можно делать так:

Отправка изменений

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

Сначала нужно добавить удаленный репозиторий с помощью команды remote. Для этого нужно передать ей URL:

Затем можно посмотреть список удаленных репозиториев:

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

Команда push указывает, что нужно отправить данные в удаленный репозиторий, origin — наш настроенный репозиторий, а master — ветвь.

Управление ветвями

Для простых проектов достаточно одной ветви. Но если проект большой и он имеет несколько версий, в том числе тестовую, то может понадобиться создать для каждой из них отдельную ветвь. Сначала смотрим доступные ветви:

Опция -a указывает что нужно вывести все ветви, даже не синхронизированные. Звездочка указывает на активную ветвь. Теперь создадим ветвь для разработки с помощью команды checkout:

Переключаться между ветвями можно тоже с помощью той же команды:

Теперь создадим еще один файл:

И добавим его в нашу новую ветвь develop:

Сделаем коммит для внесенных изменений:

Дальше проверим существует ли этот файл в основной ветке master или только в дополнительной. Смотрим текущую ветку:

Затем переключаемся на ветку master и снова смотрим:

Здесь файла нет, так и должно быть. В git есть такая полезная вещь, как слияние. С помощью нее вы можете объединить две ветви. Например, переместить код из рабочей ветки в стабильную. Для этого достаточно выполнить команду merge:

Перед тем как будет выполнено слияние вам нужно ввести комментарий, зачем это нужно. Затем если вы еще раз выполните ls, то увидите, что здесь уже есть нужный файл. Наши примеры git подошли к концу.

Why Use Git?

Version control is very important — without it, you risk losing your work. With Git, you can make a «commit», or a save point, as often as you’d like. You can also go back to previous commits. This takes the pressure off of you while you’re working. Commit often and commit early, and you’ll never have that gut sinking feeling of overwriting or losing changes.

There are many version control systems out there — but Git has some major advantages.

Merge conflicts

Git can handle merge conflicts, which mean that it’s OK for multiple people to work on the same file at the same time. This opens up the world of development in a way that isn’t possible with centralized version control. You have access to the entire project, and if you’re working on a branch, you can do whatever you need to and know that your changes are safe.

Cheap branches

Speaking of branches, Git offers a lot of flexibility and opportunity for collaboration with branches. By using branches, developers can make changes in a safe sandbox.

Instead of only committing code that is 100% sure to succeed, developers can commit code that might still need help. Then, they can push that code to the remote and get fast feedback from integrated tests or peer review.

Without sharing the code through branches, this would never be possible.

Ease of roll back

If you make a mistake, it’s OK! Commits are immutable, meaning they can’t be changed. (Note: You can change history, but it will create new replacement commits instead of editing the existing commits. More on that later!) This means that if you do make a mistake, even on an important branch like master, it’s OK. You can easily revert that change, or roll back the branch pointer to the commit where everything was fine.

The benefits of this can’t be overstated. Not only does it create a safer environment for the project and code, but it fosters a development environment where developers can be braver, trusting that Git has their back.

How to Use Git

Learning & Mastering Git Commands

If you’re getting started with Git, a great place to start is the Git Cheat sheet. It’s translated into many languages, open source as a part of the repository, and a great starting place for the fundamentals on the command line.

Some of the most important and most used commands that you’ll find there are:

• : Clone (download) a repository that already exists on GitHub, including all of the files, branches, and commits.
• : Always a good idea, this command shows you what branch you’re on, what files are in the working or staging directory, and any other important information.
• : This shows the existing branches in your local repository. You can also use to create a branch from your current location, or to see all branches, both the local ones on your machine, and the remote tracking branches stored from the last or from the remote.
• : Switches to the specified branch and updates the working directory.
• : Snapshots the file in preparation for versioning, adding it to the staging area.
• : Records file snapshots permanently in version history.
• : Updates your current local working branch with all new commits from the corresponding remote branch on GitHub. is a combination of and .
• : Uploads all local branch commits to the remote.
• : Browse and inspect the evolution of project files.
• : Show the associated remote repositories and their stored name, like .

Getting Started With GitHub

If you’re wondering where Git ends and GitHub begins, you’re not alone. They are tied closely together to make working with them both a seamless experience. While Git takes care of the underlying version control, GitHub is the collaboration platform built on top of it. GitHub is the place for pull requests, comments, reviews, integrated tests, and so much more. Most developers work locally to develop, and use GitHub for collaboration. That ranges from using GitHub to host the shared remote repository, to working with colleagues and capitalizing on features like protected branches, code review, GitHub Actions, and more.

The best place to practice using Git and GitHub is the Introduction to GitHub Learning Lab course.

If you already know Git and need to sign up for a GitHub account, head over to github.com.

Contribute to this article on GitHub.