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

Добавил пользователь Skiper
Обновлено: 10.09.2024

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

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

Git — это набор консольных утилит, которые отслеживают и фиксируют изменения в файлах (чаще всего речь идет об исходном коде программ, но вы можете использовать его для любых файлов на ваш вкус). С его помощью вы можете откатиться на более старую версию вашего проекта, сравнивать, анализировать, сливать изменения и многое другое. Этот процесс называется контролем версий. Существуют различные системы для контроля версий. Вы, возможно, о них слышали: SVN, Mercurial, Perforce, CVS, Bitkeeper и другие.

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

Установить git на свою машину очень просто:

Linux — нужно просто открыть терминал и установить приложение при помощи пакетного менеджера вашего дистрибутива. Для Ubuntu команда будет выглядеть следующим образом:
Windows — мы рекомендуем git for windows, так как он содержит и клиент с графическим интерфейсом, и эмулятор bash.
OS X — проще всего воспользоваться homebrew. После его установки запустите в терминале:

Если вы новичок, клиент с графическим интерфейсом(например GitHub Desktop и Sourcetree) будет полезен, но, тем не менее, знать команды очень важно.

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

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

Как мы отметили ранее, git хранит свои файлы и историю прямо в папке проекта. Чтобы создать новый репозиторий, нам нужно открыть терминал, зайти в папку нашего проекта и выполнить команду init. Это включит приложение в этой конкретной папке и создаст скрытую директорию .git, где будет храниться история репозитория и настройки.
Создайте на рабочем столе папку под названием git_exercise. Для этого в окне терминала введите:

Командная строка должна вернуть что-то вроде:

Это значит, что наш репозиторий был успешно создан, но пока что пуст. Теперь создайте текстовый файл под названием hello.txt и сохраните его в директории git_exercise.

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

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

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

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

Коммит представляет собой состояние репозитория в определенный момент времени. Это похоже на снапшот, к которому мы можем вернуться и увидеть состояние объектов на определенный момент времени.
Чтобы зафиксировать изменения, нам нужно хотя бы одно изменение в области подготовки (мы только что создали его при помощи git add), после которого мы может коммитить:

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

1. Подключение к удаленному репозиторию

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

Сейчас самое время переслать наш локальный коммит на сервер. Этот процесс происходит каждый раз, когда мы хотим обновить данные в удаленном репозитории.
Команда, предназначенная для этого - push. Она принимает два параметра: имя удаленного репозитория (мы назвали наш origin) и ветку, в которую необходимо внести изменения (master — это ветка по умолчанию для всех репозиториев).

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

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

Сейчас другие пользователи GitHub могут просматривать ваш репозиторий. Они могут скачать из него данные и получить полностью работоспособную копию вашего проекта при помощи команды clone.

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

4. Запрос изменений с сервера

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

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

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

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

1. Создание новой ветки

Основная ветка в каждом репозитории называется master. Чтобы создать еще одну ветку, используем команду branch

Это создаст новую ветку, пока что точную копию ветки master.

2. Переключение между ветками

Сейчас, если мы запустим branch, мы увидим две доступные опции:

master — это активная ветка, она помечена звездочкой. Но мы хотим работать с нашей “новой потрясающей фичей”, так что нам понадобится переключиться на другую ветку. Для этого воспользуемся командой checkout, она принимает один параметр — имя ветки, на которую необходимо переключиться.

3. Слияние веток

Наша “потрясающая новая фича” будет еще одним текстовым файлом под названием feature.txt. Мы создадим его, добавим и закоммитим:

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

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

Теперь ветка master актуальна. Ветка amazing_new_feature больше не нужна, и ее можно удалить.

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

1. Отслеживание изменений, сделанных в коммитах

У каждого коммита есть свой уникальный идентификатор в виде строки цифр и букв. Чтобы просмотреть список всех коммитов и их идентификаторов, можно использовать команду log:
[spoiler title='Вывод git log']

[/spoiler]
Как вы можете заметить, идентификаторы довольно длинные, но для работы с ними не обязательно копировать их целиком — первых нескольких символов будет вполне достаточно. Чтобы посмотреть, что нового появилось в коммите, мы можем воспользоваться командой show [commit]
[spoiler title='Вывод git show']

[/spoiler]
Чтобы увидеть разницу между двумя коммитами, используется команда diff (с указанием промежутка между коммитами):
[spoiler title='Вывод git diff']

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

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

Гит позволяет вернуть выбранный файл к состоянию на момент определенного коммита. Это делается уже знакомой нам командой checkout, которую мы ранее использовали для переключения между ветками. Но она также может быть использована для переключения между коммитами (это довольно распространенная ситуация для Гита - использование одной команды для различных, на первый взгляд, слабо связанных задач).
В следующем примере мы возьмем файл hello.txt и откатим все изменения, совершенные над ним к первому коммиту. Чтобы сделать это, мы подставим в команду идентификатор нужного коммита, а также путь до файла:

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

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

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

4. Разрешение конфликтов при слиянии

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

Тим предпочитает forEach:

Система не смогла разрешить конфликт автоматически, значит, это придется сделать разработчикам. Приложение отметило строки, содержащие конфликт:
[spoiler title='Вывод']

[/spoiler]
Над разделителем ======= мы видим последний (HEAD) коммит, а под ним - конфликтующий. Таким образом, мы можем увидеть, чем они отличаются и решать, какая версия лучше. Или вовсе написать новую. В этой ситуации мы так и поступим, перепишем все, удалив разделители, и дадим git понять, что закончили.

Когда все готово, нужно закоммитить изменения, чтобы закончить процесс:

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

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

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

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

Вот хорошие примеры файлов, которые нужно игнорировать:

Логи
Артефакты систем сборки
Папки node_modules в проектах node.js
Папки, созданные IDE, например, Netbeans или IntelliJ
Разнообразные заметки разработчика.

Файл .gitignore, исключающий все перечисленное выше, будет выглядеть так:

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

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

Так как эти темы довольно обширные, в статье рассмотрим их обзорно, с минимально необходимой информацией, для общего понимания и базовой работы с GitHub Desktop.

Что такое Git

Система управления версиями - определение из Wikipedia

Система управления версиями (от англ. Version Control System, VCS или Revision Control System) — программное обеспечение для облегчения работы с изменяющейся информацией. Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение, и многое другое.

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

При использовании системы Git мы запоминаем версии кода на нужных нам этапах. Имеем доступ к ранним версиям. Можем смотреть изменения, которые были сделаны между версиями. Можем отменить изменения до любой из версий.

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

У Git много возможностей, но на данный момент рассматриваем только базовые

Что такое GitHub

GitHub — крупнейший веб-сервис для хостинга IT-проектов и их совместной разработки.

Введем еще один термин, который также будет часто встречаться в статье и в работе с GitHub Desktop - репозиторий.

Репозиторий - определение из Wikipedia

Репозито?рий (англ. repository), хранилище — место, где хранятся и поддерживаются какие-либо данные. Чаще всего данные в репозитории хранятся в виде файлов, доступных для дальнейшего распространения по сети.

Если говорить совсем просто, то репозиторий - это наш проект (папка с файлами и системой Git)

Репозиторий может храниться локально на компьютере или чаще всего на таких веб-сервисах, как GitHub

Для чего нужен Github Desktop

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

Для работы с GitHub Desktop, необходимо зарегистрироваться на GitHub

Переходим на официальный сайт GitHub

На главной странице заполняем форму справа и нажимаем “Sign up for GitHub”

Проходим проверку и нажимаем “Join a free plan”

На следующей странице можно заполнить небольшую анкету (можно не заполнять)

На этой же странице спускаемся в самый низ и нажимаем “Complete setup”

Далее для завершения регистрации просят подтвердить свой email адрес.

Проверяем свою почту. Если письмо пришло, переходим к следующему пункту.

Если письмо не пришло, нажимаем “Resend verification email”.

Если по-прежнему письмо не приходит, можно проверить и изменить настройки - нажимаем “Change your email settings”

В письме от Github нажимаем “Verify email address”

Аккаунт GitHub успешно создан

Установка GitHub Desktop

Переходим на официальный сайт GitHub Desktop

Нажимаем “Download for Windows (64bit)” (операционная система может отличаться)

В открывшемся окне браузера вводим в форму свои данные, как при регистрации, и нажимаем “Sign in”

Если браузер запросит, то подтвердить, что нужно “Открыть приложение GitHub Desktop”

Далее регистрационные данные перенесутся в форму конфигурации (настроек) Git - нажимаем “Continue”

Отключаем пункт “Yes, submit periodic usage stats”, если не хотите периодически передавать статистику работы GitHub Desktop и нажимаем “Finish”

Далее видим начальное окно GitHub Desktop

“Create a tutorial repository…“ - создать обучающий репозиторий

“Clone repository from the Internet…“ - клонировать (скопировать/скачать) репозиторий из GitHub к себе на компьютер

“Create a New Repository on your hard drive…“ - создать новый репозиторий на вашем жестком диске (на вашем компьютере) и добавить систему Git в проект

“Add an Existing Repository from your hard drive…“ - добавить на GitHub репозиторий, который уже есть на вашем компьютере и использует Git

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

Создаём новый репозиторий

Создаём у себя на компьютере (например, на диске C:) папку projects, где локально будут храниться все наши репозитории.

Переходим в Github Desktop, нажимаем на начальном экране “Create a New Repository on your hard drive…“ или File > New Repository

В открывшемся окне в поле Name пишем название репозитория. В поле Description - описание репозитория, если необходимо. В Local Path выбираем созданную на диске C: папку projects, остальное оставляем по-умолчанию и нажимаем “Create repository”

В папке projects появился репозиторий Project-1

В репозитории Project-1 на данный момент находятся только необходимые служебные файлы Git.

На данный момент репозиторий расположен только локально на компьютере в папке Project-1. Чтобы репозиторий появился в аккаунте GitHub и хранился там, нажимаем “Publish repository”

В появившемся окне оставляем все по-умолчанию. Пункт “Keep this code private” оставляем отмеченным, чтобы репозиторий, пока что, был виден только нам, потом в любой момент репозиторий можно будет сделать открытым, чтобы его видели другие пользователи GitHub. Нажимаем “Publish repository”

Теперь репозиторий скопирован в аккаунт GitHub. Переходим в браузере на GitHub. Сверху справа нажимаем на круглую иконку аккаунта и выбираем пункт “Your repositories”

На странице наших репозиториев появился созданный репозиторий Project-1

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

Создадим на компьютере в папке Project-1 файл index.html и напишем в нем минимальную разметку.

На данный момент файл index.html расположен только локально в папке Project-1. Локальная система Git, которая была создана вместе с репозиторием, об этом файле ничего не знает.

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

Commit - фиксирование текущего состояния файлов, звучит как коммит.

Коммитам необходимо давать названия.

Откроем Github Desktop. Во вкладке Changes видим созданный index.html.

Вводим в поле ниже название коммита - add index.html . Затем нажимаем “Commit to main”, чтобы зафиксировать данное состояние файлов в локальную систему Git. (На данный момент не будем углубляться в ветвление Git)

На данный момент мы зафиксировали файлы в текущем состоянии и сделали запись об этом в локальную систему Git.

Далее, чтобы передать изменения в репозиторий на GitHub, нажимаем “Push origin”

Переходим в наш репозиторий на GitHub и убеждаемся, что файл index.html был добавлен

Далее внесем изменения в файл index.html - добавим заголовок

Переходим в GitHub Desktop, видим что index.html был изменен, вводим название нового коммита - add h1 и нажимаем “Commit to main”

И снова передаем изменения в репозиторий на GitHub - нажимаем “Push origin”

Видим, что index.html был изменен при коммите add h1

Нажав на название файла index.html, убеждаемся что заголовок добавлен

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

Далее рассмотрим работу с GitHub Desktop с нескольких рабочих мест

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

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

Создадим теперь на ноутбуке папку для репозиториев, например notebook projects

Устанавливаем на ноутбук GitHub Desktop, заходим под своим аккаунтом. Нажимаем File > Clone Repository

В списке выбираем необходимый репозиторий

В пункте Local path, нажимаем кнопку “Choose…“ и выбираем созданную папку notebook projects. Далее нажимаем “Clone…“

Репозиторий клонирован (скопирован) в папку Project-1.

Если в GitHub Desktop посмотреть вкладку History, то увидим всю историю коммитов

Внесем изменения в index.html на ноутбуке, добавим

Add text from Notebook

и сделаем коммит c названием add text from notebook , далее нажимаем “Commit to main”

Отправим коммит в репозиторий на GitHub - нажимаем “Push origin”

Коммит виден в репозитории на GitHub

В index.html добавлен

Add text from Notebook

Теперь возвращаемся из офиса домой, открываем GitHub Desktop на компьютере, и чтобы получить изменения, сделанные на ноутбуке, нажимаем “Fetch origin” - проверяем, есть ли отличия локального репозитория на компьютере и репозитория на GitHub

Отличия есть, поэтому далее нажимаем “Pull origin”

И получаем актуальный проект со всеми изменениями

Преимущества

Мы рассмотрели только базовое использование Git, GitHub, GitHub Desktop, но уже можем выделить достаточно много преимуществ (на самом деле их намного больше, как и возможностей)

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

Итоги

Возможно, на первый взгляд, покажется сложным, но после небольшой практики, вся базовая работа с GitHub Desktop на начальном этапе сойдется к тому, что вы поработали с проектом на работе > сделали коммит (“Commit to main”) > отправили на GitHub (“Push origin”). Пришли домой > получили изменения из GitHub (“Pull origin”) и продолжаете работу дома.

Возможно, через некоторое время напишу статью про другие возможности GitHub Desktop

Git - система контроля версий (version control system, VCS), созданная программистом Линусом Торвальдсом для управления разработкой ядра Linux в 2005 году. Хорошо, а что это всё-таки значит?

Представьте, что вы с коллегами вместе пишете ~~ядро Linux~~научную статью. У вас на компьютере есть папка, где лежат текстовые документы, картинки, графики и прочие нужные файлы; то же самое есть и у ваших коллег. Когда кто-то из вас изменяет, добавляет или удаляет файлы, остальные этих изменений не видят. Вы пишете друг другу об изменениях, пересылаете обновленные версии файлов, но в процессе работы непременно возникает путаница: какая версия текста - последняя? Куда и когда исчезла пара абзацев? Кто внес те или иные правки? Избежать таких проблем и помогают системы контроля версий. Устроено это так:

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

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

они позволяют работать над проектом в команде;
вы видите, кем и когда были внесены те или иные изменения;
их всегда можно откатить назад;
вы не потеряете проделанную работу, даже если что-то удалите на своем компьютере;
ваши наработки могут быть полностью открыты для других (а это доступность знаний и ускорение развития технологий, ура!);
GitHub и GitLab позволяют не только хранить и просматривать файлы проекта, но и публиковать веб-сайты, документацию и т.п.

Существует много систем управления версиями, но мы будем пользоваться самой распространенной - git. Также нам нужно как-то отдавать гиту команды, и делать это можно двумя способами: с помощью командной строки и через графический интерфейс (graphical user interface, GUI). Графический интерфейс программы - это все те окошки с кнопочками, которые мы привыкли видеть. Существует много графических интерфейсов для Git, например:

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

Git - разновидность системы контроля версий (самая популярная). Его можно скачать и установить, далее использовать через командную строку.
Можно использовать графический интерфейс для работы с Git. При этом скачивать и устанавливать сам Git отдельно не нужно, он обычно идет в комплекте с графическим интерфейсом (но не во всех GUI).
Репозиторий - это место где мы храним наш код проекта и всю информацию по файлам, их изменения и т.д. Репозиторий должен где-то хранится, чтобы у всех был доступ к нему и они могли видеть изменения. Его можно хранить и на домашнем компьютере, но не всегда удобно держать компьютер включенным целыми сутками, поэтому используют хостинги для репозиториев. Одними из самых известных являются GitHub и GitLab.

GitHub

GitHub - крупнейший веб-сервис для хостинга IT-проектов и их совместной разработки. Веб-сервис основан на системе контроля версий Git и разработан на Ruby on Rails и Erlang компанией GitHub, Inc. Так как мы будем хранить на нём наши репозитории, поэтому мы и выбрали GitHub Desktop, т.к. он разрабатывался специально для максимальной интеграции и упрощения работы с 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 указывает на то, по какой лицензии распространяется код. Про каждую лицензию можно почитать отдельно и в основном они отличаются тем, что можно делать с кодом: продавать, распространять, изменять и т.д. При создании нашего репозитория можно либо выбрать эти файлы, либо оставить их пустыми.

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

GNU GPL;
MIT;
Unlicense;
WTFPL (do whatever you want public license).

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

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

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

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

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

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

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

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

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

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

Ветки

В git есть понятие branch (ветка). Ветка - это покоммитный “путь” до некоторого коммита, называемого “концом” (tip) ветки. Мы можем иметь несколько независимых веток при работе. Коммит делается в конкретную ветку, по умолчанию это ветка master. Создать новую ветку можно как на сайте, так и в приложении GitHub Desktop. Для этого нужно выбрать вкладку Current branch и нажать на New branch:

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

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

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

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

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

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

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

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

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

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

Вот полный рабочий процесс (мы сделали это до открытия React Native с открытым исходным кодом ):

Сначала продублируйте репозиторий, как сказали другие (подробности здесь ):

Создайте новый репозиторий (давайте назовем его private-repo ) через интерфейс Github . Затем:

Клонируйте частное хранилище, чтобы вы могли работать с ним:

Чтобы вытащить новую горячность из публичного репо:

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

Наконец, чтобы создать частное репо с запросом на извлечение -> публичное репо:

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

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

Конечно, весь процесс может быть повторен (просто пропустите шаги, где вы добавляете пульты).

Почему нельзя просто добавить пустое частное репо в качестве нового пульта к обычному клону публичного репо, а затем нажать на него? Какая будет разница?

Я попал на шаг, где я клонировал свой личный репозиторий, а затем внес изменения, а затем подтолкнул. Все сделанные мной изменения остались незамеченными для git. git status показывает все в актуальном состоянии, рабочее дерево чистое, что бы я ни менял. Следовательно, я не могу ничего совершить и подтолкнуть. Я удалил новое частное репо, которое я сделал еще 2 раза, чтобы попытаться сделать это, но продолжал сталкиваться с той же самой проблемой. Какие-либо предложения?

Теперь есть еще один вариант (январь-2015)

Я считаю, что @MattvanAndel означает, что комментарий правильный, а не оригинальный ответ. Я тоже последовал комментарию Шивы, и это сработало. Обратите внимание, что вы НЕ должны сначала создавать локальный частный репозиторий!

Текущие ответы немного устарели, поэтому для ясности:

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

Это задокументировано на GitHub: duplicating-a-repository

Есть ли способ вытащить изменения вверх по течению? Это важно для репо с либеральной лицензией - я сделал свой репозиторий закрытым, но все же хотел бы объединить вышестоящие изменения.

Вы должны дублировать репо

Вы можете увидеть этот документ (из GitHub)

Зеркальное отображение хранилища

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

Откройте командную строку и введите эти команды:

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

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

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

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

Я собирался добавить тот же ответ, но спасибо, что сделал это первым. Рад, что Github Бесплатные частные репо доступны с января прошлого года. : D

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

1- Создание Repository

На github.com, войдите в свою учетную запись. Вы можете увидеть кнопку "Create repository" прямо на главной странице GitHub.

Назовите свой Repository и сделайте его Public или Private. Публичный (Public) repository позволит всем другим пользователям GitHub просматривать или clone (клонировать) ваш repository для создания своего собственного repository, в то время как приватный (Private) repository будет скрыт от всех обычных пользователей и будет использоваться только вами и вашей командой разработчиков.

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