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

2.1 Основы Git — Создание Git-репозитория

Если вы хотите начать работать с Git, прочитав всего одну главу, то эта глава — то, что вам нужно. Здесь рассмотрены все базовые команды, необходимые вам для решения подавляющего большинства задач, возникающих при работе с Git. После прочтения этой главы вы научитесь настраивать и инициализировать репозиторий, начинать и прекращать контроль версий файлов, а также подготавливать и фиксировать изменения. Мы также продемонстрируем вам, как настроить в Git игнорирование отдельных файлов или их групп, как быстро и просто отменить ошибочные изменения, как просмотреть историю вашего проекта и изменения между отдельными коммитами (commit), а также как отправлять (push) и получать (pull) изменения в/из удалённого (remote) репозитория.

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

Обычно вы получаете репозиторий Git одним из двух способов:

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

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

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

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

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

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

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

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

Мы разберем, что делают эти команды чуть позже. Теперь у вас есть Git-репозиторий с отслеживаемыми файлами и начальным коммитом.

Клонирование существующего репозитория

Для получения копии существующего Git-репозитория, например, проекта, в который вы хотите внести свой вклад, необходимо использовать команду git clone . Если вы знакомы с другими системами контроля версий, такими как Subversion, то заметите, что команда называется «clone», а не «checkout». Это важное различие — вместо того, чтобы просто получить рабочую копию, Git получает копию практически всех данных, которые есть на сервере. При выполнении git clone с сервера забирается (pulled) каждая версия каждого файла из истории проекта. Фактически, если серверный диск выйдет из строя, вы можете использовать любой из клонов на любом из клиентов, для того, чтобы вернуть сервер в то состояние, в котором он находился в момент клонирования (вы можете потерять часть серверных хуков (server-side hooks) и т. п., но все данные, помещённые под версионный контроль, будут сохранены, подробнее об этом смотрите в разделе Установка Git на сервер главы 4).

Клонирование репозитория осуществляется командой git clone <url> . Например, если вы хотите клонировать библиотеку libgit2 , вы можете сделать это следующим образом:

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

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

Настройка репозитория

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

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

• Инициализация нового репозитория Git
• Клонирование существующего репозитория Git
• Коммит измененной версии файла в репозиторий
• Конфигурирование репозитория Git для удаленной совместной работы
• Распространенные команды для управления версиями Git

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

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

Репозиторий Git — это виртуальное хранилище проекта. В нем можно хранить версии кода для доступа по мере необходимости.

Инициализация нового репозитория: git init

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

Создание версии существующего проекта с использованием нового репозитория Git

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

Указание в команде git init существующего каталога проекта приведет к исполнению описанной выше инициализации, но только на уровне этого каталога проекта.

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

Клонирование существующего репозитория: git clone

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

Команду git clone выполняют для создания копии (клонирования) удаленного репозитория. В качестве параметра в команду git clone передается URL-адрес репозитория. Git поддерживает несколько различных сетевых протоколов и соответствующих форматов URL-адресов. В этом примере используется SSH-протокол Git. URL-адреса SSH в Git имеют следующий шаблон: git@HOSTNAME:USERNAME/REPONAME.git

Пример URL-адреса SSH в Git имеет вид: git@bitbucket.org:rhyolight/javascript-data-store.git , а ниже приведены значения шаблонных параметров:

• HOSTNAME: bitbucket.org
• USERNAME: rhyolight
• REPONAME: javascript-data-store

После исполнения команды последние версии файлов из главной ветки удаленного репозитория будут загружены и помещены в новый каталог. Имя нового каталога будет соответствовать параметру REPONAME. В данном случае это javascript-data-store . В каталоге будет вся история удаленного репозитория и только что созданная главная ветка.

Дополнительную информацию об использовании команды git clone и поддерживаемых форматах URL-адресов в Git см. на странице git clone.

Сохранение изменений в репозитории: git add и git commit

У вас появился репозиторий, созданный путем клонирования или инициализации. Теперь вы можете выполнять коммиты изменений в версиях файлов. В следующем примере предполагается, что вы настроили проект в каталоге /path/to/project . В этом примере предлагаются следующие шаги.

• Измените каталоги на /path/to/project
• Создайте новый файл CommitTest.txt с текстом

«тест для обучения работе с Git»

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

В этом примере представлены две новые команды в Git: add и commit . Этот очень упрощенный пример. Подробнее обе команды объяснены на страницах git add и git commit. Команду git add часто используют с флагом —all . Команда git add —all добавляет все измененные и неотслеживаемые файлы в репозиторий и обновляет дерево изменений репозитория.

Совместная работа в разных репозиториях: git push

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

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

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

Сравнение чистых и клонированных репозиториев

Если в предыдущем разделе («Инициализация нового репозитория») для настройки локального репозитория вы использовали команду git clone , ваш репозиторий уже готов к удаленной совместной работе. Команда git clone автоматически настроит репозиторий, в котором значение remote будет соответствовать URL-адресу Git, из которого был клонирован репозиторий. Это означает, что после изменений файла и выполнения коммита вы можете сразу выполнить команду git push , чтобы отправить эти изменения в удаленный репозиторий.

Если вы использовали команду git init для создания репозитория с нуля, у вас не будет удаленного репозитория, в который можно помещать изменения. Зачастую для инициализации нового репозитория пользователь переходит на сервис Git-хостинга (например, Bitbucket) и создает репозиторий там. Данный сервис предоставит URL-адрес Git, который затем можно добавить в локальный репозиторий Git. После этого можно выполнять команду git push в репозиторий на хостинге. После создания удаленного репозитория на выбранном хостинге вам понадобится обновить локальный репозиторий, выполнив привязку. Этот процесс описывается далее в руководстве по установке и настройке.

Если вы предпочитаете поддерживать собственный удаленный репозиторий, вам нужно создать «чистый репозиторий». Для этого команды git init и git clone принимают аргумент —bare . Наиболее популярная причина использования чистого репозитория — создание удаленного центрального репозитория Git

Конфигурирование и настройка: git config

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

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

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

Дополнительную информацию о команде git remote см. на странице удаленной работы в Git .

Помимо конфигурирования URL-адреса удаленного репозитория, вам может потребоваться установить глобальные параметры Git, например имя пользователя или электронный адрес. Команда git config позволяет настроить инсталляцию Git (или отдельный репозиторий) из командной строки. С помощью этой команды можно установить любые настройки: от информации о пользователе до его предпочтений и характеристик репозитория. Ниже перечислены распространенные варианты конфигурации.

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

• Локальный: /.git/config — настройки на уровне репозитория.
• Глобальный: /.gitconfig — настройки на уровне пользователя. Здесь хранятся настройки с флагом —global.
• Системный: $(prefix)/etc/gitconfig — настройки на уровне всей системы.

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

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

Добавление аргумента —local или выполнение команды без параметра уровня конфигурации приведет к установке значения user.name для текущего локального репозитория.

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

Создайте быстрые клавиши для команды Git. Это мощная возможность для создания собственных комбинаций клавиш для часто используемых команд Git. Ниже показан упрощенный пример:

Так создается команда ci , которую можно использовать как сокращение команды git commit . Подробнее об алиасах в Git см. на странице git config.

Выберите текстовый редактор, используемый для таких команд, как git commit , для всех пользователей текущего компьютера. Аргумент должен представлять собой команду, запускающую нужный редактор (например, vi). В этом примере представлен аргумент —system . Аргумент —system устанавливает настройку на уровне всей системы, включая всех пользователей и все репозитории на компьютере. Дополнительную информацию об уровнях конфигурации см. на странице удаленной работы с git.

В текстовом редакторе откройте файл глобальной конфигурации для редактирования вручную. Подробное руководство по настройке текстового редактора для Git см. на странице Git config.

Пояснения

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

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

/.git/config — настройки на уровне репозитория.

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

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

Пример

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

Представьтесь репозиторию Git с помощью команды git config

Выберите любимый текстовый редактор

Добавьте алиасы по типу SVN

/.gitconfig , описанный в предыдущем разделе. Подробную информацию о команде git config см. на странице Git config.

Резюме

Мы показали, как создать репозиторий Git двумя способами: git init и git clone. Этим руководством можно пользоваться при необходимости управления исходным кодом ПО или другим контентом, при хранении которого требуется поддерживать версионность. Кроме того, были представлены команды git add, git commit, git push и git remote и показаны простые примеры их использования.

git — the simple guide

Ваш локальный git репозиторий состоит из трех «сущностей». Рабочий каталог (Working Directory) содержит файлы. Индекс (Index) или область подготовленных файлов (Staging Area) , содержит информацию о том, что должно войти в следующий коммит и HEAD указывает на последний коммит что вы сделали.

Подготовка и коммит

Чтобы подготовить изменения (добавить их в Индекс), используйте
git add <имя_файла>
git add *
Это первый шаг в основном рабочем процессе. Сделать коммит подготовленных изменений можно командой
git commit -m «Описание коммита»
Теперь изменения закреплены в локальном репозитории, и на них указывает HEAD, но еще не в удаленном репозитории.

отправка изменений

Чтобы отправить эти изменения в ваш удаленный репозиторий, выполните
git push origin master
Можно изменить master на любую другую ветвь, чтобы отправить изменения на неё.

Если вы еще не клонировали существующий репозиторий и хотите подключить ваш к удаленному, вам нужно добавить его, выполнив
git remote add origin <адрес_сервера>
Теперь вы можете отправлять изменения на удаленный репозиторий

ветвление

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

Создать новую ветку с названием «feature_x» и переключиться на неё можно командой
git checkout -b feature_x
переключиться обратно на master
git checkout master
удалить ветку
git branch -d feature_x
ветка не будет доступна тем, кто пользуется с вами удаленным репозиторием, пока вы не отправите её туда
git push origin <имя_ветки>

обновление и слияние

Обновить ваш локальный репозиторий можно командой
git pull
которая заберет изменения из удаленного репозитория и проведет слияние с активной веткой.
Для того чтобы слить другую ветку с активной (например master), используйте команду
git merge <имя_ветки>
В обоих случаях git пытается автоматически слить изменения. К сожалению, это не всегда возможно и результатом станет конфликт. Вы ответственны за разрешение возникших конфликтов, путем ручного редактирования файлов, указанных git. После изменений вам надо пометить их как слитые
git add <имя_файла>
перед слиянием вы можете предварительно посмотреть на изменения
git diff <имя_ветки> <имя_другой_ветки>

метки

Рекомендуется использовать метки для закрепления момента выпуска версий. Это популярная практика, которая также используется в SVN. Создать новую метку с именем 1.0.0 можно, выполнив
git tag 1.0.0 1b2e1d63ff
1b2e1d63ff это первые десять цифр уникального идентификатора (id), с которым будет связана метка. Чтобы посмотреть идентификаторы коммитов, выполните
git log
Можно использовать меньшее количество символов в качестве идентификатора, с учетом того, что он является уникальным.

замена локальных изменений

В случае, если вы сделали что-то не то, вы можете заменить локальные изменения, используя команду
git checkout — <имя_файла>
произойдет замена изменений в вашем рабочем каталоге, на то, что сейчас находится в HEAD. Изменения, уже внесенные в индекс, также как и новые файлы, будут сохранены.

Если же вы хотите удалить все ваши локальные изменения и коммиты, получите (fetch) последние изменения с сервера и укажите локальной ветке master на них вот так
git fetch origin
git reset —hard origin/master

Create a repo

To put your project up on GitHub, you will need to create a repository for it to live in.

В репозиториях GitHub можно хранить различные проекты, в том числе с открытым кодом. Проекты с открытым кодом позволяют предоставлять общий доступ к коду, чтобы создавать более качественное и надежное программное обеспечение. С помощью репозиториев можно вести совместную работу с другими пользователями и отслеживать ее. Дополнительные сведения см. в разделе About repositories. Дополнительные сведения о проектах с открытым кодом см. на сайте OpenSource.org.

Примечания.

• Для проекта с открытым кодом можно создать общедоступные репозитории. При создании общедоступного репозитория обязательно включите файл лицензии, определяющий способ совместного использования проекта с другими пользователями. Дополнительные сведения о продуктах с открытым кодом, особенно о создании и развитии проекта с открытым кодом, мы создали руководства по продуктам с открытым кодом, которые помогут создать работоспособный открытый код сообщества, формируя практические рекомендации по созданию и обслуживанию репозиториев для проекта с открытым кодом.
• Вы также можете пройти бесплатный курс GitHub Skills по поддержанию сообществ разработчиков продуктов с открытым кодом.
• Вы также можете добавить файлы работоспособности сообщества в репозитории, настроить рекомендации по участию, сохранить репозитории в безопасносном месте и многое другое. Дополнительные сведения см. в разделе Creating a default community health file.

1. В правом верхнем углу любой страницы откройте раскрывающееся меню

и выберите Новый репозиторий.

1. Настройте видимость репозитория. Дополнительные сведения см. в разделе About repositories.

1. Выберите Initialize this repository with a README (Инициализировать репозиторий с помощью файла сведений).

1. Щелкните Создать репозиторий.

Поздравляем! Вы успешно создали первый репозиторий и инициализировали его с помощью файла сведений.

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

1. В командной строке перейдите в каталог, в котором нужно создать локальный клон нового проекта.
2. Чтобы создать репозиторий для проекта, используйте подкоманду gh repo create . При появлении запроса выберите Создать репозиторий на GitHub с нуля и введите имя нового проекта. Если вы хотите, чтобы проект принадлежал организации, а не вашей личной учетной записи, укажите имя организации и имя проекта с помощью organization-name/project-name .
3. Следуйте интерактивным инструкциям. Чтобы клонировать репозиторий локально, при получении запроса подтвердите клонирование удаленного каталога проекта.
4. Можно также пропустить запросы, указав имя репозитория и флаг видимости ( —public , —private или —internal ). Например, gh repo create project-name —public . Чтобы клонировать репозиторий локально, передайте флаг —clone . Дополнительные сведения о возможных аргументах см. в руководстве по GitHub CLI.

Фиксация первого изменения

Фиксация похожа на моментальный снимок всех файлов проекта на определенный момент времени.

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

Давайте зафиксируем изменение в файле сведений.

В списке файлов репозитория щелкните файл README.md.

1. Над новым содержимым щелкните элемент Просмотреть изменения.

1. В нижней части страницы введите короткое понятное сообщение о фиксации, описывающее внесенное в файл изменение. В таком сообщении фиксацию можно отнести к нескольким авторам. Дополнительные сведения см. в разделе Creating a commit with multiple authors.

1. Под полями сообщения о фиксации укажите, куда следует добавить фиксацию: в текущую ветвь или в новую. Если текущей ветвью является ветвь по умолчанию, нужно создать новую ветвь для фиксации, а затем создать запрос на вытягивание. Дополнительные сведения см. в разделе Creating a pull request.

1. Щелкните Предложить изменение файла.

Теперь, когда проект создан, можно начать фиксацию изменений.

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

В командной строке перейдите в корневой каталог нового проекта. (Этот каталог был создан при выполнении команды gh repo create .)

Создайте файл сведений со сведениями о проекте.

Введите git status . Вы увидите, что есть неотслеживаемый файл README.md .

Подготовьте и зафиксируйте файл.

Отправьте изменения в свою ветвь.

Теперь вы создали репозиторий, включая файл сведений , и создали первую фиксацию в GitHub.com.

• Теперь можно клонировать репозиторий GitHub, чтобы создать локальную копию на своем компьютере. В локальном репозитории можно выполнять фиксации и создавать запросы на вытягивание, чтобы передавать изменения в вышестоящий репозиторий. Дополнительные сведения см. в разделах Cloning a repository и Set up Git.

На GitHub можно найти интересные проекты и репозитории, в которые можно внести изменения, создав вилку репозитория. Создание вилки репозитория позволит вносить изменения в другой репозиторий, не затрагивая исходный. Дополнительные сведения см. в разделе Fork a repo.

Каждый репозиторий на GitHub принадлежит пользователю или организации. Вы можете взаимодействовать с людьми, репозиториями и организациями, подписавшись на них на GitHub. Дополнительные сведения см. в разделе Be social.

У GitHub большое сообщество поддержки, где можно обратиться за помощью и поговорить с людьми со всего мира. Присоединиться к беседе можно в GitHub Community.