Как пользоваться github и зачем заливать туда it-проекты?

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

Перевод

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

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

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

Reset или не reset?

resetresetreset

Делаем hard reset

resetcheckoutreset —softreset -hard

git stash

1. Он сохраняет вашу работу в хранилище (stash), откуда вы можете забрать ее назад в любой момент. Заметьте, что это хранилище не привязано к конкретной ветке, так что вы можете сохранить состояние вашего рабочего дерева в одной ветке, а позже наложить отличия на другую ветку.
2. Stash возвращает ваше дерево в прошлое состояние, но в новой ветке. Так то если вы решите сделать коммит с вашими изменениями по сравнению с прошлым состоянием, вы не измените вашу оригинальную ветку.

reset —softreset —hardreset -hard

stashreset -hardstash

Сотрудничество

В классических хранилищах исходного кода всегда есть четкое указание на то, что это за ветвь; она находится в центральном репозитории.

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

Рисунок 10. Два репозитория

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

При выгрузке ветви, которая существует только как ветвь дистанционного отслеживания (но не как локальная ветвь), Git автоматически создает локальную ветвь из ветви дистанционного отслеживания и выгружает ее.

После этого можно объединить содержимое удаленной ветви и своей собственной. На рисунке 11 показан процесс выгрузки удаленной ветви в локальную ветвь master, но это не обязательно, ее можно слить с любой другой ветвью с общей историей, например, с помощью обычной команды merge.

Рисунок 11. Извлечение и выгрузка удаленной ветви

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

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

Рисунок 12. Получение удаленных изменений

На рисунке 12 показано действие команды ; она обновляет ветвь дистанционного отслеживания. Затем просто выполняется обычная операция слияния между ветвью дистанционного отслеживания и локальной ветвью, в данном примере – . После копирования имя можно использовать в команде слияния в качестве ярлыка скопированной удаленной ветви, например, . Кроме того, как говорилось выше, это слияние может привести к быстрому прямому слиянию, бесконфликтному слиянию или к конфликту, который нужно разрешить вручную.

Команда удобна тем, что выполняет оба действия и .

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

Рисунок 13. Публикация изменения

Существует одно условие. Это срабатывает только в том случае, если операция push приведет к быстрому прямому слиянию с удаленной ветвью в удаленном репозитории. В противном случае в удаленной ветви уже есть другие изменения (коммиты) из других репозиториев или от других коммиттеров. Тогда Git прерывает операцию push и оставляет все как есть. Затем нужно извлечь изменения, объединить их со своей локальной ветвью и повторить попытку публикации.

Обратите внимание, что в таких случаях можно выполнить обычное слияние, а можно – слияние со смещением для переноса изменений из локальной ветви в новую, отредактированную вершину удаленной ветви. Помимо команд fetch и push, есть еще один способ распространения изменений; старая добрая почта

Существует команда , которая создаёт файл изменений для каждого коммита, ведущий от данного коммита к текущему состоянию ветви. Команда применяет эти файлы изменений к текущей ветви

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

Предостережения

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

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

Что такое Git?

Git — система контроля версий (version control system, VCS), созданная программистом Линусом Торвальдсом для управления разработкой ядра Linux в 2005 году. Хорошо, а что это всё-таки значит?

Представьте, что вы с коллегами вместе пишете ядро Linuxнаучную статью. У вас на компьютере есть папка, где лежат текстовые документы, картинки, графики и прочие нужные файлы; то же самое есть и у ваших коллег. Когда кто-то из вас изменяет, добавляет или удаляет файлы, остальные этих изменений не видят. Вы пишете друг другу об изменениях, пересылаете обновленные версии файлов, но в процессе работы непременно возникает путаница: какая версия текста — последняя? Куда и когда исчезла пара абзацев? Кто внес те или иные правки? Избежать таких проблем и помогают системы контроля версий. Устроено это так:

• Ваша папка на компьютере — это не просто папка, а локальный репозиторий.
• Она является копией удалённого репозитория, который лежит на веб-хостинге (например, GitHub или BitBucket).
• Eсли вы работаете над проектом с коллегами, то своя локальная копия есть у каждого.
• Kогда вы внесли некоторое количество изменений, вы можете их сохранить, и это действие запишется в журнал; это называется commit (коммит).
• После этого можно отправить изменения в удалённый репозиторий; это называется push (пуш, пу́шить, запу́шу, пуши́ от души).
• Актуальная версия проекта, учитывающая последние изменения всех участников, будет храниться в удалённом репозитории.
• Если вы увидели, что ваши коллеги запушили в удалённый репозиторий что-то новенькое, то можно (и нужно!) “скопировать” это себе на компьютер (в локальный репозиторий); это называется pull (пулл).

Чем-то похоже на Dropbox, Google Drive и прочие облачные хранилища, правда? Только в данном случае ваши файлы синхронизируются не автоматически, а по команде, и возможностей управления ими гораздо больше.

Понятно, что для совместной работы над текстом научной статьи вполне хватит и Google Docs, но вот если, например, вы хотите опубликовать результаты исследования в интернете и сделать для этого собственный сайт, то без VCS обойтись сложно. И ещё раз, системы контроля версий хороши тем, что:

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

Существует много систем управления версиями, но мы будем пользоваться самой распространенной — git. Также нам нужно как-то отдавать гиту команды, и делать это можно двумя способами: с помощью командной строки и через графический интерфейс (graphical user interface, GUI). Графический интерфейс программы — это все те окошки с кнопочками, которые мы привыкли видеть. Существует много графических интерфейсов для Git, например:

• TortoiseGit
• GitKraken
• GitHub Desktop
• Fork
• Git GUI
• Git Extensions
• SourceTree

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

Итого:

• Git — разновидность системы контроля версий (самая популярная). Его можно скачать и установить, далее использовать через командную строку.
• Можно использовать графический интерфейс для работы с Git. При этом скачивать и устанавливать сам Git отдельно не нужно, он обычно идет в комплекте с графическим интерфейсом (но не во всех GUI).
• Репозиторий — это место где мы храним наш код проекта и всю информацию по файлам, их изменения и т.д. Репозиторий должен где-то хранится, чтобы у всех был доступ к нему и они могли видеть изменения. Его можно хранить и на домашнем компьютере, но не всегда удобно держать компьютер включенным целыми сутками, поэтому используют хостинги для репозиториев. Одними из самых известных являются GitHub и GitLab.

Продвинутое использование: правим историю

Для большего контроля над историей коммитов локальной ветки можно использовать команду , которая откроет интерактивную консоль для перемещения набора последних n коммитов, перечисленных в порядке от старых к новым (то есть в том порядке, в котором они будут перемещены). Таким образом вы можете «редактировать историю», однако помните, что оригинальные коммиты нельзя изменить, только переместить.

Вы можете поменять порядок коммитов, изменив порядок, в котором они перечислены.

Измененяем сообщение коммита/разбиваем коммиты

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

После завершения редактирования введите .

Перезапись нескольких коммитов

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

Объединение нескольких коммитов

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

Переносим отдельный коммит

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

Обратите внимание, что таким образом создаётся новый коммит, который только повторяет diff выбранного коммита (то есть разницу между этим коммитом и предыдущим), но не его состояние

Шаг 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 или выполнитьсоздать новый репозиторий из каталога вашего проекта.

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

Рекомендуемые записи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как отменить commit и не облажаться

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

Возьмем простую ситуацию: разработчик решает реализовать математические функции. Но на половине пути понимает, что данную задачу было бы хорошо декомпозировать, допустим, на две подзадачи:

• Реализовать арифметические операции (сложение, вычитание, деление и т.д.)
• Реализовать числовые операции (максимальное значение, минимальное значение, модуль числа и т.д.)

Проверять будет проще да и тестировать. Но он уже начал ее реализовывать, коммиты уже созданы, и что же делать? Не переписывать же!

Шаг 5. Выбираем Гит-клиент

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

Но вернёмся к git-клиентам.

Самыми популярными гит- клиентами на данный момент являются:

SmartGit

Удобное  приложение гармонично сочетает все необходимые функции и доступную интуитивно понятную систему управления. SmartGit – один из самых удобных графических интерфейсов для профессиональной разработки. Некоммерческая разработка и разработка open-sourse проектов не требуют платной лицензии.

GitHub Desktop

«Родной» графический интерфейс Гитхаба. GitHub Desktop работает под Windows и Mac и практически полностью копирует функционал основного сайта. Работает под той же учётной записью.
Правда, не всегда оперативно справляется с большими программами.

Зато отлично подходит для начала работы с git.

GitKraken

Поддерживает GitHub, Bitbucket и Gitlab.
Кракен очень любят программисты – фрилансеры, которым периодически приходится менять команды, а значит, и условия командной разработки. Возможность работы с разными git-хостингами через привычное приложение со знакомым интерфейсом в таких случаях играет важную роль.

SourceTree

SourceTree позволяет работать с Bitbucket и GitHub. В приложении довольно простой интерфейс, подходящий, как для опытных программистов, так и для новичков.

Как пользоваться 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 подошли к концу.

Устанавливаем 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-ключ.

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

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

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

Отслеживайте хаки локальные изменения в обход репозитория

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

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

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

Что только что сейчас произошло? Мистическим образом у нас оказалось два репозитория в одной папке, а значит и возможность вести параллельную историю файлов! Почему ? Да для единообразия. Давайте заведём себе алиас, чтобы упростить работу со вторым репозиторием:

Пробуем:

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

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

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

Видео