Урок 3. Git и Github. Создание репозитория


Содержание материала:

GitHub и Git — создание и работа с репозиторием

August 30, 2014

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

Вот такие получаются шаги, которые нужно осветить. Profit у всех этих сложностей, описанных мною выше, один — но большой! Заключается он в том, что проект, над которым вы работаете (даже в гордом одиночестве) находится на удаленном сервере, к которому можно подключиться из любого места и с любой машины. Так как он находиться на remote server, то с ним ничего не случиться, даже если ваша машина упадет\утонет\разобьется.

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

Все действия, описанные в этой статье, будут производиться под операционной системой Linux Mint 17 Cinnamon, в консоли. Поэтому пользователи Mac OS X найдут для себя почти все идентичным. Система Windows остается в стороне.

Создание SSH-ключей под Linux

Первоначально необходимо создать (если их еще нет) ssh-ключи, которые будем использоваться для авторизации на GitHub. В системе Linux такие ключи расположены в домашней директории пользователя и выглядят примерно так:

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

Если показанная выше команда “скажет” вам, что директории не существует, то это означает, что у вас с системе установлен пакет SSH, отвечающий за создание и обработку ssh-ключей.

Установка пакета SSH

Под Linux Mint его нужно установить командой:

Создание пары ssh-ключей

Теперь можно приступать к созданию пары ssh-ключей. Выполняется это командой:

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

Обязательный параметр — электронный адрес, к которому “привязывается” создаваемый ssh-ключ; данный email будет также использоваться мною для регистрации на GitHub.

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

Утилита задаст еще один вопрос, который крайне не рекомендуется игнорировать:

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

После успешного ввода ssh-ключи будут созданы:

В состав пакета входит утилита , задача которой в управлении созданными ssh-ключами. Передадим ей в пользование только созданные мною ssh-ключи:

Можно посмотреть, что утилита “подхватила” и распознала предоставленные ею ssh-ключи:

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

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

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

Добавление ssh-ключа на GitHub

Переходим на сервис GitHub и создаем на нем новую учетную запись. Описывать процесс создания такой записи на GitHub не буду, так как там все просто. Более интересный момент — это добавление ssh-ключа в профиль пользователя GitHub.

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

Откроется окно для добавления новых ssh-ключей в учетную запись пользователя на GitHub. Здесь все элементарно просто — нажимаем кнопку . В поле вводим название (произвольное) для импортируемого ssh-ключа.

В поле просто нажимаем Ctrl+V — содержимое буфера обмена (которое я получил ранее с помощью утилиты ) вставиться в это поле:

Жму на зеленую кнопку внизу окна. Ключ добавлен на GitHub и появиться в списке SSH-ключей:

Проверка SSH-соединения с GitHub

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

Для этой цели ввожу команду:

На ошибку в строке не стоит обращать внимание. В запросе командной строки печатаем и получаем:

Отлично! GitHub “узнал” меня и поприветствовал в строке . Это говорит о том, что ssh-соединение моей машины с GitHub установлено успешно и GitHub авторизует меня.

Однако, при настройке ssh-соединения возможны и ошибки. В этом случае может помочь статья — Error: Permission denied (publickey).

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

Создаем новый репозиторий на GitHub. Ввожу новое уникальное имя для репозитория, краткое его описание и включаю галочку “Initialize this repository with a README”:

Отлично! На GitHub я только что создал новый репозиторий . Теперь можно скопировать (склонировать) его на свою локальную машину командами:

Переходим в локальную копию репозитория . Вношу изменения, а затем последовательно:

Команда фиксирует изменения в локальном репозитории. Команда отправляет внесенные и зафиксированные изменения в локальном репозитории на удаленный репозиторий.

Вот, таким образом я наладил Git-работу своей машины с GitHub.

RxJs — map

Первый «серьезный» метод в моей RxJs-копилке знаний. На самом деле все просто — этот метод получает на вход поток, обрабатывает каждый ev. … Continue reading

Как создать новый репозиторий в Git

В данной статье мы рассмотрим, как создать новый пустой Git репозиторий. Мы создадим локальный репозиторий, а также рассмотрим, как создать удаленный репозиторий на примере Github.

Как создать новый пустой репозиторий

Создайте пустую директорию для вашего будущего репозитория и перейдите в нее:

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

В результате будет создан новый локальный пустой репозиторий. На экран будет выведено сообщение вида:

В директории myproject появится скрытая папка .git. Ее можно увидеть, выполнив команду ls -al

Как создать репозиторий из существующих файлов

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

Теперь можно добавить все файлы в индекс и сделать первый коммит:

Как создать удаленный репозиторий (на примере Github)

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

Перейдите на https://githib.com и войдите в свой аккаунт. Нажмите кнопку New repository (Новый репозиторий). На открывшейся странице введите имя репозитория (Repository name) и нажмите кнопку Create repository.

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

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

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

Вам нужно будет ввести логин и пароль аккаунта в Github. Результат команды будет примерно следующим:

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

Git для начинающих. Часть 5. Создание репозитория и первый коммит

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

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

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

Теперь перейдем в этот каталог.

Создадим в нем пустой git репозиторий.

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

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

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

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

Теперь, если мы выполним команду git status , то увидим, что в нашем каталоге появился один неотслеживаемый файл: README.md .

Добавим, созданный файл в stage . Stage (или cache ) – это хранилище для файлов с изменениями, информация о которых попадет в единый коммит. Stage является элементом архитектуры трех деревьев, на базе которой построен git , более подробно смотрите здесь. Для добавления файла README.md в stage необходимо воспользоваться командой git add .

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

Выполним git status для того, чтобы посмотреть на то, что сейчас происходит в нашем каталоге.

Как видно, в stage был добавлен один файл с именем README.md и теперь представленный набор изменений готов к отправке в репозиторий – т.е. к коммиту. Сделаем это.

Проверим статус каталога.

Как видно с момента последнего коммита никаких изменений в рабочем каталоге не производилось.

Теперь взглянем на список коммитов.

Из приведенной информации видно, что был отправлен один коммит, который имеет ID : 500067cc0b80643d38e2a24e9e0699031ada6be3, более подробно об идентификаторах будет рассказано в следующих уроках. Автор данного коммита Writer , он (коммит) был создан Mon Feb 12 22:51:14 2020 +0500, с сообщением: [create repository] . Это довольно подробная информация, когда коммитов станет много, такой формат вывода будет не очень удобным, сокращенный вариант выглядит так.

Подведем небольшое резюме вышесказанному.

Создание пустого репозитория.

Добавление файлов в stage .

Просмотр статуса каталога.

Просмотр коммитов в репозитории.

Просмотр коммитов в репозитории с сокращенным выводом информации.

Отличный курс по git делают ребята из GeekBrains , найдите в разделе “Курсы” курс “Git. Быстрый старт” , он бесплатный!

Урок 3. Git и Github. Создание репозитория

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

Топ-пост этого месяца:  Гугл Адвордс — введение, основы работы и создание кампании в этой системе контекстной рекламы

В статье рассмотрено как создать репозиторий на github, подключиться к нему с локального компьютера и работать с проектом. Используется Ubuntu — с github можно работать также с любой другой Unix машины или Windows.

Установка git и создание локального репозитория

Работаем от имени пользователя root. Прежде всего устанавливаем git

Заходим на https://github.com и создаем пользовательский аккаунт, также создаем в графическом интерфейсе первый репозиторий (называем его test)

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

git config —global user.name «valdes101»

git config —global user.email «[email protected]»

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

переходим в каталог

Initialized empty Git repository in /home/admin/IT/python/py/.git/

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

Как создать репозиторий на github и подключиться к нему

После адреса сайта указываем имя пользователя, затем — через / — название репозитория, .git

git remote add origin https://github.com/valdes101/test.git

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

При этом возникает ошибка:

Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Из ее текста следует, что не добавлен SSH ключ и подключение к удаленному репозиторию невозможно.

Сгенерируем ключ и добавим его в личном кабинете на github

ssh-keygen -t rsa -b 4096 -C «[email protected]»

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):

Вводим путь к ключу на сервере
Enter passphrase (empty for no passphrase):

Парольная фраза и ее повтор
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
72:d6:85:91:09:6d:61:ca:20:01:72:68:75:63:8b:9f [email protected]
The key’s randomart image is:
+—[RSA 4096]—-+
|..+oo=. .o++ |
|.+ +.oo o=o |
|. . . o.. . |
| . . . . |
| E. S . |
| + |
| |
| |
| |
+——————+

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

Добавляем его в .ssh/id_rsa

Identity added: /root/.ssh/id_rsa (rsa w/o comment)

Копируем ключ, начинающийся с ssh-rsa и вставляем его в соответствующее поле в личном кабинете на github

Выбираем «SSH and GPG keys»

Далее New SSH key (на скриншоте ключ уже добавлен)

После этого вновь пробует отправить данные

Counting objects: 3, done.
Writing objects: 100% (3/3), 216 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To [email protected]:valdes101/testrepo.git
* [new branch] master -> master
Branch master set up to track remote branch master from origin.

Все получилось — данные были успешно переданы в удаленный репозиторий.

Проверяем, создаем файл и добавляем в него произвольный текст (в данном случае добавлен «some text»)

Добавляем измененный файл

Файлы можно добавлять по одному, можно добавлять все сразу — команду можно выполнить вслед за предыдущей она ее продублирует

Делаем коммит, указывая после ключа -m комментарий

Здесь система попросит ввести логин пользователя на github и его пароль

Username for ‘https://github.com’: valdes101
Password for ‘https://[email protected]’:

Как только мы это сделаем отображаются следующая информация:

Counting objects: 3, done.
Writing objects: 100% (3/3), 215 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/valdes101/test.git
* [new branch] master -> master

Теперь меняем содержимое единственного файла в репозитории — добавляем еще одну строку

git commit -m ‘Second commit’
[master c5b2de5] First commit
1 file changed, 2 insertions(+), 1 deletion(-)


и снова передаем информацию на github

Username for ‘https://github.com’: valdes101
Password for ‘https://[email protected]’:
Counting objects: 3, done.
Writing objects: 100% (3/3), 253 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/valdes101/test.git
1273b8c..c5b2de5 master -> master

В интерфейсе аккаунта на сайте можно видеть добавленный файл, коммиты и комментарии

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

Если не добавить

перед коммитом можно увидеть следующее сообщение, выделенное в консоли красным цветом:

On branch master
Changes not staged for commit:
modified: FILE.txt

no changes added to commit

Все системные сообщения очень информативны — в частности, при попытке «пушнуть» на github неизмененные файлы возникает сообщение «Everything up-to-date»

Username for ‘https://github.com’: valdes101
Password for ‘https://[email protected]’:
Everything up-to-date

Создаем файл password и добавляем в него произвольное содержимое

git commit -m «added one more file»

[master c2a671f] added one more file
2 files changed, 2 insertions(+), 1 deletion(-)
create mode 100644 password

Отправляем информацию на удаленный репозиторий

Username for ‘https://github.com’: valdes101
Password for ‘https://[email protected]’:
Counting objects: 4, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (4/4), 318 bytes | 0 bytes/s, done.
Total 4 (delta 0), reused 0 (delta 0)
To https://github.com/valdes101/test.git
c5b2de5..c2a671f master -> master

Отмена коммитов с отменой изменений, внесенных в файлы, и без них

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

[master dded43f] new one
1 file changed, 1 insertion(+), 1 deletion(-)

Отменяем последний коммит следующей командой

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

Делаем коммит снова

Сейчас отменяем его с ключом —hard, его использование означает, что будет отменен коммит и изменения, внесенные в файл

HEAD is now at c2a671f added one more file

Отправляем данные на github

remote: Counting objects: 3, 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), done.
From https://github.com/valdes101/test
* branch master -> FETCH_HEAD
c2a671f..d578a72 master -> origin/master
Updating c2a671f..d578a72
Fast-forward
password | 3 ++-

Клонирование репозитория с Github

Идем на другую машину (в тестовой среде был просто сменен пользователь командой su mailer, затем выполнен переход в его домашний каталог cd /home/mailer)

git clone https://github.com/valdes101/test.git

Cloning into ‘test’…
remote: Counting objects: 10, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 10 (delta 0), reused 10 (delta 0), pack-reused 0
Unpacking objects: 100% (10/10), done.
Checking connectivity… done.

Переходим в каталог test

Редактируем файл password

git config —global user.email «[email protected]»

git config —global user.name «testuser2020»

git commit -m «added by another user»

git commit -m «added by another user»[master d578a72] added by another user
1 file changed, 2 insertions(+), 1 deletion(-)

Отправляем на github

Username for ‘https://github.com’: valdes101
Password for ‘https://[email protected]’:
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 293 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/valdes101/test.git
c2a671f..d578a72 master -> master

Проверяем, что на github появилась информация о сделанном коммите, а файл обновился

Теперь авторизуемся на сервере с реквизитами пользователя от имени которого работа велась изначально и выполняем команду git pull origin master

remote: Counting objects: 3, 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), done.
From https://github.com/valdes101/test
* branch master -> FETCH_HEAD
c2a671f..d578a72 master -> origin/master
Updating c2a671f..d578a72
Fast-forward
password | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

Просматриваем файл password — видим, что изменения сделанные и закоммиченные другим пользователем сохранились

Как сунуть уже готовый проект в репозиторий?

В первый раз может потребоваться указать Гиту имя пользователя (лучше латинницей) и E-mail.

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

А дальше, вроде можно и так:

1. Создать на GitHub репозиторий

Кнопочка видна после авторизованного входа на GitHub

Достаточно придумать название латинницей, можно разделять слова минусом

1. в папке с проектом инициализировать гит-репозиторий
git init

2. связать с репозиторием на ГитХабе
git remote add origin адрес_репозитория_на_гитхабе

3. Добавить все файлы в отслеживание
git add —all

4. Создать коммит (правку)

5. Дать команду на пуш в репозиторий на ГитХабе
git push origin master

6. Ввести имя пользователя GitHub

7. Ввести пароль пользователя GitHub

сам попробовал наскоком изучить, получилось не очень хорошо, делали совместный проект, народ просил не пушить меня некоторое время код, а почему, я только месяц назад понял, когда шаг за шагом прочитал учебник по гиту https://git-scm.com/book/ru/v2

по IDE, думаю во всех современных такая опция есть, я пользую IDEA https://www.jetbrains.com/idea/ тут хорошо реализовано

после прочтения учебника использую пока только терминал

резюме: рекомендую потихоньку выучить основы по учебнику и затем совершенствоваться
в качестве бонуса: есть бесплатный хороший видео-курс https://geekbrains.ru/courses/66

теперь собственно по сабжу: путем некоторых экспериментов с потерей и восстановлением кода пришел к такой последовательности:

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

Урок 3. Git и Github. Создание репозитория

/Maks/android-kernel-zzz
git init — инициализируем репозиторий
git add . — помечаем для выгрузки все файлы в

/Maks/android-kernel-zzz
git commit -m «first commit» — коммитим изменения, вместо first commit можно написать, что угодно.
git remote add origin https://github.com/твой_ник/имя_репозитория.git
git push -u origin master — после ввода команды попросит пароль.

Тема в стадии развития!

Сообщение отредактировал AndrewP_1 — 29.04.19, 12:01

Предложу альтернативу. :wink_kind:

Создаём новый пустой репозиторий с помощью командной строки:

Интеграция чужих наработок в свой репозиторий

  • git remote add name [url репозитория]
  • git fetch name
  • git cherry-pick [id коммита]

Где name это условное имя ветки (может быть каким угодно)

  • Git или Гит — система контроля и управления версиями файлов.
  • GitHub или Гитхаб — веб-сервис для размещения репозиториев и совместной разработки проектов.
  • Репозиторий Git — каталог файловой системы, в котором находятся: файлы конфигурации, файлы журналов операций, выполняемых над репозиторием, индекс расположения файлов и хранилище, содержащее сами контролируемые файлы.
  • Локальный репозиторий — репозиторий, расположенный на локальном компьютере разработчика в каталоге. Именно в нём происходит разработка и фиксация изменений, которые отправляются на удалённый репозиторий.
  • Удалённый репозиторий — репозиторий, находящийся на удалённом сервере. Это общий репозиторий, в который приходят все изменения и из которого забираются все обновления.
  • Форк (Fork) — копия репозитория. Его также можно рассматривать как внешнюю ветку для текущего репозитория. Копия вашего открытого репозитория на Гитхабе может быть сделана любым пользователем, после чего он может прислать изменения в ваш репозиторий через пулреквест.
  • Обновиться из апстрима — обновить свою локальную версию форка до последней версии основного репозитория, от которого сделан форк.
  • Обновиться из ориджина — обновить свою локальную версию репозитория до последней удалённой версии этого репозитория.
  • Клонирование (Clone) — скачивание репозитория с удалённого сервера на локальный компьютер в определённый каталог для дальнейшей работы с этим каталогом как с репозиторием.
  • Ветка (Branch) — это параллельная версия репозитория. Она включена в этот репозиторий, но не влияет на главную версию, тем самым позволяя свободно работать в параллельной. Когда вы внесли нужные изменения, то вы можете объединить их с главной версией.
  • Мастер (Master) — главная или основная ветка репозитория.
  • Коммит (Commit) — фиксация изменений или запись изменений в репозиторий. Коммит происходит на локальной машине.
  • Пул (Pull) — получение последних изменений с удалённого сервера репозитория.
  • Пуш (Push) — отправка всех неотправленных коммитов на удалённый сервер репозитория.
  • Пулреквест (Pull Request) — запрос на слияние форка репозитория с основным репозиторием. Пулреквест может быть принят или отклонён вами, как владельцем репозитория.
  • Мёрдж (Merge) — слияние изменений из какой-либо ветки репозитория с любой веткой этого же репозитория. Чаще всего слияние изменений из ветки репозитория с основной веткой репозитория.
  • Кодревью — процесс проверки кода на соответствие определённым требованиям, задачам и внешнему виду.

Как создать репозиторий на GitHub через командную строку?

В папке с проектом создаю локальный репозиторий ( git init ), выполняю весь необходимый минимум ( git add . , git commit -m «Описание коммита» ), и пробую выложить его в свой аккаунт на GitHub:

Топ-пост этого месяца:  Независимый генератор создания Sitemap WordPress сайтов

А возвращается ошибка:

remote: Repository not found. fatal: repository ‘https: // github.com / Gooddjamp/git_prj.git/’ not found

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

3 ответа 3

Linux / OS X

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

Вводим пароль от учетной записи:

Enter host password for user ‘USER_NAME’:

Репозиторий demo создан.

Теперь выгружаем проект.

Windows

Вариант 1:

Устанавливаем утилиту cURL и перезагружаемся. Дальше последовательность идентична Linux.

Вариант 2 (Спасибо @PinkTux):

Cкачиваем архив wget, разархивируем в любое место на диске и прописываем путь в переменной PATH . Открываем командную строку и пишем следующее:

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

Таким способом можно создавать репозитории с различными параметрами.Вот туд приведен полный перечень параметров. Например для создания приватного репозитория (если у вас есть конечно такая привилегия) нужно подставить в первую строку после -d :

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

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

(Впрочем, конфликты тут не страшны — можно же и push -f сделать)

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

Как пользоваться GIT – разбираемся за 30 минут

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

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

Основы основ работы с GIT

GIT — это определённый набор утилит командной строки, отслеживающих и записывающих изменения в файлах. При помощи его, возможно, восстанавливать предыдущие версии ваших программ, сравнивать, анализировать, совмещать изменения и многое другое. Такой процесс принято называть контроль версий. На сегодняшний день есть много систем контроля версий, выполняющих такую же работу. Вы могли уже слышать ранее о некоторых из них – SVN, Mercurial, Perforce, CVS, Bitkeeper.

GIT децентрализован, что означает его независимость от центрального сервера для сохранения старых версий ваших файлов. Он работает полностью локально, сохраняя данные в виде папки на вашем жестком диске, которая называется репозиторием. Но вы можете хранить копию репозитория так же и в «облаке» для взаимодействия между несколькими людьми, работающих над одним кодом. Как раз для таких целей используют GitHub и BitBucket .

1. Установка GIT

Установить GIT на ваш компьютер несложно:

  • Linux – просто откройте терминал и установите GIT через менеджер пакетов вашего дистрибутива. Команда для Ubuntu: sudo apt-get install git ;
  • Windows – можно воспользоваться установщиком на официально сайте или более лучший вариант GIT для Windows , так как он включает и графический клиент (GUI client), и эмулятор командной строки BASH;
  • OS X – легче всего воспользоваться homebrew и ввести команду brew install git в вашем терминале.

Если же вам не хотеться возиться с консолью или терминалом, то можно установить себе графический клиент GIT. Вот два наиболее популярных Sourcetree и GitHub Desktop , если поискать, то можно найти и другие не менее хорошие, чем эти. Но не стоит забывать, что умение работать с GIT-командами является хорошей практикой и в некоторых случаях это гораздо удобней, потому в оставшейся части урока мы с фокусируемся именно на этом.

2. Первоначальная настройка GIT

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

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

3. Создание нового репозитория – git init

Как упоминалось ранее, GIT хранит свои файлы и историю непосредственно как папка в вашем проекте. Чтобы создать новый репозиторий, откройте терминал, укажите адрес директории проекта и введите команду git init . Тем самым вы позволите GIT создать скрытый директорий .git для этой конкретной папки, в котором будут храниться история и конфигурация.

Для примера создайте папку на рабочем столе под названием git_exersice, откройте терминал и введите следующее:

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

Это означает, что репозиторий успешно создан, но всё ещё пуст. А теперь создайте простой текстовый файл hello.txt и сохраните в папку git_exersice.

4. Проверка статуса – git status

GIT статус это ещё одна необходимая для изучения команда, которая возвращает информацию о текущем состоянии репозитория: всё ли сохранилось, что сохранилось нового, что поменялось и так далее. На команду git status в нашем новом репозитории должен прийти такой ответ:

Полученное сообщение показывает, что файл hello.txt не отслеживается. Это означает, что файл новый, и GIT ещё не знает, должен ли отслеживать вносимые в него изменения или же игнорировать. Для подтверждения файла следует его добавить в индекс.

5. Индексирование – git add

У GIT есть понятие «области индексирования». Его можно представить себе, как пустой холст для хранения изменений, которые вы хотели бы зафиксировать. Изначально область появляется пустой, но вы можете добавлять к ней файлы (или даже отдельные строки и части файлов) с помощью команды git add и, наконец, всё сохранить (создать своеобразный «скриншот») с помощью git commit .

В нашем случае у нас есть только один файл, поэтому его и добавим:

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

Вновь проверив статус, мы должны получить уже другой ответ:

Файл готов для сохранения (создания коммита)! Это сообщение о статусе также говорит нам, что было изменено в отношении файлов в области индексирования, в данном случае о появлении нового файла (new file), но файл может показываться как modified или deleted, в зависимости от действий с ним с момента прошлой команды git add .

6. Сохранение изменений – git commit

Зафиксированные изменения показывают состояние репозитория в определённый момент времени. Как скриншот, с помощью которого мы просматриваем состояние вещей в прошлом.

Для создания новой сохранённой версии файлов нам нужно добавить как минимум одно изменение в область индексирования (мы только что это сделали с git add ) и ввести следующую команду:

Эта команда создаст новый «скриншот» со всеми сделанными изменениями (включая hello.txt). Часть -m «Initial commmit» – это краткий комментарий, написанный пользователем, к данной версии файлов. Хорошая привычка – регулярно фиксировать и всегда писать внятный комментарий.

Удалённые репозитории и GIT

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


1. Подключение к удалённому репозиторию – git remote add

Для того чтобы загрузить что-то в удалённый репозиторий, для начала нам нужно установить соединение с ним. Для этого урока наш адрес репозитория будет https://github.com/tutorialzine/awesome-project. Конечно лучше самому создать собственный пустой репозиторий на GitHub , BitBucket или другом сервисе. Регистрация и установка могут занять время, но все сервисы предлагают пошаговые инструкции в помощь вам.

Для соединения нашего локального репозитория с удалённым на GitHub, мы должны в терминале вести следующую строку:

Один проект может иметь несколько удалённых репозиториев одновременно. Для их разделения нужно дать им разные имена. Традиционно основной удалённый GIT-репозиторий называют origin.

2. Загрузка на сервер – git push

Настало время для перемещения наших локальных GIT-записей на сервер. Этот процесс называется push, и он выполняется каждый раз, когда мы хотим обновить удалённый репозиторий.

Команда GIT для push, git push , имеет два параметра – имя удалённого репозитория (мы назвали наш origin) и ветка для отправки (ветка по умолчанию для каждого удалённого репозитория – master).

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

3. Клонирование репозитория – git clone

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

Новый локальный репозиторий создаётся автоматически, с GitHub-версией, настроенной как удалённый репозиторий.

4. Получение изменений с сервера – git pull

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

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

Ветви в GIT

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

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

1. Создание новых ветвей – git branch

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

Тем самым вы создаёте новую ветвь, на данном этапе одинаковую с master.

2. Смена ветвей – git checkout

Теперь, когда мы выполнили команду git branch , мы получили доступ к двум опциям:

Master – текущая ветвь и помечена звёздочкой. Однако мы хотим работать над новыми замечательными версиями программы, поэтому нам нужно переключиться на другую ветвь. Это делается командой git checkout с указанием одного параметра – ветвь для переключения.

3. Объединение ветвей – git merge

Наша «новая версия» будет просто другим текстовым файлом под названием feature.txt. Мы создадим его, добавим и зафиксируем.

Далее мы вернемся в ветвь master.

Теперь, если мы откроем наш проект в файловом менеджере, мы заметим, что feature.txt исчез. Это потому, что мы вернулись в master-ветвь, и здесь feature.txt так и не был создан. Чтобы перенести его сюда, нам нужно объединить две ветви вместе командой git merge , применив изменения, сделанные в amazing_new_feature, к основной версии проекта.

Ветвь master обновлена, а ветвь awesome_new_feature branch больше не нужна и мы можем её удалить.

Продвинутый уровень GIT, ещё больше полезных команд

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

1. Просмотр отличий между сохранёнными версиями

Каждая зафиксированная версия программы имеет уникальный идентификационный номер в формате строки из чисел и символов. Для просмотра списка коммитов (сохранённых версий) с их идефикаторами мы можем использовать команду git log :

Как видите, >git show [commit] :

Просмотреть отличия двух любых коммитов можно с помощью команды git diff с указанием на требуемые версии: [commit-from]..[commit-to].

Топ-пост этого месяца:  Как добавить видео в ВК с телефона, компьютера, Ютуба и ...

Мы сравнили первый коммит с последним и увидели все изменения, когда-либо внесённые. Обычно это проще сделать, используя команду git difftool , которая покажет все различия между началом и концом в графическом клиенте.

2. Возвращение файла в предыдущую версию

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

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

3. Исправление коммита

Если вы заметили, что вы сделали опечатку в своей команде к сохранению, или вы забыли добавить файл, и заметили сразу после фиксации, вы можете легко исправить это с помощью команды git commit —amend . Она добавит всё из последней версии обратно в область индексирования и попытается создать новую фиксацию. Это дает вам возможность исправить вашу неправильную команду или добавить дополнительные файлы в область индексирования.

Для корректировок потруднее, которые должны быть не в последней версии (или вы уже успели отправить свои изменения на сервер), используйте команду git revert . Она отменит все изменения в этой фиксации и создаст новую, которая будет полностью противоположна исходной.

Ей может быть присвоено имя HEAD.

В подобных случаях лучше всего использовать id-номер.

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

4. Разрешение конфликтов объединения

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

Давайте посмотрим на пример, где мы будем пытаться объединить две ветви, называющиеся john_branch и tim_branch. И Джон, и Тим записывают в одном и том же файле функцию, которая отображает все элементы в массиве.

Джон использует цикл for:

Тим же предпочёл forEach:

Они оба фиксируют свой код на собственных ветвях. Теперь, если они попытаются объединить эти две ветви, то увидят следующее сообщение об ошибке:

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

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

Как только всё будет отлажено, должна появиться объединённая фиксация.

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

5. Настройка .gitignore

Во многих проектах присутствуют файлы или папки, которые мы не хотим фиксировать. Мы можем «железно» заблокировать их включение в наш git add –A созданием файла .gitignore:

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

Хорошие примеры игнорируемых файлов:

  • лог-файлы;
  • сборщик задач;
  • папка node_modules в проектах node.js;
  • папки, созданные такими IDE (интегрированные среды разработки), как Netbeans и IntelliJ;
  • личные примечания разработчика.

Файл .gitignore блокирует всё вышеуказанное примерно подобным образом:

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

Заключение

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

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

  • Официальная документация GIT, включая полную книгу и видеоуроки ;
  • Получение прав GIT– коллекция уроков и статей Atlassian ;
  • Список графических клиентов ;
  • Памятка о GIT (PDF) ;
  • Создать .gitignore файл онлайн .

Как создать репозиторий на GitHub

  • написана командой Vertex Academy. Надеемся, что она Вам будет полезна. Приятного прочтения!
  • это одна из статей из нашего «Самоучителя по Java»

Привет! Это одна из статей из руководства «GIT основы: Курс молодого бойца»

Как создать репозиторий на GitHub

Как только Вы создали эккаунт на GitHub (см. статью «Как зарегистрироваться на GitHub»), перед Вами должно появиться похожее окно:

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

Но сейчас, давайте начнем с основ. Сверху слева находится поисковая строка:

Справа вверху — небольшое меню:

Колокольчик — это уведомления.

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

Если же нажать на плюс, откроется выпадающее меню:

Как видите, можно:

  • создать новый репозиторий («New repository»)
  • импортировать репозиторий («Import repository»)
  • новый gist («New gist») — что-то наподобие статьи в блог
  • новая организация («New organisation») — например, Вы можете создать организацию, с которой можно связывать учётные записи на GitHub.

Три способа создать репозиторий на GitHub:

Cпособ 1: нажать на «New repository».

Способ 2: нажать на большую кнопку «Start a project» («Создать проект»):

Способ 3: нажать на зеленую кнопку «New repository» («Новый репозиторий») в окошке Repositories («Репозитории»):

Создаем репозиторий на GitHub

Вы уже знаете три способа создать новый репозиторий! �� Тогда создайте репозиторий, использовал любой из 3 способов.

Создали? Отлично, тогда Вы должны увидеть вот такую страницу:

Отлично! Давайте разберем по частям.

Сверху, Вы видите собственника репозитория («Owner»), и название репозитория («Repository name»). Давайте назовем его «first-repo»:

Как выбирать имя для репозитория

В языке Java есть определенные Naming Conventions (Code Conventions), т.е. соглашение о том, как нужно называть переменные, классы, методы и т.д. Как Вы наверное помните, в Java принято использовать CamelCase (по-другому CamelStyle).

На GitHub таких правил нет. Тем не менее, часто можно увидеть запись через дефис (как сделали мы), или тем же CamelCase.

Для примера, можно посмотреть на репозитории:

  • Google (https://github.com/google)
  • Facebook (https://github.com/facebook)
  • Microsoft (https://github.com/Microsoft)

Вот так выглядит репозиторий Google.

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

Возвращаемся к созданию репозитория

Итак, дальше идёт описание («Description»). Писать его не обязательно (справа от «Description» серым написано слово «optional»). Но если Вы хотите чтобы работодатель, который будет смотреть на Ваш аккаунт, или другие программисты, смогли понять о чём идёт речь и оценили Вашу работу, желательно подробно описывать проекты. В частности, это можно сделать с помощью README (об этом позже).

В описании давайте напишем «Первый проект на Git»:

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

На этом мы можем остановиться и нажать большую зеленую кнопку «Создать репозиторий» («Create repository»). Тем не менее, есть еще несколько настроек, которые мы можем сделать.

Во-первых, Вы видите галочку «Initialise this repository with a README» (Создать репозиторий с README). README — это еще один способ рассказать людям, просматривающим Ваш репозиторий, о Вашем проекте.

Хорошо расписанные README будет выглядет примерно так:

Но написание таких файлов — отдельная наука. Файл README имеет расширение .md, свой синтаксис и метки. Подробнее то, как следует писать файл README, мы рассмотрим в следующих статьях.

Кроме создания README, у нас есть еще две опции — добавлять ли файл .gitignore (по умолчанию None — не добавлять), и добавлять ли лицензию (по умолчанию тоже None).

Про то, что такое файл .gitignore, мы поговорим в следующих статьях. В двух словах, это файл, который говорит GIT, какие файлы следует игнорировать при загрузке.

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

Дело в том, что на GitHub размещают много open-source проектов, то есть бесплатных программ с открытым кодом. Интересно, что обычно лицензия используется не для того, чтобы ограничить доступ в проекту, а наоборот, чтобы позволить другим людям использовать Ваш код. Когда Вы ничего не указываете в поле «лицензия», использование кода из репозитория считается кражей.

Итак, отлично! Мы разобрались с основными полями, которые надо заполнить. Теперь, нажмем большую зеленую кнопку «Создать репозиторий» («Create repository»).

Теперь Вы должны видеть перед собой похожую страницу:

Вот мы и создали свой первый репозиторий на GitHub. Теперь он появится у Вас в разделе «Репозитории» на главной странице:

Теперь мы можем загружать проекты из компьютера на удаленный репозиторий на GitHub. О том, как это делать, мы поговорим в следующих статьях.

Спасибо, что были с нами! ��

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

Начинаем работать с системой контроля версий GIT (для чайников)

(Часть 2. Создаем репозиторий Git)

2. Создаем репозиторий Git.

Да начала создания репозитория необходимо провести базовые настройки Git. Дело в том, что часто над одним проектом работает целая команда разработчиков, поэтому системы контроля версий требуют идентифицировать пользователей, которые сохраняют изменения в репозитории. Не исключение и система контроля версий git, в которой в качестве идентификатора используется два параметра: имя пользователя и e-mail адрес. Эти параметры задаются один раз при настройке git и при каждом сохранении в репозитории напротив «коммита» указывается, кто его сохранил в репозиторий.

Коммит (commit) – единовременная загрузка группы изменений в репозиторий Git c кратким описанием содержания изменения и указания автора загрузки. Коммита – базовая величина изменения репозитория, который состоит из набора коммитов, история добавления которых показывается в виде древа коммитов.

Чтобы задать имя пользователя (в моем случае имя пользователя — Poisov) в консоли необходимо выполнить команду:

git config —global user.name «Poisov»

Чтобы задать e-mail (в моем случае e-mail: [email protected]) в консоли необходимо выполнить команду:

git config —global user.email «[email protected]»

На этом необходимый минимум настроек выполнен и можно приступить к созданию репозитория. Первое, что надо сделать – выбрать рабочий каталог, в котором вы будете разрабатывать свое программное обеспечение. Каталог может быть как пустым если вы только собираетесь начать разработку, так уже содержать результаты вашей работы. В качестве рабочего каталога я выберу пустой каталог: home/poisov/programs.

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

И создать Git-репозиторий, для чего находясь в каталоге home/poisov/programs в консоле набираем команду:

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

/programs$ git init
Initialized empty Git repository in home/poisov/programs/.git/
[email protected]:

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

Добавить комментарий