Как скачать проект с github через консоль windows

➜  ~ git --version
git version 2.35.1
➜  ~

git config --global user.name "ваше имя"

git config --global user.email email@example.com

ssh-keygen -t ed25519 -C "your_email@example.com"

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

> Generating public/private имя-ключа key pair.
> Enter a file in which to save the key (/c/Users/ваш-профиль/.ssh/id_имя-ключа):*[Press enter]*

ssh-add ~/.ssh/id_ed25519

clip < ~/.ssh/id_ed25519.pub

~ cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIO63MT6VCFuZtCLhLj1J6I7dgEU2BsRdIsnvnr4ax+Fr shklyar@htmlacademy.ru

git clone git@github.com:your-nickname/your-project.git

➜  device git clone git@github.com:academy-student/1173761-device-34.git
Клонирование в «1173761-device-34»…
remote: Enumerating objects: 15, done.
remote: Counting objects: 100% (15/15), done.
remote: Compressing objects: 100% (14/14), done.
remote: Total 15 (delta 0), reused 15 (delta 0), pack-reused 0
Получение объектов: 100% (15/15), 145.07 КиБ | 900.00 КиБ/с, готово.

git clone git@github.com:_your-nickname_/_your-project_.git folder_name

git checkout -b имя-новой-ветки.

➜  1173761-device-34 git:(master) git checkout -b task1
Переключено на новую ветку «task1»
➜  1173761-device-34 git:(task1)

git branch -m старое-имя-ветки новое-имя-ветки.

git commit -m "ваше сообщение"

git push origin название-текущей-ветки

git pull git@github.com:academy-student/1173761-device-34.git master

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

Участвовать

1. Через консоль

1. Запустить консоль git:

2. Написать команду: 

git clone Откуда Куда

↓

git clone https://bitbucket.org/testbasecode/folks/src/master/ D:\git\folks_console

В консоли нужно писать простой слеш или экранировать обратный. Иначе консоль его проигнорирует!

Также НЕ НАДО использовать в названии папки «куда клонируем» русские символы или пробелы. Иначе не говорите потом, что сборщик проекта не работает!

2. Через IDEA

1. Запустить IDEA

2. Check out from Version Control → Git

3. Заполнить поля:

4. Нажать Clone — всё! Дальше IDEA все сделает сама!

А под конец предложит открыть проект, подтверждаем!

Если открывается пустой серый экран, найдите закладку «Project» (у меня она слева сверху) и щелкните по ней, чтобы раскрыть проект:

И вуаля, и код скачали, и сразу в удобном и бесплатном редакторе открыли! То, что надо. Для новичка так вообще милое дело.

3. Через TortoiseGit

Еще один простой и наглядный способ для новичка — через графический интерфейс, то есть «черепашку» (tortoise):

2. Установить его → Теперь, если вы будете щелкать правой кнопкой мыши в папочках, у вас появятся новые пункты меню: Git Clone, Git Create repository here, TortoiseGit

3. Перейти в папку, где у нас будет храниться проект. Допустим, это будет D:git.

4. Нажать правой кнопкой мыши → Git Clone

Заполнить поля:

5. Нажать «Ок»

Вот и все! Система что-то там повыкачивает и покажет результат — папочку с кодом!

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

Git. Урок 6.
Работа с удаленным репозиторием.
Модель ветвления.
Команды: clone, fetch, push, pull.

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

Оглавление

ТЕОРЕТИЧЕСКИЙ БЛОК

Что такое удаленный репозиторий

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

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

Для начала давайте повторим информацию из предыдущих уроков.

1. Распределенная система контроля версий – такая система, в которой участники хранят у себя на компьютере полную копию всех версий проекта. Такой принцип делает их независимыми от рабочего сервера.
2. Git относится к распределенным системам контроля версий.

Чтобы вы точно вспомнили, приведем диаграмму из первого урока:

Возможно у вас возникнет вопрос: при чем здесь удаленные репозитории? Все просто: сервер по центру диаграммы и есть удаленный репозиторий. Дадим более точное определение.

“

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

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

Если мы подключим удаленный репозиторий к своему локальному, то у нас появятся копии всех ссылочных объектов удаленного репозитория. То есть, например, у удаленного репозитория есть ветка main, а у нас будет копия этой ветки – origin/main. Все такие ссылочные объекты (указатели, ветки и теги) удаленного репозитория хранятся почти там же, где и у локального – в директории .git/refs/remotes/<имя_удаленного_репозитория>.

Кстати
Принято называть удаленные ветки (то есть ветки удаленных репозиториев), приписывая к их названию имя удаленного репозитория. Например, если у нас есть удаленный репозиторий с именем origin и веткой main, то мы будем называть такую ветку origin/main. То же мы будем делать и со всеми остальными ссылочными объектами. Это может показаться излишним, но на самом деле это добавляет определенности и позволяет не запутаться в многочисленных названиях веток.

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

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

Настройка подключения удаленного репозитория. Группа команд git remote.

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

Для управления подключением удаленных репозиториев в Git предусмотрена целая группа команд – git remote. Мы рассмотрим самые частоиспользуемые команды из этой группы.

2.1. Добавление удаленного репозитория к существующему локальному. Команда git remote add.

Давайте разберемся, как добавить удаленный репозиторий к вашему локальному репу. Для этого в Git есть команда git remote add.

Команда git remote add

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

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

Со ссылкой на удаленный репозиторий тоже все просто. Мы работаем с GitHub, поэтому эту ссылку можно взять, нажав на большую зеленую кнопку Code на странице репозитория на GitHub.

Вам предложат выбрать одну из трех ссылок: для протоколов https и ssh и для клиента GitHub на компьютер. Вот примеры этих трех ссылок для репозитория geometric_lib известного вам по практическим занятиям этого курса:

1. HTTPS-ссылка: https://github.com/smartiqaorg/geometric_lib.git
2. SSH-ссылка: git@github.com:smartiqaorg/geometric_lib.git
3. GitHub CLI ссылка: gh repo clone smartiqaorg/geometric_lib

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

Итак, с последней ссылкой все понятно: ее нужно использовать в специальной программе для компьютера с графическим UI от создателей GitHub. Но в чем разница между первыми двумя?

Дело в том, что существует два основных протокола подключения к git-серверу: HTTPS и SSH. SSH считается более надежным, но он немного сложнее в настройке. Давайте разберемся, как настроить подключение для каждого из них. А окончательный выбор протокола оставим на вкус читателя.

2.2. Настройка подключения по HTTPS

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

Итак, чтобы создать токен персонального доступа, следуйте инструкции:
1. Подтвердите свой email-адрес, который вы использовали при регистрации аккаунта GitHub (если он не подтвержден

2. Кликните на свою аватарку в правом верхнем углу, в открывшемся окне выберите Settings (Настройки):

3. Перед вами откроются настройки. В меню слева выберите Developer settings (Настройки разработчика)

4. Перед вами откроются Настройки разработчика. В меню слева выберите Personal access tokens (токены персонального доступа).

5. Нажмите Generate new token (сгенерировать новый токен)

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

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

8. Нажмите Generate token (сгенерировать токен).

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

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

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

2.3. Настройка подключения по SSH

Чтобы настроить подключение по SSH, вам нужно на своем компьютере сгенерировать два SSH-ключа: публичный (public) и секретный (private).

Немного про SSH
Как работает SSH протокол и зачем ему ключи? Если коротко, то публичный ключ передается на удаленный сервер, а секретный все время остается с вами. Удаленный сервер использует публичный ключ, чтобы удостовериться, что у вас действительно есть секретный ключ. Как только сервер убеждается в наличии у вас секретного ключа, он понимает, что вы – это вы, ведь секретный ключ нельзя подделать.

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

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

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

1. Откройте Git Bash (или терминал, если вы работаете на Linux/MacOS)
2. Выполните в нем команду ssh-keygen -t rsa 4096 -C «<ваша-почта>@example.com»
2.1. Вам предложат ввести путь к директории, в которой будет сохранен ключ, а также будет выведена директория для сохранения по умолчанию. Нажмите Enter, чтобы выбрать директорию по умолчанию, либо введите любую другую директорию и тоже нажмите Enter.
2.2. Затем вам предложат ввести пароль для файла с секретным ключом. Нажмите Enter, чтобы оставить файл без пароля, либо введите пароль и нажмите Enter.
3. Теперь нужно добавить ключ в SSH-агента. Запустим агента командой eval `ssh-agent -s`
4. Теперь выполните команду ssh-add <путь до приватного ключа>. Если вы оставили путь по умолчанию, ваша команда будет выглядеть так: ssh-add ~/.ssh/id_ed25519
5. Отлично, последний этап: добавляем публичный ключ на GitHub. Для этого откройте файл с публичным ключом (он должен иметь расширение .pub). Если вы оставили путь по умолчанию, то ваш ключ будет располагаться по адресу ~/.ssh/id_ed25519.pub.
6. Скопируйте содержимое файла.
7. Перейдите в настройки GitHub
8. Откройте раздел SSH and GPG keys (ssh и gpg ключи)

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

11. Скопированный ключ вставьте в раздел Key (ключ)
12. Нажмите Add SSH key (добавить ssh-ключ)
13. Возможно потребуется ввести пароль для подтверждения действия.

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

2.4. Отключение удаленного репозитория от локального. Команда git remote remove.

Иногда возникает необходимость забыть удаленный репозиторий. Для этого существует команда git remote remove.

Команда git remote remove

Данная команда предельно проста в использовании. В качестве имени репозитория нужно передавать то имя, которое вы указывали в команде git remote add. Заметьте, данная команда не удаляет удаленный репозиторий с сервера, она удаляет только подключение вашего репозитория к удаленному.

2.5. Изменение имени удаленного репозитория. Просмотр всех удаленных репозиториев. Команды git remote rename, git remote show.

Иногда возникает необходимость переименовать удаленный репозиторий. Для этого существует команда git remote rename.

Команда git remote rename

Еще более частая задача – просмотреть список всех подключенных удаленных репозиториев и получить информацию о каждом из них. Для этого существует команда git remote show.

Команда git remote show

Таким образом можно просмотреть информацию о каждом из подключенных удаленных репозиториев.

Клонирование удаленного репозитория.
Команда git clone.

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

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

Команда git clone

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

Заметьте, что клонирование по https возможно вообще всегда, а по ssh – нет. Чтобы клонировать репозитории по ssh, нужно, чтобы владелец удаленного репозитория на GitHub добавил к себе публичный ssh-ключ из пары, в то время, как секретный ssh-ключ от той же пары хранится у вас на компьютере, с которого вы выполняете git clone. Таким образом, если вы настроили ssh в своем аккаунте, то вы сможете беспрепятственно клонировать свои репозитории и по https, и по ssh. Но если вы пытаетесь клонировать чужой репозиторий по ssh, то скорее всего получите ошибку доступа.

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

Давайте на примере разберем, как происходит клонирование. Клонируем уже знакомый нам репозиторий geometric_lib. При выполнении команды git сlone https://github.com/smartiqaorg/geometric_lib.git произойдет следующее:

1. В директории, откуда вы запустили команду git clone, создается директория с именем репозитория. В нашем случае, если мы выполнили команду из директории пользователя, будет создана папка C:userssmartiqageometric_lib.
2. В созданную директорию копируется репозиторий, все его ветки и коммиты.
3. В новосозданный локальный репозиторий добавляется удаленный репозиторий с именем origin и ссылкой, которую мы передавали в git clone. Это избавляет нас от необходимости вручную писать git remote add origin https://github.com/smartiqaorg/geometric_lib.git. На этом процесс клонирования заканчивается.

Кстати
Вместо git clone можно было бы создать пустой локальный git-репозиторий, выполнив команду git init. Затем подключить наш удаленный репозиторий командой git remote add origin https://github.com/smartiqaorg/geometric_lib.git. После чего вручную загрузить изменения с удаленного репозитория командой git pull, которую мы рассмотрим ниже. Но зачем делать что-то вручную, если для этого есть автоматизированный инструмент из коробки.

Получение изменений из удаленного репозитория. Команда git fetch

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

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

Итак, чтобы получить изменения из удаленного репозитория, в Git предусмотрена команда git fetch.

Команда git fetch

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

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

├── alpha.txt
└── num.txt

* 47573c7 | 2021-05-10 | Initial commit | [Smartiqa] |  (HEAD -> dev, origin/develop)

├── alpha.txt
├── new_file.txt
└── num.txt

* b9ad22e | 2021-05-10 | New commit | [Smartiqa] |  (HEAD -> develop, origin/develop)
* 47573c7 | 2021-05-10 | Initial commit | [Smartiqa] |

Как видно, в удаленном репозитории есть один коммит, которого нет у нас. В этом коммите был добавлен файл new_file.txt. Кроме того видно, что наша копия удаленной ветки origin/dev находится на первом коммите, хотя должна быть на втором. Чтобы обновить информацию для этой ветки, нам и понадобится git fetch. Выполним команду git fetch origin:

$ git fetch origin
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), 287 bytes | 143.00 KiB/s, done.
From github.com:smartiqaorg/test-repo
   47573c7..b9ad22e  develop -> origin/develop

В выводе команды видно, что она скачала несколько объектов, а из последней строчки мы узнаем, что ветка develop удаленного репозитория была записана в ветку origin/develop на нашем компьютере.

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

├── alpha.txt
└── num.txt

* b9ad22e | 2021-05-10 | New commit | [Smartiqa] |  (origin/develop)
* 47573c7 | 2021-05-10 | Initial commit | [Smartiqa] |  (HEAD -> develop)

На первый взгляд может показаться, что произошло что-то очень странное: новый коммит появился, а файл, который он добавляет – нет. На самом деле, файл тоже появился, просто рабочая копия не была обновлена. Это видно и из истории репозитория: у нас есть две отдельные ветки: develop и origin/develop. Причем указатель HEAD, который, как мы помним, отвечает за состояние рабочей копии, находится на ветке develop. Что ж, давайте попробуем выполнить самое очевидное: переключим HEAD на ветку origin/develop.

$ git checkout origin/develop
Note: switching to 'origin/develop'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at b9ad22e New commit

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

├── alpha.txt
├── new_file.txt
└── num.txt

Все как мы и ожидали, новый файл появился в рабочей копии. Но почему мы оказались в состоянии detached HEAD, если переключались на ветку? Все просто: хоть origin/develop и считается веткой, это ветка не нашего, а удаленного репозитория. Если вы сделаете какие-то коммиты или как-то еще попытаетесь изменить ветку origin/develop, все эти изменения будут потеряны при следующем git fetch. Файл .git/refs/remotes/origin/develop, в котором хранится хэш коммита, на который указывает ветка origin/develop, будет просто переписан. В него запишется тот хэш, на который указывает ветка удаленного репозитория. Все коммиты, которые вы самостоятельно сделали на этой ветке, будут утеряны: на них не останется ссылок. Отсюда и состояние detached HEAD.

Но что же делать, – спросите вы, – как объединить две ветки в одну? В прошлом уроке мы изучили специально созданную для этого команду – git merge.

# Переключимся обратно на ветку develop
$ git checkout develop
Switched to branch 'develop'
Your branch is behind 'origin/develop' by 1 commit, and can be fast-forwarded.
  (use "git pull" to update your local branch)

# Сольем ветку origin/develop в ветку develop
$ git merge origin/develop
Updating 47573c7..b9ad22e
Fast-forward
 new_file.txt | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 new_file.txt

После выполнения git checkout даже сам Git напомнил нам, что наша ветка отстает от origin/develop на 1 коммит. Правда, он посоветовал выполнить git pull вместо git merge, но уже в следующем разделе мы поймем, что это одно и то же.

Кстати, в выводе команды git merge можно заметить, что слияние прошло в fast-forward режиме. Именно поэтому не было создано merge-коммита. На самом деле, слияние удаленной ветки очень часто можно выполнить в fast-forward режиме, но иногда все-таки приходится разрешать конфликты и создавать merge-коммиты.

Подведем итог
Команда git fetch используется для синхронизации локальных ссылочных объектов с этими же объектами в удаленном репозитории. Рабочую копию она не меняет.
Чтобы синхронизировать локальную рабочую копию с удаленным репозиторием, нужно слить удаленные ветки в локальные. Сделать это можно уже знакомой командой git merge.

Получение изменений из удаленного репозитория. Команда git pull

Связкой git fetch && git merge мы получили изменения из удаленного репозитория и обновили свою рабочую копию. Часто вместо этого хочется получать изменения и сразу обновлять рабочую копию так, чтобы она соответствовала удаленному репозиторию. И для этого в Git существует отдельная команда. Называется она git pull.

Команда git pull

На самом деле, новых команд здесь нет. Команда git pull это просто сокращение последовательного применения git fetch и git merge. Но используется git pull намного чаще.

Подведем итог
Команда git pull используется для синхронизации локальной рабочей копии и всех ссылочных объектов с удаленным репозиторием.
По сути, git pull — это то же самое, что git fetch + git merge.

Отправка изменений в удаленный репозиторий. Команда git push

Мы знаем почти все про удаленный репозиторий. Осталось изучить, как загружать в него свои локальные изменения. Для этого в Git существует команда git push.

Команда git push

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

Давайте более подробно разберем, как работает эта команда. Допустим, мы выполнили git push origin develop в нашем локальном репозитории. Возможны три варианта развития событий.

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

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

Но если вы вдруг передали флаг —force, то все коммиты, которых нет в вашем локальном репозитории, будут удалены. То есть удаленный репозиторий станет точной копией вашего локального. Есть более щадящая версия этого флага – —force-with-lease. Он будет делать в точности то же самое, но если вдруг нужно будет удалить коммит, созданный не вами, выполнение немедленно прекратится и вернется ошибка. Таким образом, вы не попадете в ситуацию, когда вы случайно удалили чужой коммит.

GitHub. Работа с репозиторием,
создание форков и пулл-реквестов

Научившись работать с локальным репозиторием, освоим основы работы с GitHub. Итак, если коротко, то GitHub – это, наверное, самый популярный сервис бесплатного хостинга удаленных репозиториев с множеством дополнительных функций. Среди них есть, например, создание issue – запросов, в которых можно сообщить разработчикам об ошибках, создание репозиториев-форков и пулл-реквестов. Кроме того, на GitHub можно подписаться на обновления какого-то конкретного пользователя или включить отслеживание репозитория вашего любимого проекта. Все это превращает GitHub в настоящую социальную сеть для разработчиков по всему миру. Давайте приступим к изучению основ работы с этим сервисом.

7.1 Создание репозитория на GitHub

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

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

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

1. Итак, первое поле Repository name – имя репозитория. Здесь все просто, вам нужно придумать имя, которое будет отображаться на странице вашего репозитория. Здесь нет никаких ограничений, но старайтесь давать как можно более содержательные имена своим репозиториям.
2. Второе поле – Description – описание. Его заполнять необязательно. Но другим пользователям, которые попали на страницу вашего репозитория, будет проще понять, что перед ними, если вы заполните графу описания.
3. Затем вы можете выбрать, будет ли репозиторий открытым, то есть доступным абсолютно всем пользователям GitHub, или закрытым, то есть доступным только вам и людям, которым вы предоставите доступ.
4. Последние три поля предлагают нам добавить, соответственно, README-файл, .gitignore файл и выбрать лицензию для нашего проекта.

После заполнения полей страница выглядит примерно так.

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

Завершим процесс создания репозитория, нажав кнопку Create repository.

7.2 Страница репозитория на GitHub.

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

Как видно из рисунка, GitHub автоматически создал первый коммит, добавив в него файл .gitignore и файл README.

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

В верхнем меню мы видим 9 разных вкладок. Давайте разберем их по порядку.

1. Вкладка Code. Сейчас открыта именно она. В ней содержится рабочая копия нашего репозитория (по центру), описание (справа), вывод файла README (под рабочей копией), история коммитов, а также кнопки для клонирования репозитория и просмотра файлов.
2. Вкладка Issues. В этой вкладке будут отображаться все запросы, сделанные другими пользователями. Как правило, пользователи используют запрос, чтобы сообщить о найденном баге, либо чтобы задать какой-то вопрос о вашем приложении.
3. Вкладка Pull-requests. На этой вкладке будут отображаться все пулл-реквесты, сделанные другими пользователями. О том, что такое пулл-реквесты, мы поговорим ниже.
4-5. Вкладки Actions и Project относятся скорее к системе CI/CDI, которую предоставляет GitHub, в этом курсе мы не будем затрагивать их.
6. Вкладка Wiki открывает вам доступ к созданию и размещению документации о собственном проекте.
7. На вкладке Security содержатся различные настройки безопасности вашего проекта. Там же можно включить инспекцию вашего кода, чтобы узнать, если вы случайно загрузите какой-нибудь секретный токен на GitHub.
8. Вкладка Insight содержит различную информацию и статистические данные об активности репозитория. Там вы сможете посмотреть на зависимость количества коммитов в репозитории от времени или на процент коммитов, сделанных вами.
9. Последняя вкладка – Settings. В ней находятся различные настройки вашего репозитория. Там вы можете поменять видимость репозитория, сделав его частным, или вовсе удалить репозиторий.

7.3. Создание форка репозитория на GitHub. Пулл-реквесты.

Итак, одной из самых важных частей GitHub является создание форков.

“

Форк (от англ. fork – вилка) – точная копия репозитория, но в вашем аккаунте. Форки нужны, чтобы вносить свои изменения в проект, к репозиторию которого у вас нет прямого доступа.

“

Пулл-реквест (от англ. pull-request – запрос pull) – функция GitHub, позволяющая попросить владельца репозитория, от которого мы сделали форк, загрузить наши изменения обратно в свой репозиторий.

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

Теперь давайте рассмотрим пайплайн контрибуции (англ. contribution – внесение вклада) на примере реального репозитория. То есть научимся вносить свой вклад в разработку проектов с открытым исходным кодом на GitHub.

1. Для начала зайдем на страницу репозитория проекта. Нажимаем на кнопку Fork, как показано на картинке. После этого Git создаст точную копию этого репозитория в вашем аккаунте.

2. Клонируем репозиторий к себе на компьютер командой git clone. Создадим файл README.md с описанием проекта, чтобы другим пользователям было понятно, в чем отличие этой реализации от остальных.

3. Сделаем коммит и выполним git push, чтобы загрузить наши изменения в удаленный репозиторий.

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

5. Нажимаем на кнопку Compare на подсказке GitHub, либо переходим на вкладку Pull Requests и нажимаем New pull request.

6. Перед нами откроется страница создания пулл-реквеста.

Здесь мы можем просмотреть внесенные изменения и выбрать две ветки: одну в исходном репозитории, на нее будут залиты наши изменения, вторую – в нашем репозитории, с нее будут скачаны изменения. Как только мы выбрали ветки и убедились, что не внесли никаких лишних изменений, нажимаем кнопку Create pull request.

7. Теперь мы попадаем на страницу описания наших изменений.

Здесь необходимо описать, что за изменения вы внесли и почему они были необходимы. Сообщение, которое оставили мы, видно на картинке. Оно отражает суть и необходимость внесенных изменений. Как только мы закончили с описанием, можно нажимать кнопку Create pull request.

8. Теперь мы попадаем на страницу уже созданного пулл-реквеста в изначальном репозитоии. В нашем случае он выглядит так.

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

Подытожим
Таким образом, вы можете вносить свой вклад в абсолютно любые приложения с открытым программным кодом. Даже репозиторий самого Git хранится на GitHub, и вы в любой момент можете сделать форк и придумать новую команду (правда не факт, что ответственный примет ваш пулл-реквест). Вы можете внести свой вклад в разработку ядра Linux, в популярный редактор Visual Studio Code, в ядро криптовалюты Bitcoin, в языки программирования Python, Go, Ruby – все эти проекты имеют открытые репозитории на GitHub.

Модель ветвления Git

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

8.1. Центральный репозиторий

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

Центральный репозиторий на картинке назван origin. Как мы уже упоминали выше, это одно из общепринятых наименований в Git.

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

8.2. Основные ветки

В нашей модели существуют две главные ветки:

1. main – ветка, в которой содержится только код, готовый к релизу.
2. develop – ветка, в которой содержатся изменения, готовые ко включению в последующий релиз.

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

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

Таким образом, коммит в ветке origin/main означает выпуск нового релиза. Кстати, если строго придерживаться этого правила, можно организовать непрерывную интеграцию при помощи как встроенных средств GitHub, так и сторонних инструментов, специализирующихся на CI/CDI.

8.3. Вспомогательные ветки

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

Наша модель предполагает существование следующих групп вспомогательных ветвей:

1. Ветви для разработки новых функций. Они же feature branches.
2. Ветви релизов, то есть release branches.
3. Ветви срочных исправлений – hotfix branches.

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

8.4. Feature-ветки

Могут порождаться от: develop
Могут вливаться в: develop
Правило именования: любое имя, кроме main, develop, release-*, hotfix-*.

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

Feature-ветки существуют в основном только в репозиториях разработчиков, но могут на некоторое время появиться и в центральном репозитории.

Графически взаимодействие разработчика с feature-веткой выглядит примерно так:

Создать feature-ветку можно следующим образом:

# Переключимся на главную ветвь develop
$ git checkout develop
# Создадим feature-ветку
 $ git checkout -b new-feature

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

# Переключимся на главную ветвь develop
$ git checkout develop
# Сольем нашу feature-ветку явным образом
 $ git merge --no-ff new-feature
# Удалим нашу feature-ветку
 $ git branch -d new-feature
# Выполним пуш изменений в основной репозиторий
 $ git push origin develop

Заметьте, мы специально выполнили merge в режиме non-fast-forward. Дело в том, что хоть fast-forward и удобнее в некоторых случаях, в данном все же лучше использовать явное слияние. Явное слияние позволяет сохранить информацию о том, что ветка new-feature существовала, и объединяет все ее коммиты в один merge-коммит. Впоследствии это позволит разобраться, какие коммиты отвечают за добавление одних и тех же функций. Кроме того, сливая ветку явным образом, мы оставляем себе обходной путь: отменить такое слияние намного проще, чем отменять слияние fast-forward.

8.5. Release-ветки

Могут порождаться от: develop
Могут вливаться в: develop, main
Правило именования: release-*

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

Решение о номере версии релиза принимается только после создания release-ветки и опирается на принятые в компании правила нумерации версий. До тех пор неясно, будет ли новый релиз иметь версию 4.1.5, 4.2 или 5.0. Создать release-ветку можно следующим образом.

# Переключимся на главную ветвь develop
$ git checkout develop
# Создадим release-ветку
 $ git checkout -b release-4.2

Заметьте, мы приняли решение, что новая версия будет иметь номер 4.2, а потому создали ветку с именем release-4.2. Работая в этой ветке, мы можем исправить незначительные ошибки и внести метаинформацию о версии проекта в соответствующие файлы. Обратите внимание, что на этой ветви запрещено вносить какие-то крупные изменения или исправлять серьезные ошибки, ее предназначение не в этом.

Как только все файлы вашего проекта будут готовы к выпуску релиза, данную ветвь можно слить в основную ветку main, что и будет соответствовать выпуску релиза. После чего нужно пометить релиз соответствующим тегом, чтобы впоследствии к нему было проще обращаться. Важно не забыть слить изменения с release-ветки в ветку develop, чтобы вернуть наши незначительные изменения в процесс разработки следующего релиза.

# Переключимся на основную ветвь main
$ git checkout main
# Сольем в нее нашу release-ветку
$ git merge --no-ff release-4.2
# Присвоим коммиту тег
$ git tag -a v4.2
# Переключимся на основную ветку develop
$ git checkout develop
# Сольем в нее нашу release-ветку, чтобы вернуть внесенные изменения в разработку
$ git merge --no-ff release-1.2
# Теперь можно удалить release-ветку
$ git branch -d release-1.2

8.6. Hotfix-ветки

Могут порождаться от: main
Могут вливаться в: develop, main
Правило именования: hotfix-*

Ветки срочных исправлений или hotfix-ветки, нужны для внесения срочных исправлений в уже вышедший релиз. Такую ветку необходимо создать в ситуации, когда в недавно вышедшем релизе был обнаружен серьезный баг. Предназначение этой ветки – исправить ошибку в последнем вышедшем релизе, а затем выпустить новый релиз, слив ветку hotfix в main и develop. Смысл создания отдельной ветки в том, что работа большей части команды может продолжаться над выходом нового стабильного релиза на ветке develop, пока bugfix-команда работает над исправлением ошибки в последнем релизе в ветке hotfix.

Чтобы создать hotfix-ветку, выполните:

# Переключимся на главную ветвь main
$ git checkout main
# Создадим hotfix-ветку для последнего релиза
 $ git checkout -b hotfix-4.2.1

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

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

# Переключимся на основную ветвь main
$ git checkout main
# Сольем в нее нашу hotfix-ветку
$ git merge --no-ff hotfix-4.2.1
# Присвоим коммиту тег
$ git tag -a v4.2.1
# Переключимся на основную ветку develop
$ git checkout develop
# Сольем в нее нашу hotfix-ветку, чтобы сохранить исправление бага в следующем релизе 
$ git merge --no-ff hotfix-4.2.1
# Теперь можно удалить hotfix-ветку
$ git branch -d hotfix-4.2.1

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

ПРАКТИЧЕСКИЙ БЛОК

Задание

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

Условие

Разбор задания

На странице Задания и Ответы по курсу Git мы даем подробный разбор текущего задания.
Приводим в нем не только команды Git, но и их консольный вывод, а также даем комментарии к каждой команде.

Как вам материал?

Читайте также

• →

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

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

1. Основные термины Git

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

Индекс — это часть локального репозитория (ЛР), хранящая не зафиксированные с помощью команды git add изменения файлов. Еще ее называют областью подготовки файлов. Эту область можно сравнить с черновиком (промежуточным этапом), из которого разработчик по завершению своей работы выбирает, какие изменения нужно зафиксировать (добавить в тот или иной коммит).

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

Коммит (commit) — фиксация изменений, взятых из индекса. Это действие заносит изменения в репозиторий Git. Его можно сравнить со слепком текущего состояния вашего ЛР. Вы берете из черновика (индекса) нужные изменения и коммитите текущее состояние файлов и папок. Это действие похоже на создание точки восстановления в Windows. Каждый коммит также является итогом вашей работы.

Закоммитить/коммитить — зафиксировать изменения, сделать слепок текущего состояния файлов и папок.

Клонирование репозитория (clone) — процесс скачивания копии УР к себе на компьютер. При этом создание ЛР происходит автоматически, без явного ввода git init.

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

Если упрощенно объединить все, что было сказано в этом разделе, то процесс работы с Git сводится к следующим шагам:

Ветка (branch) — это одно из направлений развития вашего проекта. Git позволяет вести параллельную работу (в разных ветках), в рамках одного репозитория, над одними и теми же файлами. У каждой ветки есть имя. Имя основной ветки — master (main).

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

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

2. Создание локального репозитория

В предыдущей статье, с помощью команды git init, мы создали ЛР — место на компьютере для хранения файлов и отслеживания в них любых изменений. Именно с этого шага начинается работа с Git.

Выполните команду git init в корне вашего проекта, как показано в образце ниже, если не делали этого ранее:

D:JavaStartJava
> git init
Initialized empty Git repository in D:/Java/StartJava/.git/

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

3. Связывание удаленного и локального репозитория

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

URL на ваш УР скопируйте, зайдя на github.com и выбрав протокол, который вы настроили для взаимодействия с GitHub в прошлой статье.

В итоге команда будет выглядеть так (используйте ссылку на свой репозиторий!):

> git remote add origin https://github.com/ichimax/startjava2.git

• git — используется приложение git
• remote — управляет удаленным репозиторием
• add — добавляет информацию об УР в ЛР
• origin — общепринятый псевдоним для URL УР
• https://github.com/ichimax/startjava2.git — ссылка на УР

Эту длинную команду можно трактовать так: Git, добавь к себе информацию о связи между УР github.com/ichimax/startjava2.git, которому я хочу дать псевдоним origin, с ЛР.

Проверим, что получилось, введя git remote -v:

> git remote -v
origin  https://github.com/ichimax/startjava2.git (fetch)
origin  https://github.com/ichimax/startjava2.git (push)

Взаимосвязь установлена успешно: напротив псевдонима origin размещается ссылка на УР.

4. Состояние репозитория

Одной из самых популярных и простых команд, которая используется постоянно, является git status. Она показывает в каком состоянии в текущий момент находится ЛР (какие файлы были изменены, что нового добавилось и т. д.).

Файлы в репозитории могут находиться в следующих состояниях:

• не отслеживаемые (untracked) — находящиеся в ЛР, но еще не добавленные в индекс (под версионный контроль). Это могут быть новые файлы
• индексированные (staged) — новые файлы, добавленные впервые в индекс
• зафиксированные (committed) — попавшие в коммит
• измененные (modified) — модифицированные после коммита

Файлы все время меняют свое состояние. Их жизненный цикл повторяется снова и снова.

Введем в консоли git status:

D:JavaStartJava (master)
> git status
On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        about.txt
        src/

nothing added to commit but untracked files present (use "git add" to track)

Команда вывела сообщение, которое означает, что Git видит src и about.txt, но не отслеживает, вносимые в них изменения. В связи с этим, он предлагает добавить файлы в индекс. Тут следует запомнить одну важную деталь: добавленные в репозиторий новые файлы не попадают сразу под версионный контроль. Git их просто видит, но не фиксирует в них изменения.

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

А теперь разберем все, что вывела команда git status:

1. On branch master — [находимся] в ветке master
2. No commits yet — нет коммитов [которые можно запушить]
3. Untracked files — [имеются] неотслеживаемые файлы
4. (use «git add <file>…» to include in what will be committed) — используйте «git add <file> …» для включения файлов в коммит, состояние [изменения] которых нужно зафиксировать.
   Git увидел, что в ЛР есть не занесенные в индекс и незафиксированные изменения. Т.к. он src и about.txt видит впервые, то для него они по умолчанию являются измененными. Поэтому Git предлагает закоммитить (зафиксировать) их текущее состояние, чтобы уже от него учитывать все последующие изменения.
5. nothing added to commit but untracked files present (use «git add» to track) — ничего не добавлено в коммит, но присутствуют не отслеживаемые файлы (для отслеживания используйте «git add»)

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

5. Добавление файлов в индекс

Добавим файлы в индекс, запустив команду git add . (с точкой в конце), а затем снова выполним git status.

D:JavaStartJava (master)
> git add .

D:JavaStartJava (master)
> git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   about.txt
        new file:   src/MyFirstApp.java

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

Если вам требуется добавить вообще все изменения, которые были сделаны в репозитории, начиная с его корня, то для этого нужно использовать параметр -A вместо точки.

В выводимом сообщении произошли изменения: src и about.txt перестали быть untracked, а позеленели и теперь находятся в индексе.

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

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

6. Коммит файлов

Осталось зафиксировать изменения из индекса с помощью команды commit. Это можно сделать двумя основными способами.

6.1. Первый способ

Напишем в консоли команду git commit. Откроется указанный ранее при настройке (установке) текстовый редактор. В нашем случае откроется новая вкладка, содержащая следующий шаблонный текст:

При этом в консоли отобразится текст «hint: Waiting for your editor to close the file…» (благодаря параметру —wait, который мы установили в предыдущей статье).

Текст во вкладке COMMIT_EDITMSG частично напоминает то, что выводил git status. В начале каждой строки идет символ #, говорящий о том, что текст закомментирован и несет только информационную нагрузку. На него можно не обращать внимание (или удалить полностью), он все равно не попадет в коммит или его описание.

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

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

Из заголовка видно, что данный коммит является первым (root-commit), т. к. в нем присутствует слово «Инициализация». Далее указаны пункты с теми изменениями, которые мы внесли в файлы проекта.

Сохраните, а затем закройте вкладку. Git создаст коммит, добавит к нему описание и выведет о нем информацию в консоль:

D:JavaStartJavasrc (master)
> git commit
[master (root-commit) 1e36e0f] Инициализация проекта
 2 files changed, 6 insertions(+)
 create mode 100644 about.txt
 create mode 100644 src/MyFirstApp.java

Сообщение содержит следующие данные о коммите:

• master — для какой ветки он был выполнен
• root-commit — является корневым (первым) коммитом
• 1e36e0f — уникальный идентификатор (контрольная сумма)
• Инициализация проекта — описание (заголовок). При этом другие пункты — не отображаются
• 2 files changed — количество измененных файлов
• 6 insertions(+) — количество добавленных в файлах строк
• create mode 100644 — права доступа к файлам в Unix-стиле

6.2. Второй способ

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

Изменим название файла about.txt на README.md («Прочитай меня») и внесем в него изменения. В этом файле принято размещать описание проекта, который находится в репозитории.

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

Изменим имя файла с помощью Git и отобразим результат:

D:JavaStartJava (master)
> git mv about.txt README.md && ls
README.md  src/

Откроем README.md, написав в консоли его имя, и жмем Enter. Затем, используя маркдаун, внесем в него следующие изменения:

# [StartJava](https://topjava.ru/startjava) — курс на Java для начинающих

## Используемые на курсе инструменты и технологии

1. Java
1. Git/GitHub
1. Командная строка
1. Sublime Text
1. Intellij IDEA
1. SQL
1. PostgreSQL
1. psql

Отобразим данный файл в браузере. Для этого необходимо нажать Ctrl + Shift + P, написать preview и выбрать первую строку с надписью «MarkDown Preview: Preview in Browser» (при этом пакет Markdown Preview должен быть установлен):

Откроется страница в браузере с отформатированным текстом:

Далее проверим статус файла (вывод дан в сокращенном виде):

D:JavaStartJava (master)
> git status
Changes to be committed:
        renamed:    about.txt -> README.md

Changes not staged for commit:
        modified:   README.md

Видим, что Git сам переименовал about.txt в README.md, а также пометил README.md как измененный.

Добавим все изменения в индекс, выполнив команду git add README.md с явным указанием имени измененного файла.

Перед тем как выполнить коммит, посмотрим, какие изменения мы хотим зафиксировать. Для этого пишем git status -v (вывод дан в сокращенном виде):

> git status -v

Changes to be committed:
        new file:   README.md
        deleted:    about.txt

diff --git a/README.md b/README.md
+++ b/README.md

+# [StartJava](https://topjava.ru/startjava) — курс на Java для начинающих
+
+## Используемые на курсе инструменты и технологии
+
+1. Java
+1. Git/GitHub
+1. Командная строка
+1. Sublime Text
+1. Intellij IDEA
+1. SQL
+1. PostgreSQL
+1. psql

diff --git a/about.txt b/about.txt
--- a/about.txt
-Интенсив StartJava - программирование на Java для начинающих!

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

Плюсом обозначаются добавленные в файл строки (выделены зеленым), а минусом удаленные (красные).

> git commit -m "Переименовал about.txt в README.md и внес в него описание проекта"
[master 39ba195] Переименовал about.txt в README.md и внес в него описание проекта
 2 files changed, 12 insertions(+), 1 deletion(-)
 create mode 100644 README.md
 delete mode 100644 about.txt

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

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

В каких случаях и как часто необходимо делать коммит:

• вы закончили создание нового функционала
• вы завершили запланированное исправление ошибок в коде
• в конце рабочего дня

Дополнительные правила создания коммита смотрите по ссылке.

7. Список коммитов

Чтобы посмотреть список (историю) всех имеющихся коммитов, воспользуемся командой git log (1, 2):

> git log
commit 39ba195cf96f555aaf2d9f0a2f3ffcfb37e0c536 (HEAD -> master)
Author: ichimax <myEmail>
Date:   Thu Sep 22 16:31:55 2022

    Переименовал about.txt в README.md и внес в него описание проекта

commit 1e36e0f6daf70d936627c444f8cb082bfffb9b17
Author: ichimax <myEmail>
Date:   Thu Sep 22 13:02:17 2022

    Инициализация проекта

    - добавил файл с описанием проекта
    - добавил реализацию первого класса
(END)

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

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

Информация к коммиту в себя включает следующие метаданные:

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

С помощью git log можно выводить информацию о конкретном количестве коммитов, а также видеть все изменения, содержащиеся в них:

Параметр -p позволяет отображать изменения (что добавили в файлы, что удалили), а -1 отвечает за количество отображаемых коммитов (в данном случае — один).

Если вам не требуется выводить подробную информацию по каждому коммиту, то можно воспользоваться сокращенным выводом с помощью опции —oneline, которая выводит каждый коммит в одну строку:

> git log --oneline
39ba195 (HEAD -> master) Переименовал about.txt в README.md и внес в него описание проекта
1e36e0f Инициализация проекта

8. Отправка коммитов на удаленный репозиторий

Сейчас оба наших коммита являются локальными — находятся в директории .git у вас на компьютере. Необходимо их загрузить (запушить) на УР на GitHub, используя команду push.

Предварительно введем git status:

> git status
On branch master
nothing to commit, working tree clean

Видим, что коммитить нам нечего, файлов, которые нужно добавить в индекс тоже нет. Выполним пуш, введя команду git push -u origin master:

> git push -u origin master
Enumerating objects: 8, done.
Counting objects: 100% (8/8), done.
Delta compression using up to 8 threads
Compressing objects: 100% (7/7), done.
Writing objects: 100% (8/8), 1.17 KiB | 238.00 KiB/s, done.
Total 8 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/ichimax/startjava2.git
 * [new branch]      master -> master
branch 'master' set up to track 'origin/master'.

Данная команда помимо того, что отправит на удаленный репозиторий коммиты, установит связь (с помощью параметра -u) между локальной и удаленной веткой master. В будущем, чтобы сделать пуш, достаточно будет ввести git push. Все остальные параметры указывать уже не обязательно.

После пуша, зайдите на ваш репозиторий на GitHub и убедитесь, что src/MyFirstApp.java и README.md были загружены.

9. Подтягивание изменений с УР

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

Или возможна другая ситуация, когда над проектом работает команда программистов, каждый из которых вносит изменения в файлы и пушит их на УР.

Дома, вы открываете свой проект и хотите продолжить над ним работу. И тут вам приходит в голову мысль, а как мне получить с УР все изменения, которые сделали как вы, так и другие программисты, чтобы ваш домашний ЛР был в актуальном состоянии?

Для этого в Git предусмотрена команда pull, которая скачивает с GitHub к вам на компьютер все коммиты, которых нет в вашем ЛР.

Для простоты эксперимента внесем изменения прямо на GitHub (да, это возможно) и подтянем их в свой ЛР.

Изменим код в файле MyFirstApp.java на следующий:

public class MyFirstApp {
    public static void main(String[] args) {
        System.out.print("Написано однажды, ");
        System.out.println("работает везде!");
    }
}

Пример того, как это можно сделать на GitHub, включая создание коммита:

Затем подтянем новый коммит в ЛР:

> git pull
remote: Enumerating objects: 7, done.
remote: Counting objects: 100% (7/7), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 4 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (4/4), 942 bytes | 40.00 KiB/s, done.
From https://github.com/ichimax/startjava2
   39ba195..b59d871  master     -> origin/master
Updating 39ba195..b59d871
Fast-forward
 src/MyFirstApp.java | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Теперь количество коммитов в ЛР и УР совпадают — ЛР содержит данные в актуальном состоянии. Можно спокойно продолжить работу.

Выполняйте команду git pull всякий раз перед тем, как начинаете работать над своим проектом (пишите код, вносите какие-то изменения). Эта привычка защитит вас от множества проблем.

10. Клонирование репозитория

После того, как ваш (или чей-то) проект оказался на GitHub, любой желающий может скачать его копию с помощью git clone.

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

D:Java
> git clone https://github.com/ichimax/Java-Style-Guide.git
Cloning into 'Java-Style-Guide'...
remote: Enumerating objects: 69, done.
remote: Counting objects: 100% (69/69), done.
remote: Compressing objects: 100% (66/66), done.
Receiving objects:  33% (23/69)
Receiving objects: 100% (69/69), 22.24 KiB | 1.71 MiB/s, done.
Resolving deltas: 100% (19/19), done.

При этом новый ЛР создастся автоматически с уже прописанным УР и будет содержать всю историю изменения проекта.

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

> cd Java-Style-Guide && ls -a && git status && git remote -v
./  ../  .git/  guide.md  README.md
On branch main
Your branch is up to date with 'origin/main'.
nothing to commit, working tree clean
origin  https://github.com/ichimax/Java-Style-Guide.git (fetch)
origin  https://github.com/ichimax/Java-Style-Guide.git (push)

11. Игнорирование файлов и папок

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

Давайте поэкспериментируем, создав условия для использования данного файла. Самое простое, что мы можем сделать — это скомпилировать MyFirstApp.java, чтобы в репозитории появился class-файл. Делать это мы уже умеем (если кто-то пропустил, то данная тема разбиралась ранее).

> javac MyFirstApp.java && ls
MyFirstApp.class  MyFirstApp.java

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

На GitHub нужно хранить только разные версии ваших файлов к которым в будущем можно вернуться (откатиться). class-файлы нужны только для запуска программ. Для версионного контроля они не представляют никакой ценности.

Создадим .gitignore в корне нашего проекта:

D:JavaStartJava (master -> origin)
> touch .gitignore

Отобразим все файлы и папки:

> tree /F
D:.
│   .gitignore
│   README.md
│
└───src
        MyFirstApp.class
        MyFirstApp.java

Не лишним будут посмотреть статус репозитория:

> git status
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        .gitignore
        src/MyFirstApp.class

Репозиторий содержит два новых неотслеживаемых файла. Один из них нужно игнорировать (чтобы Git его даже не отображал).

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

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

*.class
*.DS_Store
*.iml
out/
lib/
.idea/

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

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

Снова проверим статус репозитория:

> git status

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        .gitignore

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

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

git add .
git commit -m "Добавил .gitignore с шаблоном *.class"
git push
git log --oneline

12. Список команд

Список команд, разобранных в статье, с кратким описанием.

Заключение

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

Оцените статью, если она вам понравилась!