Как скачать репозиторий с github windows

1. On GitHub.com, navigate to the main page of the repository.

2. Above the list of files, click Code.
   

3. Copy the URL for the repository.

   • To clone the repository using HTTPS, under «HTTPS», click .
   • To clone the repository using an SSH key, including a certificate issued by your organization’s SSH certificate authority, click SSH, then click .
   • To clone a repository using GitHub CLI, click GitHub CLI, then click .
     

4. Open TerminalTerminalGit Bash.

5. Change the current working directory to the location where you want the cloned directory.

6. Type git clone, and then paste the URL you copied earlier.

   $ git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY

7. Press Enter to create your local clone.

   $ git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY
   > Cloning into `Spoon-Knife`...
   > remote: Counting objects: 10, done.
   > remote: Compressing objects: 100% (8/8), done.
   > remove: Total 10 (delta 1), reused 10 (delta 1)
   > Unpacking objects: 100% (10/10), done.

To clone a repository locally, use the repo clone subcommand. Replace the repository parameter with the repository name. For example, octo-org/octo-repo, monalisa/octo-repo, or octo-repo. If the OWNER/ portion of the OWNER/REPO repository argument is omitted, it defaults to the name of the authenticating user.

gh repo clone REPOSITORY

You can also use the GitHub URL to clone a repository.

gh repo clone https://github.com/PATH-TO/REPOSITORY

1. On GitHub.com, navigate to the main page of the repository.
2. Above the list of files, click Code.
   
3. Click Open with GitHub Desktop to clone and open the repository with GitHub Desktop.
   
4. Follow the prompts in GitHub Desktop to complete the clone.

For more information, see «Cloning a repository from GitHub to GitHub Desktop.»

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

Участвовать

Download Article

Download Article

When you view individual files on GitHub, you’ll notice the button to download the code isn’t there. You’ll instead see the download button on the right side of the page when you navigate to the root of the repository. This wikiHow will teach you how to download files from GitHub by changing to the Raw version of the file.

Advertisement

Thanks for submitting a tip for review!

About This Article

Article SummaryX

1. Go to https://github.com/ in a web browser.

2. Navigate to the file you want to download.
3. Click Releases (if it’s available).

4. Click Go to file.

5. Click to select a file that you want to download.

6. Click Raw .

7. Right-click the page and click Save as.

Thanks to all authors for creating a page that has been read 362,452 times.

Download Article

Download Article

When you view individual files on GitHub, you’ll notice the button to download the code isn’t there. You’ll instead see the download button on the right side of the page when you navigate to the root of the repository. This wikiHow will teach you how to download files from GitHub by changing to the Raw version of the file.

Advertisement

Thanks for submitting a tip for review!

About This Article

Article SummaryX

1. Go to https://github.com/ in a web browser.

2. Navigate to the file you want to download.
3. Click Releases (if it’s available).

4. Click Go to file.

5. Click to select a file that you want to download.

6. Click Raw .

7. Right-click the page and click Save as.

Thanks to all authors for creating a page that has been read 362,452 times.

➜  ~ 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

apt-get update -y
apt-get install git
git clone https://github.com/Red-company/RDDoS_Tool.git
cd RDDoS_Tool
bash setup.sh
python3 RDDoS_Tool.py

git clone https://github. com/Red-company/RDDoS_Tool. git

cd RDDoS_Tool

pip install tqdm
pip install pyfiglet

python3 RDDoS_Tool. py

apt-get update -y
apt-get install git
git clone https://github.com/Red-company/RDDoS_Tool.git
cd RDDoS_Tool
bash setup.sh
python3 RDDoS_Tool.py

• 1. Это обновление пакетов, вам нужно посмотреть как обновлять пакеты на вашем линукс-дистрибутиве(разновидность ОС Linux) и обновить

• 2. Установка GIT и опять же посмотрите, как установить GIT на вашем дистрибутиве линукс

• 3.Установка утилиты, тут по аналогии с виндовс действуем:

git clone https://github. com/Red-company/RDDoS_Tool. git

pip install tqdm
pip install pyfiglet

sudo apt install python

python3 RDDoS_Tool. py

apt-get update -y
apt-get install git
git clone https://github.com/Red-company/RDDoS_Tool.git
cd RDDoS_Tool
bash setup.sh
python3 RDDoS_Tool.py

brew update
brew install git
git clone https://github.com/Red-company/RDDoS_Tool.git
cd RDDoS_Tool
bash setup.sh
python3 RDDoS_Tool.py

brew install python git python-pip

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

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, но и их консольный вывод, а также даем комментарии к каждой команде.

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

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