Руководство по github на русском

Skip to main content

Skip to main content

Из этой статьи вы узнаете

• Зачем нужны системы контроля версий

• Откуда взялся Git

• Как создать свой репозиторий на GitHub и внести в него изменения

• Что такое fork, branch и другие интересные слова из мира Git

• Как создать свой Pull Request

Вступление

Бывает, что начинающие разработчики проблематично осваивают Git и не с первого захода понимают логику работы сервиса. Но стоит создать пару репозиториев или, ещё лучше, погрузиться в реальную историю по установке стартапа на рельсы DevOps, как работа с ветками станет дружелюбной, а PR и MR больше не вызовут путаницы. Ошибки в любом случае появятся, но вы будете к ним готовы!

Начало

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

Первое и самое просто решение — «А давайте перед каждым изменением сохранять копию программы (просто копировать папку с кодом)?»

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

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

Про Git

Существует несколько систем контроля версий: Git, Subversion, Team Foundation Server, Mercurial. Сегодня познакомимся с Git — самой популярной из них, по скромному признанию более 90% разработчиков.

Git появился 7 апреля 2005 года и был создан для управления разработкой ядра Linux. Кстати, создал его тот самый Линус Торвальдс, а сегодня его развитием и поддержкой занимается Дзюн Хамано.

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

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

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

GitHub — крупнейший веб-сервис, который позволяет заниматься совместной разработкой с использованием Git и сохранять изменения на своих серверах. На самом деле функциональность GitHub намного больше, но сейчас нас интересует только совместная разработка и история изменений. Ещё есть Gitlab, Bitbucket и другие, но мы будем использовать GitHub как самый популярный в настоящее время.

Предварительная настройка

Займёмся предполётной подготовкой.

Для начала зарегистрируйтесь на GitHub: задайте логин, почту и придумайте пароль. После «Создать аккаунт» не забудьте проверить почту и подтвердить её (опрос от Github после подтверждения почты можно пропустить).

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

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

GitHub поддерживает безопасность за счёт двух сетевых протоколов, HTTPS и SSH, и вся работа с сервисом происходит через один из них.

Работать с GitHub будем через терминал по SSH. Для этого один раз сгенерируем специальные ключи и добавим один из них в наш аккаунт на GitHub.

Можно работать и через HTTPS, но нужно будет каждый раз вводить пароль и специальный token.

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

При подключении используется пара ключей — открытый (публичный, public) и закрытый (приватный, private). Пользователь создаёт пару ключей при помощи специальной команды и сохраняет закрытый ключ у себя, а открытый кладёт на сервер (в нашем случае на GitHub). А работает это всё благодаря асимметричному шифрованию.

Алгоритм следующий: отправитель (GitHub) шифрует сообщение публичным ключом и передаёт сообщение клиенту (нам), а мы его расшифровываем при помощи приватного ключа, который предусмотрительно сохранили у себя. То, что зашифровано публичным ключом, расшифровать сможет только приватный ключ.

Давайте создадим пару ключей и добавим открытый ключ на GitHub.

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

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

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

$ ssh-keygen
Generating public/private rsa key pair.
# путь до ключей, в скобках путь по умолчанию
Enter file in which to save the key (/Users/ifireice/.ssh/id_rsa):  
# пароль для ключей, при задании пароля в консоли не отображается ничего, даже звёздочки
# если нажать Enter, ничего не вводя, пароль будет пустым
Enter passphrase (empty for no passphrase):
# повторите пароль
Enter same passphrase again:
# после появится сообщение такого вида
Your identification has been saved in /Users/ifireice/.ssh/id_rsa
Your public key has been saved in /Users/ifireice/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:Zu+HkZPC4ZP0veRmVjuKgylVvljHBNO8mHs+ieFFPvs ifireice@ifireice-osx
The key's randomart image is:
+---[RSA 3072]----+
|           o     |
|          o o    |
|           = .   |
|        o + +    |
|       +S* X     |
|       oB.@ X .  |
|       . O.# * . |
|      . +.*.% o  |
|       .  o*.+E. |
+----[SHA256]-----+

Бинго, ключи сгенерированы: в заданной директории появятся два файла, id_rsa и id_rsa.pub.

Теперь надо добавить публичный ключ в аккаунт на GitHub:

# выведите содержимое публичного ключа в консоль
$ cat ~/.ssh/id_rsa.pub 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDDJfHIi73sKd6cqm3RwKuY1zl46aAaE6X9Gp
/6zJiY3BiJj95oJjPdpfpPhVFWLIbmT8zFAtOLbX9N4C3b0enHUzgMacP/Kl4AbrAkhLqaua9iD
VNxxiTVxADG1M5525oc/eAvx7y0pXIb9ouWdYJSKa8/TUYFhWlCzV2quY9SA0FaMs7eY41+KWYpG.....
tA0oGxv+7WmXQmQzleLIRG13KQ+VAbL2vabdPcRoGuZavh0smOr/GtVSnLdspZ5RgONMSPWlF2I1YHMR
Q7CIKPs= ifireice@ifireice-osx
$

Скопируйте ключ от символов ssh-rsa и до конца файла и вставьте его в ваш аккаунт на GitHub.

Ну что, с настройкой GitHub пока закончили, осталось установить Git на компьютер. Сделать это можно по официальной инструкции (выберите пункт для вашей ОС).

Терминология

Самое время пополнить ваш Git-словарик, прежде чем создадим первый Pull Request.

Репозиторий (repository) — директория проекта, который отслеживается Git. В директории хранится проект, история изменений и мета-информация проекта (в скрытой директории .git).

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

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

Ветка (branch) — последовательность коммитов. По сути — ссылка на последний коммит в этой ветке. Ветки не зависят друг от друга — можно вносить изменения в одну, и они не повлияют на другую (если вы явно этого не попросите). Работать вы начинаете в одной ветке — main, увидите чуть позже.

Форк (Fork) — собственное ответвление (fork) какого-то проекта. Это означает, что GitHub создаст вашу собственную копию проекта, данная копия будет находиться в вашем пространстве имён, и вы сможете легко делать изменения путём отправки (push) изменений.

Пул-реквест — pull request PR (пиар, он же merge request MR(мр)) — предложение изменения кода в чужом репозитории. Допустим, вы забрали к себе чужой репозиторий, поработали с ним и теперь хотите, чтобы ваши изменения попали в оригинальный репозиторий — тогда вы создаёте создаёте PR с просьбой добавить ваши изменения в репозиторий.

Начало работы

Начнём с простого — создадим свой репозиторий и сделаем наш первый коммит.

Зададим параметры:

• (1) Repository name: имя репозитория.

• (2) Description: описание репозитория.

• (3) Тип репозитория: Public (публичный) или Private (приватный). Сейчас выберем публичный — кто угодно может видеть содержимое репозитория.

• (4) Ставим галку на «Создать README файл». В этом файле в формате MarkDown описывают проект или прочую документацию. Именно содержимое этого файла можно увидеть, когда заходим на главную страницу репозитория. Примеры 1, 2, 3.

• (5) Если известно, на каком языке будет проект, можем добавить шаблон .gitignore для этого языка. Сейчас у нас нет какого-то языка, поэтому не будем создавать .gitignore.

• (6) Выбираем тип лицензии для нашего кода. В лицензии оговариваются права на проект. Стоит обратить внимание на BSD 3 или MIT, так как они предоставляют хороший баланс прав и ответственности.

(7) По умолчанию имя основной ветки в GitHub носит имя main, но до недавнего времени было master.

И нажимаем кнопку «Create repository». Успех, у нас есть первый репозиторий!

А что будет, если не добавим README и .gitignore?

На самом деле ничего страшного не произойдёт, но придётся выполнить ещё ряд шагов, чтобы проинициализировать git-репозиторий, прежде чем начать с ним работать.

Итак, мы создали репозиторий на удалённом сервере, теперь пора «забрать» его к себе на локальную машину и внести какие-то изменения.

Чтобы забрать репозиторий, его надо склонировать к себе при помощи команды git clone и пути до репозитория.

Для начала получим путь до репозитория.

Теперь идём в консоль, переходим в директорию, где хотим хранить проекты, и выполним (git@github.com:ifireiceya/MyFirstRepo.git — путь, который мы скопировали ранее):

$ git clone git@github.com:ifireiceya/MyFirstRepo.git
Cloning into 'MyFirstRepo'...
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (4/4), done.

Переходим в новый каталог, где теперь лежит копия нашего проекта с GitHub:

$ cd MyFirstRepo

Можем посмотреть, что уже есть в этой директории:

$ ls -a
.git      LICENSE   README.md

Видим два знакомых файла,LICENSE и README.md, а также одну скрытую директорию .git.

В .git хранится метаинформация и вся история для проекта. На каждый проект есть только одна директория .git, и лежит она в корне проекта.

$ ls .git
HEAD                 # указатель на вашу активную ветку
config               # персональные настройки для проекта
description          # описание проекта
hooks                # pre/post action hooks
index                # индексный файл
logs                 # история веток проекта (где они располагались)        
objects              # ваши объекты (коммиты, теги и тд)
packed-refs refs     # указатели на ваши ветки разработки

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

При установке Git была добавлена утилита git config, которая позволяет просматривать и изменять большинство параметров работы Git’а. Если речь о данных пользователя или способе работы репозитория — git config будет самым удобным способом настройки.

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

Поэтому в терминале переходим в Git-репозиторий, для которого задаём настройки, и выполняем:

$ git config user.name "Дарья Меленцова"
$ git config user.email ifireice@example.com


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

Чтобы настраивать ещё больше параметров с помощью git config, прочитайте эту документацию.

Вносим изменения

Теперь нужно внести изменения в проект. Но перед этим посмотрим две полезных команды:

• git status — показывает текущее состояние файлов в репозитории (какие файлы изменились, удалились, добавились);

• git log — показывает историю изменений (это про зафиксированные изменения, то есть коммиты).

Выполним эти команды и посмотрим, что они выведут для нашего репозитория.

Вбиваем git status:

$ git status                                  
On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean

И видим, что у нас нет изменений. Говорят, «нет коммитов в репозитории». Конечно, мы успели только клонировать репозиторий и ещё ничего не делали.

Идём дальше и пробуем git log, который покажет, что в проекте был только один Initial commit — когда мы создавали репозиторий с README.md:

$ git log
commit 9ae1cbcc77f3b64d604612d4a599bdbb8b1cf204 (HEAD -> main, origin/main, origin/HEAD)
Author: ifireiceya <117034707+ifireiceya@users.noreply.github.com>
Date:   Mon Oct 31 00:01:05 2022 +0300

    Initial commit
(END)

Убедились, что у нас нет неучтённых изменений. Пора бы уже что-то сделать!

Открываем любимый текстовый редактор и создаём новый файл с именем hw.py.

Это будет небольшая программа на Python, которая при запуске печатает «Hello World!» (внезапно):

$ vi hw.py
print("Hello World!")

Отлично, код написан и даже хранится локально в нашем репозитории (мы же в директории проекта всё делали).

Теперь наша задача — сохранить изменения в «оригинальный» (удалённый) репозиторий. Для этого нужно:

1. Познакомить Git с новым файлом, то есть добавить файл в индекс — git add.

2. Зафиксировать (закоммитить) изменения — git commit.

3. Синхронизировать изменения с сервером — git push.

4. Посмотреть в репозиторий и убедиться, что всё сработало.

Делаем!

Появился файл hw.py, но он красный. Паника! Всё сломалось?!

Нет, всё идёт по плану, но прежде чем продолжить, стоит обсудить состояние файлов с точки зрения Git’а.

По мнению Git’а, файл может пребывать в одном из четырёх состояний:

1. Неотслеживаемый (untracked).

2. Изменённый (modified) — файл, в котором есть изменения, но он ещё не добавлен в коммит (не зафиксирован).

3. Отслеживаемый (staged) — файл, который добавили в индекс.

4. Зафиксированный (committed) — файл уже сохранён в локальной базе, и в нём не было изменений с последнего коммита.

В связке с состоянием файлов используют три основных секции проекта:

• Рабочая директория (working directory) — это директория, которая содержит в себе то, с чем вы работаете, или то, что вы извлекли из истории проекта в данный момент. Рабочая директория — это временное место, где вы можете модифицировать файлы, а затем выполнить коммит.

• Область индексирования (staging area) — индекс-файл в каталоге Git, который содержит информацию о том, что попадёт в следующий коммит.

• Каталог Git — место, где Git хранит метаданные и базу объектов вашего проекта. Помните ещё про .git?

Что происходит на практике

Мы добавили новый файл hw.py и видим, что у него состояние untracked, то есть неважно, что мы делаем с файлом, Git проигнорирует любые изменения в нём.

Чтобы Git начал следить за изменениями в файле, его нужно добавить в индекс.

Для этого используем команду git add <имя файла>.

Кстати, вы заметили, что Git довольно дружелюбный и часто подсказывает команды, которые нужно выполнить?

$ git add hw.py
# если нужно добавить много файлов и не хочется описывать, можно использовать команду
# git add .
# но стоит точно понимать, что добавляем, иначе придётся потом удалять файлы из индекса
# кстати, для удаления используется команда git rm, но стоит почитать доку перед использованием

И ещё не забывайте о файле .gitignore, где перечислены папки и файлы репозитория, которые Git не должен отслеживать и синхронизировать их состояние (не добавлять их в индекс). Обычно в него добавляют файлы логов, результаты сборки и другое. Поддерживает шаблоны. Кстати, .gitignore — тоже файл, который надо добавить в индекс.

• Если файл попадает в правила.gitignore, то он не появится в git status.

• Если файл был добавлен в индекс, а потом добавлено правило для файла в .gitignore — файл всё равно будет отслеживаться и его надо явно удалить из индекса.

Посмотрим, как изменилось состояние нашего файла:

Давайте зафиксируем изменения, так как наша задача сейчас решена: мы написали программу на Python и хотим сказать Git, что вот теперь мы закончили работать с файлом и надо запомнить текущее состояние.

Для этого нужно закоммитить файл с помощью команды git commit.

При создании обычно лаконично описывают коммит, используя ключ -m:

$ git commit -m "add python hello world"     
[main 6d8a5c3] add python hello world
 1 file changed, 1 insertion(+)
 create mode 100644 hw.py

Пара слов о том, как писать сообщения для коммитов:

• максимум 50 символов;

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

• сообщение стоит начинать с заглавной буквы;

• если меняли код, пишите исходный код в сообщении.

$ git log

$ git push
Counting objects: 100% (4/4), done.
Delta compression using up to 12 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 341 bytes | 341.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
To github.com:ifireiceya/MyFirstRepo.git
   9ae1cbc..6d8a5c3  main -> main

Предлагаем проверить, что наши изменения есть на GitHub. Идём в репозиторий и смотрим на него.

Задача немного посложнее

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

Например, есть у нас любимый опенсорсный проект, в который мы хотим принести добро и закрыть им какой-нибудь Issue.

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

Но будем делать это с позиции внешних пользователей в чужом репозитории.

Репозиторий хранится в ifireice/git, а изменения делает пользователь ifireiceya.

Пользователь ifireiceya не имеет доступа в ifireice/git, и ему придётся работать через Fork, то есть нужно сперва сделать копию этого репозитория к себе и вести разработку у себя, а потом отправить в основной репозиторий запрос на изменения — Pull Request.

Но обо всём по порядку. Сначала делаем Fork.

Откроется окно для создания нового форка (fork).

Изменится владелец репозитория (1), и опционально можно изменить описание проекта.

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

Теперь клонируем форк-репозиторий к себе на машинку и ведём разработку.

Только мы будем работать чуть-чуть по-другому, не как с нашим репозиторием.

В нашем репозитории мы работали в ветке main и все изменения сохраняли в ней.

А теперь у нас большой проект, и над ним одновременно могут трудиться несколько разработчиков. Чтобы разные изменения не смешивались в кучу и чтобы один разработчик не мешал другому, разработка ведётся в разных независимых версиях продукта — ветках (branch). Когда работа закончена, все изменения сливаются в одну главную ветку.

Клонируем репозиторий и создаём отдельную ветку, в которой будем устранять опечатку:

$ git clone git@github.com:ifireiceya/git.git
$ cd git
# создадим новую ветку и сразу же переключимся на неё, чтобы работать там
$ git checkout -b fix-misprint
Switched to a new branch 'fix-misprint'

Чтобы посмотреть, какие ветки есть в проекте и какая сейчас активна, используется команда git branch:

$ git branch
* fix-misprint
  main
# * помечена текущая активная ветка

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

Можем посмотреть, что изменилось с последнего коммита, при помощи команды git diff (красным с “-” то, что было, зелёным с “+” — то, что стало):

$ git diff

$ git status
On branch fix-misprint
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   README.md

no changes added to commit (use "git add" and/or "git commit -a")

$ git commit -am "Поправили опечатку"
[fix-misprint 188caa7] Поправили опечатку
 1 file changed, 1 insertion(+), 1 deletion(-)

$ git push
fatal: The current branch fix-misprint has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin fix-misprint

Упс, fatal. Читаем подсказку от Git и выполняем:

$ git push --set-upstream origin fix-misprint
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 12 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 402 bytes | 402.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
remote:
remote: Create a pull request for 'fix-misprint' on GitHub by visiting:
remote:      https://github.com/ifireiceya/git/pull/new/fix-misprint
remote:
To github.com:ifireiceya/git.git
 * [new branch]      fix-misprint -> fix-misprint
Branch 'fix-misprint' set up to track remote branch 'fix-misprint' from 'origin'.

Успех!

Почему произошёл fatal: простой git push предполагает, что ветка, которую отслеживает текущая локальная ветвь, уже существует на удалённом сервере. У нас ветка новая и была создана только локально, поэтому нам нужно её создать, указав --set-upstream.

Проверим, что ветка появилась на GitHub.

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

Для этого создаём Pull request.

И увидим такую картину.

(1) репозиторий, в который хотим добавить изменения. — ifireice/git

(2) ветка, в которую хотим добавить изменения — main

(3) репозиторий, из которого хотим добавить изменения — ifireiceya/git

(4) ветка, из которой хотим добавить изменения — main

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

Будем считать, что у нас всё хорошо и наши изменения приняли без вопросов.

Как это выглядит на стороне ревьюверов:

На этом пока всё. Увидимся в следующих выпусках про Git и не только.

Что изучили

• Поговорили про системы контроля версий

• Настроили себе GitHub

• Создали первый репозиторий и внесли в него изменения

• Узнали про ветки, форки и остальное

• Сделали первый ПР

Что НЕ изучили

• Конфликты

• Откат изменений (reset, revert)

• Как забрать файл из другой ветки (Cherry-pick)

• rebase

Что ещё почитать

• Отличная книга Pro Git (есть на русском и английском)

• Курс «DevOps для эксплуатации и разработки»

• Trunk-Based Development — стратегия отведения веток

• GitFlow — другая стратегия отведения веток

Иллюстрация: GitHub / Colowgee для Skillbox Media

83 миллиона пользователей, четыре миллиона организаций и 200 миллионов репозиториев. В Сети много сервисов для размещения исходного кода своих проектов, но говорят чаще всего именно про GitHub. В чём же дело?

Конечно, известный владелец сервиса (Microsoft) и привычка играют свою роль, но главная причина — возможности платформы.

• Что такое GitHub и чем он отличается от Git
• Как понять, нужен ли вам GitHub
• Основные концепции GitHub простыми словами
• Создание репозитория и загрузка файлов
• Просмотр файлов в репозитории
• Поиск и чтение репозиториев
• Создание веток

• Переключение веток и решение конфликтов
• Настройка описания репозитория
• Создание сайта из вашего GitHub-профиля
• Подключение GUI-клиента GitHub Desktop
• Работа с GitHub через CLI
• Настройка GitHub-профиля
• Вместо end()

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

Здесь можно найти кучу open-source-проектов на разных языках и поучаствовать в них, разместить своё портфолио с примерами кода, чтобы приложить ссылку к резюме, подглядывать в открытых проектах интересные архитектурные решения, смотреть, как опытные разработчики пишут код, и скачивать огромное количество полезных в разработке и бесплатных инструментов для разработки. Кстати, некоторые умельцы умудряются собирать в GitHub целые библиотеки — книг и статей, а не программистские либы

И да, если вы недовольны какими-то фичами в любимой открытой программе и она выложена на GitHub, вы всегда можете прийти и поругаться в комментариях к проекту А лучше всего — оформить issue (мы расскажем, что это) и самостоятельно пофиксить проблему на радость всем пользователям. Не забывайте и благодарить авторов классных открытых проектов — донатами и просто тёплыми словами. Им будет очень приятно.

Придя практически в любую IT-компанию, вы столкнётесь с тем, что код где-то хранится — и в подавляющем большинстве случаев этим «где-то» будет именно GitHub. У GitHub есть довольно известный конкурент — GitLab, он тоже основан на Git, но это разные платформы разных компаний, хотя их функциональность очень похожа.

А ещё не стоит путать GitHub и Git. GitHub — лишь одна из реализаций системы контроля версий Git (только взгляните на полный список Git-клиентов с графическим интерфейсом), в которую добавлено много удобных инструментов и возможностей (те же комментарии, issues, гиперссылки, форматированный текст и тому подобное). Помните, GitHub можно использовать и без знания Git (обратное тоже верно).

Ну как, звучит круто? Тогда приступайте к нашему гайду о том, как пользоваться GitHub, чтобы во всём разобраться и вообще понять, нужен ли он вам прямо сейчас.

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

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

И действительно, есть множество других способов хранения исходников: можно создать для них папку в разделе «Мои документы», закидывать их в облако и подписывать версии или даже загружать в «Избранное» в Telegram или «ВКонтакте» (костыльно, да, но вполне реально).

А ещё можно накидывать список изменений в заметках в телефоне/на холодильнике текстом в приватном Telegram-канале. Можно деплоить проект с помощью простого скачивания и распаковки ZIP-архива с файлами вашей программы (особенно если цель — просто показать программу другу или девушке, которой вы пришли «помочь с ноутбуком» ^_^). В конце концов, можно сообщать о багах в вашем любимом фреймворке сообществу анонимов в паблике в VK — возмущаться вместе очень весело.

Все эти способы по-своему хороши, но для работы в IT нужно привыкать к GitHub: это стандарт индустрии.

Интересный факт: недавно появилась российская альтернатива GitHub под названием GitFlic. Команда сервиса заявила, что намерена дать «новый импульс разработке отечественных операционных систем, программ, приложений и серверных решений». Среди цепляющих возможностей — интеграция с Telegram.

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

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

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

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

Это просто корневая папка с файлами и вложенными директориями вашей программы — и одновременно её страница на GitHub. Загрузить в репозиторий можно всё что угодно, но предполагается, что вы будете хранить в нём файлы с исходным кодом и какие-нибудь дополнительные материалы — допустим, необходимую для GUI или вёрстки графику (картинки, иконки и тому подобное).

Репозитории могут быть публичными и приватными, в них можно создавать другие папки и отслеживать изменения версий. Управлять своими репозиториями можно прямо через интерфейс сайта, командную строку, десктопное приложение GitHub или различные средства разработки (IDE), поддерживающие интеграцию с сервисом.

В ветки группируются изменения и обновления — допустим, одна главная ветка (по умолчанию создаётся main) и одна beta. Ветки независимы друг от друга, но при желании их можно объединять (merge — слияние) — даже если между ними есть разница в коде.

Внести в содержимое репозитория изменения можно напрямую или создав копию. Само внесение изменений называется «коммит» (от английского commit — совершить), у него есть временная метка и хеш-сумма.

Перенос изменений-коммитов из локального репозитория (на вашем ПК) на удалённый (remote repository, то есть в данном случае на GitHub) называется «пуш» (push) — от английского «толкать» (дословно — «проталкивать» изменения).

Скопировать репозиторий для внесения изменений в копию можно двумя основными способами:

• клонировать (clone) — то есть просто скопировать на локальный компьютер или сервер;
• или форкнуть (от английского fork — развилка) — сделать отдельную копию репозитория (обычно чужого) для продолжения разработки «по другому пути развилки».

Если вы форкнули чужой проект, чтобы предложить автору конкретные улучшения, нужно по готовности «запулить» их в исходный репозиторий — то есть сделав pull request (запрос на изменения).

Это 90% необходимых фактов. Более скучные подробности описаны в документации и разделе обучения GitHub, а также в руководстве по самому Git, ну а мы попробуем применить всё это на практике.

Конечно, самый простой способ пользоваться GitHub — через сайт, поэтому начнём отсюда.

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

Очень кратко повторим выводы из нашего прошлого материала:

• для создания репозитория нужно нажать на + в правом верхнем углу сайта, выбрать пункт New Repository, заполнить название и описание, проставить нужные галочки и щёлкнуть на Create Repository;
• для загрузки файлов нужно зайти в нужный репозиторий, щёлкнуть на Add file и выбрать Upload files.

Но для обучения Тёмной стороне Силы работе с GitHub полезно потренироваться выполнять и другие необходимые в процессе разработки действия: клонирование/форк, объединение веток, просмотр и разрешение конфликтов и другие.

Давайте пошагово пройдём всё это вместе — сначала через сайт, а потом взглянем одним глазком на работу через GUI-клиенты и интерфейс командной строки (CLI).

Согласитесь, что в ряде случаев удобно не скачивать исходники, а просто бегло ознакомиться с ними. Для таких простых операций вовсе не нужен десктопный клиент: все файлы можно быстро открыть в веб-версии (и код, и те же картинки). Просто щёлкните по ним для просмотра!

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

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

Важнее другое — на что обращать внимание. Пройдёмся по некоторым пунктам со скриншота выше.

Во-первых, самое очевидное — это описание на главной странице. Именно в нём находится ответ на ваш главный вопрос — что это и чем может вам помочь.

Если точнее, предусмотрено два описания репозиториев — краткое (один абзац справа вверху) и полное (по центру, под списком файлов).

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

После этого оцените, подходит ли вам частота обновлений, — это можно сделать в разделе Releases (ссылка прямо под кратким описанием). Конечно, это зависит от ситуации: где-то может пригодиться инструмент, который не обновлялся четыре года, но чаще всего нужна хотя бы минимальная поддержка — то есть обновления минимум раз в несколько месяцев.

Важно знать и где посмотреть количество и содержание коммитов — кликабельный счётчик находится над списком файлов справа.

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

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

Вообще, неплохо изучать репозитории известных приложений, которыми сами пользуетесь (как на скриншоте выше), и отмечать понравившиеся звёздочками. Это не только интересно — со временем GitHub изучит ваши предпочтения и станет предлагать в блоке Explore то, что вам может понравиться.

Создать новую ветку очень просто:

• Жмём на большую зелёную кнопку New branch.
• Вводим название новой ветки.
• Выбираем исходную ветку для копирования (то есть main, так как пока других и нет).
• Щёлкаем на Create branch.

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

Создадим также альтернативную ветку №2 (sava) и посмотрим, как всё это выглядит в итоге.

Можно говорить и про переключение между ветками в другом смысле — когда изменения из альтернативной ветки сливают с главной веткой. Смотрите: у нас есть файл code.js, но его содержимое немного отличается:

• в ветке main там JS-команда console.log («Дефолтная ветка») и картинка с великим маэстро современности Риком Эстли;
• однако в ветке koshka тот же файл содержит команду console.log («Кошка!»);, а вместо Рика — смешной кот;
• и всё совсем усложняется третьей веткой sava, где консольный вывод вида console.log («Сова!»); и используется картинка с совой (естественно, все перечисленные картинки во всех ветках называются одинаково — pic.jpg).

Получается, между ветками есть конфликт и просто слить любую из альтернативных веток с главной нельзя! Но для этого уже есть решение: GitHub предлагает нам сравнить конфликтующие ветки, и если мы захотим, то и запулить изменения в основную — то есть сделать тот самый pull request, о котором говорилось выше.

Вот как выглядит сравнение веток (c koshka и sava соответственно).

Допустим, мы решаем принять изменения из ветки sava и создаём pull request с небольшим комментарием.

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

Пул-реквест можно окончательно принять, подтвердив слияние (merge) веток, или отклонить, закрыв запрос (Close pull request).

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

Чтобы поменять данный ряд параметров, зайдите в своём репозитории в раздел Settings -> Branches. Нужные настройки — в подразделе Branch protection rules (целых 10 галочек на выбор).

Основное описание вашего GitHub-проекта задаётся в файле Readme.md, который можно создать вместе с репозиторием или после. Расширение md — это просто сокращение от названия популярного языка упрощённой разметки контента — Markdown.

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

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

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

Файл Readme может быть довольно длинным, но всё же для оформления большой документации GitHub рекомендует создать «Вики».

Захостить сайт на GitHub можно с помощью функции GitHub Pages. Это очень просто:

• Зайдите в настройки репозитория.
• В блоке Code and automation выберите Pages.
• Выберите источник (Deploy from a branch, затем нужную ветку).
• Кликните на Save.
• Обновите страницу, и вверху страницы появится ссылка на ваш новый сайт.

В случае создания сайта для продвижения себя, а не проекта, просто создайте репозиторий с кодом сайта-визитки и дайте ему имя вида [username].github.io, где username — название вашего аккаунта на GitHub. Более подробно про эту функцию — тут.

Если вам удобнее такой способ работы, здесь всё тоже просто. Опять же, повторим кратко выводы из нашего более подробного гайда на эту тему:

• Скачиваем и устанавливаем сам клиент.
• Авторизуемся в своей учётной записи.
• Работаем с существующими репозиториями или создаём новые (локальные).

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

Клонированные из удалённого GitHub-репозитория файлы хранятся в специальной папке на вашем компьютере, и в них легко вносить изменения — клиент будет открывать их в выбранном вами редакторе кода / среде разработки (хотя удобнее всё по отдельности — выбрав нужный файл-исходник в папке).

В общем, всё просто, как раз-два-три.

Работать с GitHub можно и через командную строку Windows или PowerShell. Это не очень сложно: для начала интерфейс командной строки также нужно скачать и установить (документация — здесь).

Команды для GitHub CLI начинаются с сокращения gh — к примеру gh repo clone.

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

Главное, что нужно про это знать: все команды Git начинаются соответственно — со слова git, после чего указывается тип действия: git clone, git merge, git fork и прочее. Чтобы воспользоваться ими, установите Git, распечатайте себе любую памятку по его командам и смело начинайте ими пользоваться.

Кастомизация профиля — важная часть самопрезентации разработчика: резюме, визитная карточка и витрина проектов, над которыми вы работали.

Эту информацию оценивают работодатели, поэтому стоит заполнить информацию о себе и сделать публичными несколько ваших лучших репозиториев (конечно, если там ничего секретного :)) — именно они будут частью вашей персональной витрины.

Посмотрим на профиль какого-нибудь крутого разработчика из тех, кто сейчас в тренде GitHub (да-да, есть и такой раздел).

На первом месте — некий Стивен Селис. А что в его профиле? Указано место работы, есть сайты и контакты, а в статистике — 123 репозитория и 1725 изменений в репозиториях за год (круглый год). То есть невооружённым глазом видно, что человек как минимум активный и опытный.

Даже если вы пока ещё не в топе GitHub, нужно стремиться к подобному наполнению профиля: подробная информация + показательный ряд проектов (вы можете закреплять их по-своему, нажав в собственном профиле на Customize your pins).

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

GitHub пользуются все: это один из важных общих навыков вне зависимости от выбранного вами языка программирования и направления разработки. И, как и школьные уроки ОБЖ, тот же git clone когда-нибудь вас спасёт.

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

Как зарабатывать больше с помощью нейросетей?
Бесплатный вебинар: 15 экспертов, 7 топ-нейросетей. Научитесь использовать ИИ в своей работе и увеличьте доход.
Узнать больше

Git — распределенные системы контроля версий, которые помогают обмениваться кодом и «ковать» проекты в команде — отслеживать и контролировать все изменения в коде. Если вы занимаетесь разработкой приложений, веб-сайтов или игр, то наверняка сталкивались с этим.

Одна из таких систем — GitHub — платформа для хостинга репозиториев. Расскажем о ней подробнее: как зарегистрироваться, создать проект, вносить в него изменения и не столкнуться с конфликтами версий. 

Регистрация на GitHub: создание аккаунта

Для работы с платформой нужно создать аккаунт. Для этого переходим по ссылке и тапаем по кнопке Sign up.

На странице регистрации вводим данные:

1. Адрес электронной почты. Если на почту уже был зарегистрирован аккаунт, на странице появится сообщение об ошибке: «Email is invalid or already taken».

1. Пароль. Система рекомендует использовать для пароля последовательность из 15 символов или 8, но с использованием хотя бы одной цифры и строчной буквы.

1. Имя пользователя. «Юзернейм» должен быть уникальным. При этом он не может начинаться или заканчиваться дефисом. 

Теперь нужно нажать кнопку Continue, принять или отклонить предложение о подписке на рассылку и пройти экстравагантную валидацию:

Затем подтвердите адрес электронной почты. 

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

Установка Git

Для работы с репозиторием необходимо скачать Git-терминал или GitHub Desktop. Что из этого выбрать — решать вам. Но предпочтительней уметь работать с командной строкой Git. Такое требование часто можно встретить в вакансиях. Вдобавок, знание командной строки позволяет работать с другими платформами, подобными GitHub.

Терминал

Если у вас установлен Linux, смело пропускайте раздел. С Mac и Windows другая история.

Mac OS

Если вы пользовались XCode, вероятно, Git уже установлен. В противном случае зайдите в терминал, выполните команду git и нажмите кнопку Установить.

После установки можно узнать версию Git.

git --version

Windows

На винду Git можно скачать с официального сайта или через пакет Git Chocolatey. Дополнительная информация о Git Windows доступна по ссылке.

GitHub Desktop. Краткий обзор

Непривычна работа в командной строке — установите «десктопную» версию (доступна на всех ОС). Она хорошо подходит для базовых операций.Установщик есть на официальной странице GitHub Desktop. Там же и наиболее подробное описание программы.

При первом запуске пользователя встречает окно с авторизацией.

А после — интерфейс с привычным функционалом: можно создавать и клонировать репозитории.

Важно отметить, что установка GitHub Desktop на Linux может отличаться в зависимости от дистрибутива. Рекомендуем ознакомиться с официальной инструкцией.

Создание первого репозитория

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

Первый способ — синхронизация с локальным репозиторием

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

Перед его загрузкой в глобальный репозиторий можно создать локальный.

Для этого необходимо зайти в терминал, перейти в директорию проекта и ввести команду:

git init 

Загрузка файлов в репозиторий. Создание коммитов

Далее следует добавить все файлы проекта в своеобразный пакет изменений и сделать commit («закоммитить») — загрузить изменения.

git add main.py
git add GAN_core.py
git add dino_ds_api.py
git commit -m “первый коммит”

Последняя команда делает сам «коммит», а флаг -m указывает на сообщение «первый коммит».

В примере были «закоммичены» несколько python-файлов: main, GAN_core и dino_ds_api. Если вам нужно добавить в «коммит» все, что есть в директории, — используйте команду:

git add .

Теперь создадим репозиторий на GitHub. Для этого нужно нажать на кнопку Create repository.

В открывшемся окне обязательно к заполнению только поле с названием проекта. Оно должно быть кратким, но понятным. В нашем примере это gan-dino (gan от generative adversarial networks и dino от dinosaur).

Все остальное опционально:

• Описание. Поле с кратким описанием проекта. 
• Режим доступа. Для коммерческих или корпоративных продуктов обычно устанавливается режим private (репозиторий доступен ограниченному кругу лиц). В остальных случаях — public (доступно по ссылке).
• Файл README. Если в репозитории нужно подробное описание проекта — поставьте галочку рядом с Add a README file. Но есть нюанс: для первого способа создания репозитория галочки быть не должно.
• Конфигурация .gitignore. Бывает, что в проекте нужно разместить невидимые для Git файлы. Чтобы как-то их обозначить, придумали конфигурацию .gitignore, в которой их можно перечислить.
• Лицензия. Чтобы никто не использовал ваш код в коммерческих целях без спроса, необходимо добавить файл с лицензией. В нем правообладатели прописывают правила использования своей интеллектуальной собственности.

Создадим public-проект gan-dino, без файла README и конфигурации .gitignore.

Далее GitHub показывает наборы команд, необходимые для загрузки исходного кода в репозиторий. Нас интересует второй блок.

git remote add origin https://github.com/t-rex-general/gan-dino.git
git branch -M main
git push -u origin main

Первая строка загружает origin —  прообраз нашего проекта в глобальном репозитории. Со второй командой мы познакомимся позже. Третья команда загружает (пушит) изменения в GitHub-репозиторий.

После ввода команд система попросит авторизоваться с помощью пароля и названия профиля.

После 13 августа 2021 года вместо пароля нужно вводить токен. 

Откройте настройки вашего аккаунта, выберите пункт меню Developer settings, кликните по Personal access tokens и generate new token. А затем повторите попытку.

Получилось! В репозиторий загрузились нужные файлы. Можно смело делиться ссылкой на него.

Второй способ — от глобального к локальному

Бывает другая ситуация, когда кода программы нет и нужно создать пустой репозиторий на GitHub, а после — сделать его локальный дубликат. Данный процесс называется локальным развертыванием. 

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

Чтобы клонировать этот репозиторий себе на компьютер, нужно нажать на зеленую кнопку Code, скопировать HTTPS-адрес, перейти в терминал, в нужную директорию и ввести команду:

git clone https://github.com/t-rex-general/gan-dino2.git

В результате файл README.md появится в выбранной директории — локальном репозитории.

С помощью этой же команды можно клонировать и чужие проекты. Например, чтобы не писать все модули для определителя динозавров самостоятельно, можно клонировать чужой репозиторий себе на компьютер. Или сделать fork («форк»), то есть скопировать чей-то проект в свой GitHub-профиль для его доработки. 

Третий способ — внутри GitHub

Если нет возможности использовать Git-терминал или GitHub Desktop, можно работать напрямую с GitHub. Перед этим создаем репозиторий с файлом README.

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

Например, для создания нового файла достаточно нажать на кнопку Create new file. Откроется встроенный редактор кода. 

Потом необходимо сделать коммит.

Работа с ветками

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

Представьте ситуацию: 

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

Создание веток через Git

Чтобы создать ветку (например, dev) в проекте, нужно ввести команду:

git branch dev

После ветка появится в общем списке.

git branch

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

git checkout dev

Попробуем изменить файл проекта и загрузить коммит.

git add main.py
git commit -m “добавили if”

Теперь можно посмотреть логи — историю добавления коммитов.

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

git checkout 61a8f08226eb8067d4e356387f1dcce5c79812dd

Чтобы запушить ветку в онлайн-репозиторий введем команду:

git push --set-upstream origin dev

Открываем репозиторий в GitHub и видим, что добавилась ветка dev:

Но если мы зайдем в main.py, то никаких изменений там не обнаружим, пока не выберем ветку dev.

Чтобы изменения затронули и main-ветку, нужно сделать merge — слияние веток.

Создание веток через GitHub

Как и в случае создания репозитория, можно быстро создавать новую ветвь в GitHub и переключаться между существующими ветками.

В рамках веток можно также вносить изменения — механизм работы не меняется. 

Слияние веток проекта

Мы почти разработали свой проект. Самое время объединить ветки dev и main.

Первым шагом необходимо переместиться в ветку main:  

git checkout main

Вторым шагом — сделать merge с веткой dev и запушить изменения:

git merge dev
git push

Теперь в GitHub-репозитории отображается актуальная информация.

Работа в команде: конфликты версий и git pull

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

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

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

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

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

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

git pull

Если это сделать, в файле main.py появится структура, в которой будут видны изменения, которые внесли Вася и Гриша.

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

git add main.py
git commit -m “dino_weight”
git push

Репозиторий успешно обновлен.

На практике конфликтов гораздо больше и разрешаться они могут по-разному. Важно научиться серфить по руководству git и гуглить. Впрочем, это относится ко всему процессу изучения Git и GitHub. 

Fork и Pull Request

Бывает, что ваш репозиторий кто-то форкает и вносит свои коррективы. Вы можете даже не знать, кто инициатор. Если он захочет поделиться корректировками с вами, то создаст запрос слияния (Pull Request). 

Зайдем с другого аккаунта, найдем репозиторий gan-dino через поисковую систему в GitHub и сделаем форк.

В нашем списке репозиториев появился новый gan-dino-FORK — это форк-образ gan-dino. Теперь можно внести изменения, например, в main.py, и сделать pull request.

Затем владельцу репозитория нужно подтвердить или отклонить запрос. Чтобы это сделать, нужно перейти во вкладку «Pull requests», выбрать интересующий pull-запрос и нажать одну из предложенных кнопок.

Домашнее задание

Любой конкурентоспособный разработчик должен разбираться в Git. Нелишним будет и знание GitHub, в котором есть много возможностей, значительно упрощающих работу над проектами в команде (project management). Например, дашборды во вкладке Projects, повторяющие функционал Trello и Jira.

GitHub — это целая социальная сеть для разработчиков из разных частей света. 

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

Присоединяйтесь к нашей команде и погрузитесь в наши git-проекты.

---

Если у вас остались вопросы по работе с Git или GitHub, напишите нам.