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

Git для начинающих. Урок 2.
Создание и клонирование репозитория

Видеоурок. Часть 1. Практика

Все о репозиториях

Видеоурок. Часть 2

Конспект урока

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

Что такое репозиторий

Это каталог в файловой системе, где хранится информация о проекте:

Можно ли работать с git локально

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

Локальный репозиторий

Удаленный репозиторий, зачем он нужен

Это репозиторий, который хранится в облаке, на сторонних сервисах, специально созданных под работу с проектами git.

Плюсы удаленного репозитория

Что такое клонирование

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

Как клонировать готовый проект

Наберем в командной строке

Как клонировать проект в другую папку

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

Свой удаленный репозиторий

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

Где держать репозиторий

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

Как создать репозиторий в github

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

Права на репозиторий, публичные и приватные

Есть 2 типа репозиториев:

Публичные репозитории хороши для opensource-проектов и чтобы показать в резюме. Пока нам это не нужно.

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

Что такое ssh-ключи

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

ssh-ключ не имеет прямого отношения к git, но так репозитории находятся на удаленных серверах, то ssh-ключи используются для разграничения доступа к приватным репозиториям.

ssh-ключ состоит из пары ключей: публичного и приватного ключа. Это просто 2 текстовых файла:

Публичный ключ передается сторонним серверам, например, github, для открытия доступа на эти сервера. Приватный ключ хранится только на нашей машине и никому не передается. То есть когда у нас просят ssh-ключ, чтобы дать доступ на какой-нибудь сервер, мы отдаем именно публичный ключ, id_rsa.pub

Как сгенерировать ssh-ключ

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

Если этих файлов нет, то нужно сгенерировать ключи утилитой ssh-keygen. В Windows она устанавливается вместе с git, в Linux и MacOS при необходимости установите. В Linux, например, вот так

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

Как добавить ssh-ключ в настройках github

Два способа создания проекта

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

Второй, когда у нас уже есть проект. Нужно зайти в папку проекта и связать его с уже существующим репозиторием на github. Это называется инициализация.

Рассмотрим оба способа.

Пустой проект

Идем в командную строку и запускаем

Непустой проект

Допустим, у нас на локальной машине уже есть проект second-site. Создаем в github репозиторий second-site. Заходим в папку проекта и выполняем команды

Все, можно приступать к работе над проектом. Команды add, commit и push мы разберем в следующих уроках.

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

Что могу посоветовать

Немного подробнее о копировании ssh-ключей

Как скопировать ssh-ключи с одной машины на другую

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

Ссылки, которые могут пригодиться

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

mewforest / Git help.md

Шпаргалка для работы с git

Создаем репозиторий для пустой папки

Создаем репозиторий для существующей папки

Настраиваем удаленный репозиторий (замените на свою ссылку!)

Теперь все изменения делаются так:

Убрать добавленные изменения (git add)

Убрать все изменения файлов до последнего коммита

Отменить последний коммит не удаляя файлы

Посмотреть историю коммитов

Примечание: русский язык может не поддерживаться в вашем IDE.

Переключение на коммит с id=»name_of_commit»

git checkout name_of_commit

Переключение обратно на последний коммит

«Скачать», а точнее клонировать проект

git clone https://github.com/. /project.git

Часто пока вы работаете над одной частью вашего проекта и всё находится в беспорядке, у вас возникает желание сменить ветку и поработать над чем-то ещё. Сложность при этом заключается в том, что вы не хотите фиксировать наполовину сделанную работу только для того, чтобы иметь возможность вернуться к ней позже. Справиться с ней помогает команда git stash. Source

Скрыть незакоммиченные изменения

git stash save «Ok here it is»

Посмотреть все скрытые изменения

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

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

git stash apply stash@

Отменить отслеживание закоммиченного файла

Удалить файл из репозитория, ен удаляя с диска

Как перестать каждый раз вводить логин/пароль от Github?

Не только Github, но и любого другого удаленного git-сервера. Вопрос решает авторизация с помощью генерации SSH-ключа на компьютере разработчика. Вначале проверьте, установлен ли у вас SSH-клиент (Windows 10 со сборки 1809, Ubuntu, OS X, etc

Если есть, то отлично, генерируем ключ (вместо ed25519 можно выбрать другие алгоритмы шифрования ключа):

На все вопросы можете ответить Enter. Но моя рекомендация, когда будет запрос «Enter passphrase (empty for no passphrase)», ввести кодовую фразу для ключа. Да, каждый push/pull/fetch придется её вводить, но зато если вдруг кто-то украдёт приватную часть ключа, он не сможет без неё получить доступ ко всем вашим удаленным репозиториям. Да, вам не послышалось, ключ разделён на две части: приватная (private key) и публичная (private key). Как следует из названия, приватную никому передавать нельзя, жди беды, а вот публичную как раз и стоит загрузить на удаленный сервер с репозиториями, в твоём случае это, скорей всего github.com.

Последний этап: загрузить свой public key на сервер и поменять у локального сервера способ авторизации с HTTP на SSH.

Github: Клик по аватару / Settings / SSH and GPG keys / New SSH key. Расположение ключа смотрите в консоли, оно там уже распечаталось. Далее переходим в ваш репозиторий на Github и клацаем по большой зеленой кнопке «Code», после чего выбраем SSH, копируем ссылку и вводим ее в консоль проекта:

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

За основу взят код отсюда.

Если возникнет необходимость ручного слияния, то выскочит что-то вроже:

В примере выше test_2.py прощел автоматическое слияние, а test_1.py нет. Для того, чтобы это исправить, нужно открыть конфликтующий файл и решить, какую строку оставить и закоммитить проект:

Добавление других проектов, как подмодулей

GitHub: настройка и первая публикация проекта

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

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

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

Как установить Git

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

Если вдруг его у вас нет, можно воспользоваться менеджером недостающих пакетов для macOS — Homebrew. Для установки пропишите в консоли brew install git.

Чтобы использовать Git на системе Linux, нужно поставить пакет Git. Например, для установки на Ubuntu нужно будет прописать sudo apt install git.

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

После того как скачаете его, запустите установщик:

Для скорости можно не менять дефолтные настройки и прокликать Next:

Теперь вы можете использовать на Windows такую же консоль, как и на iOS:

Все описанные ниже команды будут работать как в терминале на iOS и Linux, так и в Windows.

Регистрация в Git

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

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

Вместо user-name подставьте логин, который указывали при регистрации. В нашем случае это test-github-04, а вместо email@example.com — адрес вашей электронной почты. В нашем примере — testgithub@gmail.com.

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

Как опубликовать первый проект на Git

Зайдите в ваш профиль: для этого кликните по иконке в правом верхнем углу и нажмите Your Profile:

Теперь создайте репозиторий: перейдите во вкладку Repositories и кликните по кнопке New:

Задайте имя репозитория. Мы придумали название проекта test-github и сделали его публичным, чтобы его могли просматривать все пользователи. Далее нажмите кнопку Create repository:

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

Будем использовать протокол HTTPS — с ним проще работать с Git, чем с SSH. Подробнее про различия протоколов можно прочитать в документации.
Github предлагает несколько вариантов создания проекта:

Создание проекта с нуля

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

Команда echo «# test-github» >> README.md добавляет новый файл в проект. Его также можно создать вручную в папке.

git init — инициализирует проект. После инициализации создаётся специальная скрытая папка для Git:

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

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

git status поможет проверить, что происходит с изменёнными файлами. В нашем случае, например, файлы не прикреплены к коммиту:

Теперь снова посмотрим, что скажет git status. Сейчас он пустой, так как все изменённые файлы мы прикрепили к только что созданному коммиту:

git log показывает историю коммитов:

Команда git remote add origin https://github.com/test-github-04/test-github.git добавляет сервер, где origin — это имя сервера, а url — это адрес.

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

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

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

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

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

Как установить Git

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

Если вдруг его у вас нет, можно воспользоваться менеджером недостающих пакетов для macOS — Homebrew. Для установки пропишите в консоли brew install git.

Чтобы использовать Git на системе Linux, нужно поставить пакет Git. Например, для установки на Ubuntu нужно будет прописать sudo apt install git.

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

После того как скачаете его, запустите установщик:

Для скорости можно не менять дефолтные настройки и прокликать Next:

Теперь вы можете использовать на Windows такую же консоль, как и на iOS:

Все описанные ниже команды будут работать как в терминале на iOS и Linux, так и в Windows.

Регистрация в Git

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

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

Вместо user-name подставьте логин, который указывали при регистрации. В нашем случае это test-github-04, а вместо email@example.com — адрес вашей электронной почты. В нашем примере — testgithub@gmail.com.

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

Как опубликовать первый проект на Git

Зайдите в ваш профиль: для этого кликните по иконке в правом верхнем углу и нажмите Your Profile:

Теперь создайте репозиторий: перейдите во вкладку Repositories и кликните по кнопке New:

Задайте имя репозитория. Мы придумали название проекта test-github и сделали его публичным, чтобы его могли просматривать все пользователи. Далее нажмите кнопку Create repository:

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

Будем использовать протокол HTTPS — с ним проще работать с Git, чем с SSH. Подробнее про различия протоколов можно прочитать в документации.
Github предлагает несколько вариантов создания проекта:

Создание проекта с нуля

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

Команда echo «# test-github» >> README.md добавляет новый файл в проект. Его также можно создать вручную в папке.

git init — инициализирует проект. После инициализации создаётся специальная скрытая папка для Git:

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

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

git status поможет проверить, что происходит с изменёнными файлами. В нашем случае, например, файлы не прикреплены к коммиту:

Теперь снова посмотрим, что скажет git status. Сейчас он пустой, так как все изменённые файлы мы прикрепили к только что созданному коммиту:

git log показывает историю коммитов:

Команда git remote add origin https://github.com/test-github-04/test-github.git добавляет сервер, где origin — это имя сервера, а url — это адрес.

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

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

Сопровождение проекта

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

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

Давайте создадим новый репозиторий для распространения кода нашего проекта. В панели управления справа нажмите кнопку «New repository» или воспользуйтесь кнопкой + на панели инструментов, рядом с вашим именем пользователя как показано на рисунке Выпадающее меню «New repository».

Это приведёт к открытию формы «New repository»:

Всё, что в действительности нужно сделать, так это указать название проекта, все остальные поля опциональны. Сейчас, просто нажмите кнопку «Create Repository» и ваш новый репозиторий с названием / готов.

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

Теперь ваш проект хостится на GitHub и вы можете предоставить ссылку на него любому желающему. Все проекты на GitHub доступны как по HTTP https://github.com/ /

, так по SSH git@github.com: /

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

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

Добавление участников

Если вы работаете с другими людьми, которым вы хотите предоставить доступ для отправки коммитов, то вам следует добавить их как «участников». Если Бен, Джефф и Льюис зарегистрировались на GitHub и вы хотите разрешить им делать «push» в ваш репозиторий, то добавьте их в свой проект. Это предоставит им «push» доступ; это означает, что они будут иметь права доступа как на чтение, так и на запись в проект и Git репозиторий.

Перейдите по ссылке «Settings» в нижней части панели справа.

Затем выберите «Collaborators» в меню слева. Напишите имя пользователя в поле для ввода и нажмите кнопку «Add collaborator». Так вы можете добавить неограниченное количество пользователей. Чтобы отозвать доступ, просто нажмите «X» справа от имени пользователя.

Управление запросами на слияние

Сейчас у вас есть проект с некоторым кодом и, возможно, несколько участников с «push» доступом, давайте рассмотрим ситуацию, когда вы получаете запрос на слияние.

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

Для последующих примеров предположим, что вы «tonychacon» и создали новый проект для Arduino с названием «fade».

Email уведомления

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

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

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

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

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

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

Если слияние тривиально, то можно просто нажать кнопку «Merge» на сайте GitHub. Это всегда приводит с созданию коммита слияния, даже если доступно слияние перемоткой вперёд. Это значит, что в любом случае создаётся коммит слияния, как только вы нажимаете кнопку «Merge». Как можно увидеть на Кнопка Merge и инструкции по ручному слиянию запроса, GitHub отображает информацию об этом при вызове подсказки.

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

Ссылки на запрос слияния

Если у вас много запросов слияния и вы не хотите добавлять пачку удалённых репозиториев или постоянно делать однократный «pull», то у GitHub есть хитрый трюк, позволяющий это делать. Этот трюк очень сложный, но полезный и мы рассмотрим его немного позже в Спецификации ссылок.

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

В качестве примера мы используем низкоуровневую команду ls-remote (часто упоминается как «plumbing» команда, более подробно о ней будет рассказано в Сантехника и Фарфор). Обычно, эта команда не используется в повседневных Git операциях, но сейчас поможет нам увидеть какие ссылки присутствуют на сервере.

Если выполнить её относительно использованного ранее репозитория «blink», мы получим список всех веток, тегов и прочих ссылок в репозитории.

Аналогично, если вы, находясь в своём репозитории, выполните команду git ls-remote origin или укажете любой другой удалённый репозиторий, то результат будет схожим.

Теперь можно получить ссылки напрямую.

Запросы слияния на запросы слияния

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

При открытии запроса на слияние вверху страницы вы увидите меню для выбора целевой и исходной веток. Если нажать кнопку Edit справа, то станет доступным выбор не только исходной ветки, а ещё и форка.

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

Упоминания и уведомления

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

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

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

Если кто-то будет упомянут в запросе слияния или проблеме, то он автоматически «подписывается» и будет получать уведомления о последующей активности. Вы так же будете подписаны на некоторые уведомления если просто откроете запрос слияния или проблему, станете отслеживать репозиторий или если оставите комментарий. Для прекращения отправки вам уведомлений нажмите кнопку «Unsubscribe».

Страница уведомлений

Когда мы говорим «уведомления» в контексте GitHub, мы имеем ввиду способ, которым GitHub пытается связаться с вами в случае возникновения каких-либо событий, настроить который можно несколькими способами. Для просмотра настроек уведомлений перейдите на закладку «Notification center» на странице настроек.

Доступны два вида уведомлений: посредствам «Email» и «Web». Вы можете выбрать один, ни одного или оба, если активно участвуете в событиях отслеживаемых репозиториев.

Web уведомления

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

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

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

Email уведомления

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

Например, если взглянуть на заголовки письма, отправленного Тони в примере Email уведомление о новом запросе слияния, то можно увидеть следующее:

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

Особенные файлы

Существует несколько особенных файлов, которые GitHub заметит при наличии их в вашем репозитории.

README

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

Для чего предназначен проект

Инструкции по конфигурации и установке

Правила участия в проекте

В этот файл можно встраивать изображения или ссылки для простоты восприятия информации.

CONTRIBUTING

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

Управление проектом

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

Изменение основной ветки

Если вы используете в качестве основной другую ветку, отличную от «master», и хотите, чтобы пользователи открывали запросы на слияние к ней, то это можно изменить в настройках репозитория на закладке «Options».

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

Передача проекта

Если вы хотите передать проект другому пользователю или организации на GitHub, то это можно сделать нажатием кнопки «Transfer ownership» в настройках репозитория на закладке «Options».

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

Это действие приведёт не только к передаче репозитория со всеми его подписчиками и звёздами, но и добавит перенаправление с вашего URL на новый. Кроме этого, изменятся ссылки для клонирования и получения изменений из Git, а не только для веб запросов.

Инструкция: заливаем проект на GitHub без командной строки

Загружаем проект в удалённый репозиторий через GitHub Desktop

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

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

Шаг 1

Создаём учётную запись

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

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

Шаг 2

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

Репозиторий — это файловое хранилище проектов. На бесплатном тарифе можно загружать до 500 МБ данных и создавать неограниченное количество репозиториев.

Чтобы создать репозиторий, нажмите на кнопку New repository, назовите проект и кликните Create repository. Можно добавить описание проекта, сделать его публичным или приватным и прикрепить технические файлы:

Мы создаём тестовый репозиторий, поэтому обойдёмся без лицензии — выберем только два дополнительных файла: README file и gitignore. Если вы пока не знаете, что писать в README file и что добавлять в gitignore, — оставьте эти файлы пустыми или посмотрите инструкцию в разделе Read the guide.

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

После редактирования gitignore делаем коммит — записываем в историю проекта факт того, что мы установили ограничение для файлов Mac OS.

Шаг 3

Переносим удалённый репозиторий на ПК

Перейдите на сайт desktop.github.com и скачайте GitHub Desktop — это приложение, которое позволит синхронизировать удалённый репозиторий на GitHub и файлы на вашем компьютере без командной строки терминала:

Мы создали тестовый удалённый репозиторий, поэтому выберем третий вариант — клонировать существующий репозиторий в папку компьютера.

После клонирования репозитория в рабочем пространстве появятся три вкладки: Current Repository, Current Branch и Fetch origin.

Обратите внимание на раздел Current Repository и вкладку Changes. В левом нижнем углу есть окно для добавления коммитов и комментариев — это означает, что вы можете записывать каждый шаг, не посещая сайт GitHub.

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

Шаг 4

Добавляем новые файлы на ПК и переносим их в удалённый репозиторий

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

Выбор редактора кода — дело вкуса. Мы будем работать с репозиторием в Visual Studio Code — это бесплатный редактор от компании Microsoft.

Создадим HTML-файл, добавим базовую структуру и посмотрим на боковое меню — HTML-файл подсвечен зелёным цветом. Это означает, что в проекте появились изменения и они ещё не добавлены в репозиторий на GitHub.

Переходим в GitHub Desktop — созданный HTML-файл появится во вкладке Changes. Для его сохранения пишем коммит и переходим во вкладку History для просмотра изменений. Если изменения сохранились, нажимаем на Push origin и отправляем изменения в удалённый репозиторий.

Шаг 5

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

Добавим к проекту пустой CSS-файл и подключим его к HTML. После этого в меню редактора появятся два цвета: HTML-файл подсветится оранжевым, а CSS-файл — зелёным. Оранжевый означает, что файл уже есть в удалённом репозитории и его нужно обновить. Зелёный — файла нет в репозитории. Переходим в GitHub Desktop и добавляем коммит для этого изменения.

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

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

Предположим, наша идея с красным фоном оказалась удачной и код нужно залить в основную ветку. Чтобы это сделать, переходим сайт GitHub, нажимаем кнопку Сompare & pull request и подтверждаем изменения кнопкой Merge pull request. Последний шаг — переходим в GitHub Desktop, кликаем Fetch origin и синхронизируемся с удалённым репозиторием. Теперь код из дополнительной ветки попал в основную, а изменения есть на ПК и в облаке.

Hello world

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

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

Идём в настройки репозитория (шестерёнка с надписью Settings справа вверху)

Прокручиваем до пункта GitHub Pages. Видим желтую полосу с надписью «Pages settings now has its own dedicated tab! Check it out here!». Кликаем по ссылке и переходим на страницу с настройками GitHub Pages.
Если здесь уже находится выделенная зелёным цветом ссылка на созданную страницу, больше ничего делать не нужно, GitHub Pages создана. Если нет, подождите несколько минут, GitHub Pages создаётся не мгновенно.

8. Деплой на netlify

Если необходимо разместить в интернете проект, созданный в приватном репозитории, можно использовать сервис https://www.netlify.com/ Для этого авторизуемся на netlify, нажимаем на кнопку New site from Git и указываем репозиторий на GitHub, где находится наше приложение.

Также netlify позволяет разместить приложение, код которого находится в локальной папке на компьютере. Для этого достаточно открыть страницу https://app.netlify.com/drop и перетянуть папку с кодом приложения в прямоугольник с надписью «Drag and drop your site». Как и при деплое на GitHub Pages, деплой приложения на Netlify возможен, если файл index.html находится на верхнем уровне папки с проектом.

9. Приватный репозиторий школы

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

Приватный репозиторий школы видите только вы сами, менторы и админы. Другие студенты его увидеть не смогут. Будьте внимательны, когда сабмитите ссылки на свои работы для кросс-чек проверки. Нет смысла отправлять ссылку на приватный репозиторий школы или PR в нём, проверяющие его не увидят. Работу для проверки необходимо залить на gh-pages и сабмитить ссылку на задеплоенную версию. Перед сабмитом проверьте ссылку на деплой, открывается ли она в режиме инкогнито браузера и смогут ли проверяющие увидеть вашу работу.

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

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

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

Запустите Git Bash и перейдите в директорию, где хотите создать репозиторий (в этом задании она обязательно должна быть пуста):

Создайте гит-репозиторий в этой директории:

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

Создайте в репозитории файл README.md удобным для вас способом и опишите в нём назначение репозитория с помощью Markdown-разметки. Ниже можно увидеть пример такой разметки. Узнать больше о Markdown можно тут.

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

Отлично, теперь проверим изменения и сохраним их в репозитории:

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

Гит сообщит, что наш файл README.md untracked и подсветит его красным. Нужно сообщить ему, что мы собираемся сохранить изменения этого файла:

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

Обратите внимание, что важно писать хорошие сообщения коммитов, отражающие суть произведённых изменений. Среди англоговорящих программистов принято писать глаголы в сообщениях к коммитам в повелительном наклонении. Например “Add readme file” подойдёт в нашем случае.

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

Пришло время писать саму программу: назовите файл DateTime.pas и создайте в ней такой текст:

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

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

Машина времени: отменяем коммит

Мы столкнулись с необходимостью отменить коммит. Для начала посмотрим историю коммитов:

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

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

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

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

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

Создадим новую ветку:

И переключимся на неё

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

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

$ git checkout master

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

Продолжаем добавлять методы в библиотеку (разумеется, используя ветки (одной ветки хватит на все оставшиеся задания, не требующие явно сделать ещё одну)):

Оу, да это была ну уж слишком простая функция. Ревертируйте коммит с функцией SeconsInHours и удалите тесты для это функции (сделайте коммит).

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

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

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

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

Подробнее о способах исправления ошибок в истории коммитов можно узнать здесь.

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

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

Создание репозитория на гитхабе. (git remote)

Подключение локального репозитория к репозиторию на GitHub по данному адресу:

$ git remote add origin

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

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

Ну вот, библиотека успешно создана и опубликована, а вы стали начинающим пользователем Git.

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

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

Настройка Учетной Записи GitHub

Настройка вашей учетной записи на GitHub очень проста. Чтобы установить учетную запись, посетите официальный сайт GitHub https://github.com.

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

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

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

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

Для новичка GitHub Free plan более чем достаточно.

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

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

Панель Управления Учетной Записью GitHub

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

Панель мониторинга GitHub будет содержать три раздела.

Репозитории GitHub

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

Лента GitHub

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

GitHub Discover Repositories

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

Этого должно быть достаточно, чтобы вы начали работать на GitHub.

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

Репозиторий GitHub — это удаленный репозиторий на сервере GitHub. Это совершенно очевидно, так как GitHub — это веб-хостинг для репозитория Git. Создание репозитория GitHub дает нам много преимуществ. Одним из главных преимуществ является то, что вы можете поделиться своим репозиторием. Это самый простой и удобный способ.

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

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

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

Типы репозиториев в GitHub

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

Что такое публичный репозиторий на GitHub?

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

Что такое частный репозиторий на GitHub?

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

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

Репозитории GitHub легко создавать и легко управлять.

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

В последнем уроке мы познакомились с командой Git fetch и Read more

В одной из последних статей мы узнали о команде Git Read more

Мы уже знаем, как вносить изменения в локальное хранилище и Read more

Команда git push при выполнении перемещает изменения, внесенные пользователем на Read more

«Клонирование» означает создание идентичных особей естественным или искусственным путем. Клонирование Read more

Сегодня мы узнаем, как скопировать чужой репозиторий в наш аккаунт Read more

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

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

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

Как только Вы создали эккаунт на GitHub (см. статью «Как зарегистрироваться на 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Гид по Git

Что такое Git?

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

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

GitHub

После регистрации вы попадете на приветственную страницу, где сначала нужно, ничего не меняя, нажать зеленую кнопку Continue, а потом Skip this step (но если не лень, можно заполнить опросник и нажать Submit).

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

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

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

Сначала создадим через сайт. Чтобы создать репозиторий, нажимаем кнопку Start a project и выбираем название. Оно может быть любым, но должно отражать суть того, что лежит внутри, например, “homeworks”. Впрочем, GitHub предлагает более креативные варианты. Также в специальном поле можно добавить описание. Для публичных репозиториев хорошей практикой является заполнение всех полей, чтобы другие пользователи (или люди, проходящие по ссылке из резюме) могли сразу понять, о чём конкретно данный репозиторий.

У нас есть выбор между Public и Private. Разница между ними в том, что публичные репозиторий видно в поиске, в вашем профиле, любой может просмотреть весь код и предложить свои исправления (pull request, пулл-реквест, ПР, пи-ар). Приватный репозиторий доступен только определённым пользователям, хозяин репозитория сам выбирает, кто видит репозиторий и кто может делать коммиты. На обычном (бесплатном) аккаунте возможность создавать приватные репозитории обычно ограничена несколькими.

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

Также стоит упомянуть про файл .gitignore и LICENSE. Файл .gitignore нужен для того, чтобы в репозиторий не попадали разные временные файлы или сборки, например, при сборке проекта в Visual Studio создается множество временных бинарных файлов, которые при каждом изменении исходного кода программы, будут другими, поэтому для репозитория (хранилища исходного кода) это по факту мусор. Поэтому в этом файле прописано, что определенные папки и файлы не будут учитываться при подготовке коммитов и, следовательно, загрузке в удалённый репозиторий. При создании репозитория можно выбрать уже заранее созданные файлы под язык программирования или среду разработки. Также его можно прописать или дополнить и указать какие файлы включить или убрать из репозитория. Файл LICENSE указывает на то, по какой лицензии распространяется код. Про каждую лицензию можно почитать отдельно и в основном они отличаются тем, что можно делать с кодом: продавать, распространять, изменять и т.д. При создании нашего репозитория можно либо выбрать эти файлы, либо оставить их пустыми.

Популярные лицензии (в сторону уменьшения количества ограничений):

Текст лицензии понадобится скопировать в файл LICENSE.

Клонируем репозиторий

Теперь нам нужно сделать локальную копию нашего удалённого репозитория. Мы снова воспользуемся кнопкой Clone or download, но теперь используем полную ссылку на репозиторий; эту ссылку нужно скопировать (Если у вас окошко выглядит не так как на картинке, то нажмите в окне на ссылку справа сверху Use HTTPS).

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

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

Тут мы выбираем из списка репозиторий:

Тут мы вставляем ссылку на репозиторий:

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

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

Теперь давайте создадим в нашей папке новый текстовый документ с сообщением “Hello world!”.

Если мы откроем GitHub Desktop, мы увидим что наш файл увидела система и пометила как добавление новгго файла, отметив зеленым плюсом. Справа отобразив что именно сделали с файлом: зеленым выделены добавленные фрагменты.

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

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

Если все прошло успешно, и изменения запушились в удаленный репозиторий, то, обновив его страницу на GitHub, мы увидим новый файл hello world.txt.

Теперь давайте создадим файл на GitHub и скопируем его в локальный репозиторий. Нажимаем кнопку Create new file и называем его newfile.

Осталось “прописать” коммит и сделать его, нажав Commit new file:

Откроем GitHub Desktop и обнаружим, что система сама определила, что произошел внешний коммит и наши файлы нужно обновить. Если изменений не видно, нажмите F5 или перезапустите приложение. Нажмём на Pull origin и скачаем файлы в свой локальный репозиторий:

Верните всё назад!

Любой коммит можно отменить, щёлкнув по нему правой кнопкой мыши и выбрав Revert this commit. Так, если мы проведём эту процедуру с последним коммитом и запушим изменения на GitHub, то файл goose там исчезнет. В истории изменений данное действие будет видно, как ещё коммит, отменяющий изменения выбранного (анти-коммит). Чтобы посмотреть историю коммитов, нужно нажать на History.

Откатывать коммиты можно также через веб-интерфейс (на сайте GitHub).

Клонирование чужих репозиториев

Клонировать можно не только свои репозитории, но и чужие. Для этого найдите нужный репозиторий в поиске на github. И выбираем Clone or Download.

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

Что это нам дает? Это позволяет получать файлы, сразу после их добавления или изменения и не требует захода на сайт и ручной проверки на изменения.

Fork репозитория

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

В чем же отличие от клонирования репозитория? При клонировании мы только используем файлы оригинального репозитория и при создании коммита с какими-то изменениями, GitHub Desktop скажет нам, что у нас нет доступа на запись и сам предложит сделать форк. (Если доступ к этому репозиторию у нас есть, то сделать коммит мы сможем.) А если мы сделали форк, то изменения уйдут в нашу копию в нашем аккаунте.

Fork может быть полезен при разработки открытого ПО, например, мы сделали форк алгоритма сжатия, в нем мы изменили функцию сжатия и теперь алгоримт сжимает в 10 раз лучше. Мы можем сделать Pull request, т.е. запросить у хозяина оригинального репозитория с алгоритмом сжатия, интегрировать наши изменения в его репозиторий.

Ветки

Выбираем имя и в эту ветку пойдет вся информация с ветки master (точнее, новая ветка будет “смотреть” на тот же коммит, что и master), в том числе и все файлы:

Делаем коммит в новую ветку и смотрим, что произошло. Как мы видим, в ветке master всё осталось, как прежде. Она по прежнему указывает на тот же коммит, что и раньше.

А вот в ветке Features удалённого файла уже нет. Переключить ветку можно, нажав на кнопку Branch с названием ветки:

Ветки удобно использовать для добавления новых функция, что они не ломали рабочий код до новой функции. После разработки ветку можно объединить с master (merge, смёржить, слить) сделав так называемый Pull request.

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

Как говорилось ранее, новый репозиторий можно создать и из самого приложения. Для этого идем в File/New repository:

Указываем все данные аналогично тому как создавали на сайте и нажимаем Create repository:

Не забудьте нажать на Publish repository, чтобы он ушёл на сайт.

Далее еще раз укажите имя уже на сайте и всё.