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

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

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

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

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

Выбираем «Public»:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаг 1. Зайдите в свой аккаунт на GitLab и нажмите на иконку «Groups» в верхней панели.

Шаг 2. Затем перейдите во вкладку «Your group».

Шаг 3. Выберите команду с названием вашего учебного проекта.

Шаг 4. Вы перешли на страницу своей команды. Теперь нужно создать репозиторий. Для этого нажмите на кнопку «New project».

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

Шаг 5. Напишите название вашего репозитория и добавьте нужные данные. Готово!

Шаг 6.

Перенос существующего репозитория
Если у вас уже есть репозиторий на MIEM GitLab, то его легко можно перенести:

Для этого зайдите на страницу нужного вам проекта. Далее перейдите в настройки.

Опуститесь до раздела «Advanced» и разверните его с помощью кнопки «Expand».

Найдите внутри блок «Transfer project» и с помощью селектора выберите новое расположение.

Перенос существующего репозитория с другой платформы

Если проект был создан на другой платформе (Github, Bitbucket и т.д.), то при создании нового репозитория откройте вверху вкладку «Import project» вместо «Blank project», а затем выберите » Repo by URL».

Подробнее о миграции проектов.

При этом вся информация по коммитам будет перенесена. Однако, чтобы она корректно отображалась и учитывалась в статистике, необходимо, чтобы коммиты были сделаны с почты @miem.hse.ru. Если коммиты были сделаны с другой почты, то необходимо добавить ее адрес в личном кабинете в Git.miem.hse.ru (подробнее в блоке «Коммит»)

Part 3: Exploring GitHub Desktop

In the file menu at the top of the screen, you can access settings and actions that you can perform in GitHub Desktop. Most actions also have keyboard shortcuts to help you work more efficiently. For a full list of keyboard shortcuts, see «Keyboard shortcuts.»

The GitHub Desktop menu bar

At the top of the GitHub Desktop app, you will see a bar that shows the current state of your repository.

Current repository shows the name of the repository you’re working on. You can click Current repository to switch to a different repository in GitHub Desktop.
Current branch shows the name of the branch you’re working on. You can click Current branch to view all the branches in your repository, switch to a different branch, or create a new branch. Once you create pull requests in your repository, you can also view these by clicking on Current branch.
Publish repository appears because you haven’t published your repository to GitHub yet, which you’ll do later in the next step. This section of the bar will change based on the status of your current branch and repository. Different context dependent actions will be available that let you exchange data between your local and remote repositories.

Changes and History

In the left sidebar, you’ll find the Changes and History views.

The Changes view shows changes you’ve made to files in your current branch but haven’t committed to your local repository. At the bottom, there is a box with «Summary» and «Description» text boxes and a Commit to BRANCH button. This is where you’ll commit new changes. The Commit to BRANCH button is dynamic and will display which branch you’re committing your changes to.
The History view shows the previous commits on the current branch of your repository. You should see an «Initial commit» that was created by GitHub Desktop when you created your repository. To the right of the commit, depending on the options you selected while creating your repository, you may see .gitattributes, .gitignore, LICENSE, or README files. You can click each file to see a diff for that file, which is the changes made to the file in that commit. The diff only shows the parts of the file that have changed, not the entire contents of the file.

Синтаксис

Для добавления кода из локального git-репозитория используется следующий синтаксис:

— (не обязательный параметр) путь к директории или файлу, содержимое которого (которой) нужно добавить в образ. Указывается абсолютный путь относительно корня репозитория, т.е. он должен начинаться с . По умолчанию копируется все содержимое репозитория, отсутствие параметра равносильно указанию ;
— путь внутри образа, куда будет скопировано соответствующее содержимое;
— имя или id пользователя-владельца файлов в образе;
— имя или id группы-владельца файлов в образе;
— список исключений (маска) при рекурсивном копировании файлов и папок. Указывается относительно пути, указанного в ;
— список масок файлов и папок для рекурсивного копирования. Указывается относительно пути, указанного в ;
— список масок файлов и папок для указания зависимости пересборки стадии от их изменений. Позволяет указать, при изменении каких файлов и папок необходимо принудительно пересобирать конкретную пользовательскую стадию. Более подробно рассматривается здесь.

При использовании удаленных репозиториев дополнительно используются следующие параметры:

— адрес удаленного репозитория;
, , — имя ветки, тега или коммита соответственно. По умолчанию — ветка master.

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

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

> git log
fatal: your current branch 'master' does not have any commits yet

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

> git status
On branch master

Initial commit

nothing to commit (create/copy files and use "git add" to track)

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

> touch README.md

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

> git status
On branch master

Initial commit

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        README.md

nothing added to commit but untracked files present (use "git add" to track)

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

> git add README.md

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

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

> git status
On branch master

Initial commit

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

        new file:   README.md

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

> git commit -m ""
 
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 README.md

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

> git status
On branch master
nothing to commit, working tree clean

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

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

> git log
commit 500067cc0b80643d38e2a24e9e0699031ada6be3
Author: Writer <[email protected]>
Date:   Mon Feb 12 22:51:14 2018 +0500

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

> git log --oneline
500067c

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

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

> git init

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

> git add filename

Создание коммита.

> git commit -m “message”

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

> git status

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

> git log

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

> git log --oneline

<<< Часть 4. Архитектура Git Часть 6. Просмотр информации по коммитам >>>

Что такое коммит и коммитить?

По-английски commit значит «фиксировать». Git-коммит — это операция, которая берет все подготовленные изменения и отправляет их в репозиторий как единое целое.

Зачем нужен коммит, если Git и так следит за всеми изменениями? Коммиты разбивают процесс разработки, состоящий из большого количества правок, на отдельные шаги. То есть коммит — это некое логически завершенное изменение внутри проекта и понятная (в том числе и другим разработчикам) точка, к которой можно вернуться, если возникнут какие-то проблемы.

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

Как правило, рабочий процесс представляет собой цикл: коммит — изменение файлов — коммит.

Каждому коммиту можно присвоить сообщение. Источник

Для чего нужен Git

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

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

Система контроля версий хранит историю изменений со временем. Так вы можете безбоязненно вносить абсолютно любые изменения, предварительно «сохранившись». В любой момент времени можно откатиться на любой checkpoint в прошлом.

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

Инструмент 1: Добавление членов команды

Как правило, существует два способа настройки Github для совместной работы:

Организации. Владелец организации может создавать множество команд с разными уровнями доступа для различных репозиториев
Сотрудники. Владелец репозитория может добавлять коллабораторов с доступом Read + Write для одного репозитория

Organizations

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

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

Pull Only: выборка и слияние с другим репозиторием или локальной копией. Доступ только для чтения.
Push and Pull: (1) наряду с обновлением удаленного репозитория. Читайте + Запись.
Push, Pull & Administrative: (1), (2) наряду с правами на информацию о выставлении счетов, созданием команд, а также удаление аккаунтов организации. Чтение + запись + доступ администратора

Соавторы

Коллабораторы (соавторы) используются для предоставления возможности «читать + писать» в один репозиторий, принадлежащий личной учетной записи. Чтобы добавить Collaborators (другие личные учетные записи Github), перейдите на страницу :

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

Инструмент 5: Управление проектами

В то время как issues Github имеют возможности управления проектами с помощью Issues и Milestones, некоторые команды могут предпочесть другой инструмент из-за других функций или существующего рабочего процесса. В этом разделе мы увидим, как мы можем связать Github с двумя другими популярными инструментами управления проектами — Trello и Pivotal Tracker. С помощью сервисов Github мы можем автоматизировать задачу обновления с помощью коммитов, проблем и многих других действий. Эта автоматизация помогает не только экономить время, но и повышает точность обновлений для любой команды разработчиков программного обеспечения.

Github и Trello

Trello обеспечивает простой, визуальный способ управления задачами. Используя Agile Software Development, карточки Trello могут эмулировать простую виртуальную Kanban Board. В качестве примера мы автоматически создадим карточку Trello всякий раз, когда будет появляться новый пул реквест с помощью Github Service Hooks. Давайте пройдем через все шаги!

Откройте свой аккаунт в Trello, если у вас его еще нет, и создайте новую доску Trello.
Перейдите в репозиторий Github> Настройки> Хуки для сервисов> Trello
Получите в разделе «Примечания по установке» № 1 с гиперссылкой, предоставленной для аутентификации.
В разделе Примечания по установке #2 используйте URL-адрес для создания форматированной в json структуры, которая дает нам для каждой карточки Trello. является частью URL-адреса, когда мы посещаем доску на странице . можно создать с помощью гиперссылки, указанной в разделе Примечания по установке #1.
Вернитесь в сервисные хуки Github, введите и . Установите Active, Test Hook, и теперь все настроено на автоматическое обновление каждый раз, когда будет новый пул реквест.
В следующий раз, когда появится запрос, у карточки Trello Pull Request автоматически будет новый элемент!

Github и Pivotal Tracker

Pivotal Tracker — еще один легкий гибкий инструмент управления проектами, в котором планирование на основе истории позволяет команде легко взаимодействовать, мгновенно реагируя на различные изменения и прогресс проекта. Основываясь на текущем прогрессе команды, он также может создавать диаграммы для анализа скорости команды, итераций разработки, релизов и прочего. В этом кратком примере мы автоматически доставим историю, связав ее с коммитом на Github!

Создайте новый проект в Pivotal Tracker с новой Story которая должна быть сделана.
Перейдите в профиль> API-токен (справа внизу). Скопируйте указанный API токен.
Вернитесь в репозиторий Github> Настройки> Хуки для сервисов> Pivotal Tracker. Вставьте токен, установите флажок Активно и нажмите «Обновить настройки». Теперь все настроено на автоматическое предоставление данных для Pivotal Tracker Stories из коммитов на Github!
Наконец, мы зафиксируем наши изменения и добавим идентификатор трекера в сообщение фиксации в формате
Теперь, когда мы вернемся к Pivotal Tracker, мы увидим, что история была автоматически доставлена со ссылками на конкретный коммит Github, который показывает изменения файла!

С примерами Trello и Pivotal Tracker ясно, что мы можем тесно связать наш список задач и обновления с нашими коммитами. Это огромная экономия времени при работе в команде, и это повышает точность при связывании задач с точными фиксациями. Хорошей новостью является то, что если вы уже используете другие инструменты управления проектами, такие как Asana, Basecamp и другие, вы также можете создать Service Hooks аналогичным образом. Если для вашего текущего инструмента управления проектами нет существующих сервисных хуков, вы даже можете их создать сами!

Основы работы с удаленным репозиторием¶

git clone — создание копии (удаленного) репозитория

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

Клонируем репозиторий, используя протокол http:

git clone http://user@somehost:port/~user/repository/project.git

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

git clone /home/username/project myrepo

Клонируем репозиторий, используя безопасный протокол ssh:

git clone ssh://user@somehost:port/~user/repository

У git имеется и собственный протокол:

git clone git://user@somehost:port/~user/repository/project.git/

Импортируем svn репозиторий, используя протокол http:

git svn clone -s http://repo/location

-s

git fetch и git pull — забираем изменения из центрального репозитория

Для синхронизации текущей ветки с репозиторием используются команды git fetch и git pull.

git fetch — забрать изменения удаленной ветки из репозитория по умолчания, основной ветки; той, которая была использована при клонировании репозитория. Изменения обновят удаленную ветку (remote tracking branch), после чего надо будет провести слияние с локальной ветку командой git merge.

git fetch /home/username/project — забрать изменения из определенного репозитория.

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

git remote add username-project /home/username/project

git fetch username-project — забрать изменения по адресу, определяемому синонимом.

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

git merge username-project/master

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

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

git pull

Забрать изменения и метки из определенного репозитория:

git pull username-project --tags

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

git push — вносим изменения в удаленный репозиторий

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

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

git push

Отправить изменения из ветки master в ветку experimental удаленного репозитория:

git push ssh://yourserver.com/~you/proj.git master:experimental

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

git push origin :experimental

В удаленную ветку master репозитория origin (синоним репозитория по умолчанию) ветки локальной ветки master:

git push origin master:master

Отправить метки в удаленную ветку master репозитория origin:

git push origin master --tags

Изменить указатель для удаленной ветки master репозитория origin (master будет такой же как и develop)

git push origin origin/develop:master

Добавить ветку test в удаленный репозиторий origin, указывающую на коммит ветки develop:

git push origin origin/develop:refs/heads/test

Инструмент 8: документация

В этом разделе мы рассмотрим два метода создания документации:

Формальная документация: Github Wiki для создания документации для исходного кода
Неофициальная документация: Github Hubot документирует обсуждения между членами команды и автоматизирует поиск информации, взаимодействуя с бот-чатом!
Упоминания, ярлыки и эмози

Github Wiki

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

Одна вещь, которую я нахожу очень полезной, — это интеграция Github Wiki в основной проект исходного кода, так что мне не нужно поддерживать два отдельных проекта git. Для этого я добавляю Wiki git repo как субмодуль из ветки master. Если вы используете Travis CI или любой другой CI, убедитесь, что инструмент сборки игнорирует подмодуль wiki. Для файла Travis CI добавьте следующее:

Затем добавьте wiki-подмодуль git в основной репозиторий кода:

Теперь Wiki будет выглядеть как подмодуль в основном проекте с исходным кодом.

Github Hubot

Hubot — это просто бот-чат, который может получать информацию или предоставлять уведомление при подключении к Github коммитам, issues или активности. В команде, которая стремится значительно сократить количество встреч или даже полностью устранить их, Hubot с интерфейсом чата среди членов команды помогает документировать каждую отдельную дискуссию. Это, безусловно, способствует гибкому графику работы, так как никто не должен присутствовать одновременно для обсуждения. Предупреждение: Hubot ужасно вызывает привыкание!

Итак давайте начнем с настройки Hubot, размещенным на Heroku, и ботом с интерфейсом чата Campfire! Для обоих и Heroku и Campfire есть бесплатные версии, с которым можно начать.

Мы воспользуемся версией Hubot от Github’s Campfire. Если вы хотите, вы можете выбрать адаптеры для других чатов, таких как Skype, IRC, Gtalk и т.д.
Откройте новую учетную запись Campfire только для Hubot, и эта учетная запись создаст новую комнату для чата, в которую все остальные будут приглашены позже.
Разверните Hubot на Heroku с помощью этой инструкции, приведенной на Hubot Wiki. Не волнуйтесь, если URL-адрес приложения heroku дает сообщение , поскольку по умолчанию еще нечего делать.
С учетной записью Hubot Campfire пригласите себя. Теперь войдите в свою учетную запись Campfire и выполните команду . Эта команда предоставит вам все доступные команды для hubot.
Попробуйте что-нибудь, например, или .
Затем добавим скрипт Hubot. Существует множество доступных команд с иллюстрациями.
В качестве примера мы добавим скрипт github-commits, чтобы каждый раз, когда есть фиксация, Hubot уведомит нас об этом в чате. Поместите файл внутри папки .
Обновите файл с соответствующими зависимостями, как указано в начале каждого файла сценария hubot, в комментариях.
Разверните изменения на Heroku еще раз с помощью .
Перейдите в репозиторий на Github, чье уведомление об фиксации будет отображаться в чате. Добавьте веб-хук в настройки репозитория. В случае с указанным сценарием «github-commit» webhook будет
В следующий раз, когда в репозитории будет фиксация, Hubot будет об этом говорить и писать в чат!

Ознакомьтесь с другими скриптами Hubot, связанными с Github, или если вы хотите написать один, есть крутой учебник по этому поводу! Короче говоря, Hubot может значительно добавить веселья в документировании и уведомлении командных дискуссий о важных коммитах, проблемах и действиях, происходящих с нашими репозиториями на Github. Попробуйте его!

В качестве заключительной заметки о командной работе на Github, вот несколько советов по производительности:

Упоминания. В любой текстовой области мы можем указать другого пользователя github с , и пользователь получит уведомление о комментарии
Клавиши быстрого доступа — нажмите Для доступа к клавишам быстрого доступа Github на любой странице.
Emoji — Используйте список Emoji, Github textareas также поддерживает вставку этих значков. Попробуйте их и повеселитесь со своими товарищами по команде!