¶ Репозиторий
Репозиторий — каталог файловой системы, в котором могут находиться файлы журналов конфигураций и операций, выполняемых над репозиторием, а также сами контролируемые файлы.
Репозиторий бывает:
- локальный (расположен непосредственно в памяти компьютера разработчика, в нем происходит разработка и фиксация изменений, после чего можно отправить на удаленный репозиторий)
- удаленный (находится на сервере, может быть приватным – доступным ограниченному числу лиц, и публичным – open source)
По умолчанию репозиторий хранится в подкаталоге с названием .git в корневом каталоге рабочей копии дерева файлов, хранящегося в репозитории. Любое файловое дерево в системе можно превратить в репозиторий git, отдав команду создания репозитория из корневого каталога этого дерева (или указав корневой каталог в параметрах программы).
Репозиторий может быть импортирован с другого узла, доступного по сети. При импорте нового репозитория автоматически создается рабочая копия, соответствующая последнему зафиксированному состоянию импортируемого репозитория (то есть не копируются изменения в рабочей копии исходного узла, для которых на том узле не была выполнена команда commit).
Для того чтобы узнать как создать репозиторий перейдите по ссылке:
git quickstart
¶ Зеркалирование репозиториев
Зеркальное отображение репозиториев позволяет выполнять зеркальное отображение репозиториев на внешние источники и из них. Его можно использовать для зеркалирования веток, тегов и коммитов между репозиториями.
Зеркальное отображение репозитория полезно, когда вы хотите использовать репозиторий вне GitLab.
GitLab поддерживает два типа зеркалирования репозитория:
- Push: для зеркалирования репозитория GitLab в другое место.
- Вытягивание: для зеркалирования репозитория из другого места в GitLab.
При обновлении зеркального репозитория все новые ветки, теги и фиксации будут отображаться в ленте активности проекта.
Пользователи, имеющие как минимум доступ к проекту для разработчиков, также могут принудительно выполнить немедленное обновление, если:
- Зеркало уже обновляется.
- С момента последнего обновления не прошло 5 минут.
¶ Случаи применения
Ниже приведены некоторые возможные варианты использования зеркального отображения репозитория:
- Вы перешли на GitLab, но по-прежнему хотите сохранить свой проект в другом источнике. В этом случае вы можете просто настроить его для зеркалирования в GitLab (pull), и вся необходимая история коммитов, тегов и веток будет доступна в вашем экземпляре GitLab.
- У вас есть старые проекты в другом источнике, которые вы больше не используете активно, но не хотите удалять для архивирования. В этом случае вы можете создать push-зеркало, чтобы ваш активный репозиторий GitLab мог отправлять свои изменения в старое расположение.
- Вы являетесь пользователем GitLab с самоуправлением по соображениям конфиденциальности, и ваш экземпляр закрыт для публики, но у вас все еще есть определенные программные компоненты, которые вы хотите использовать с открытым исходным кодом. В этом случае использование GitLab в качестве основного репозитория, закрытого для общественности, и использование push-зеркалирования в общедоступный репозиторий, позволяет вам открывать конкретные проекты с открытым исходным кодом и вносить свой вклад в сообщество с открытым исходным кодом.
¶ Отправка в удаленный репозиторий
Для существующего проекта вы можете настроить push-зеркалирование следующим образом:
- Перейдите в Settings -> Repository и разверните раздел Mirroring repositories.
- Введите URL-адрес репозитория.
- В раскрывающемся списке «Mirror direction» выберите «Push».
- При необходимости выберите метод аутентификации в раскрывающемся списке Authentication method .
- При необходимости установите флажок «Keep divergent refs» (сохранять расходящиеся ссылки).
- При желании установите флажок «Only mirror protected branches» (только защищенные зеркалом ветви) .
- Нажмите кнопку «Mirror repository» , чтобы сохранить конфигурацию.
¶ Что значит сохранить расходящиеся ссылки
По умолчанию, если какая-либо ссылка на удаленном зеркале отличается от локального репозитория, вся отправка завершится неудачей и ничего не будет обновлено.
Например, если в репозитории есть master, develop и stable ветки, которые были зеркалированы на удаленный компьютер, а затем добавляется новый коммит для разработки на зеркале, следующая попытка push завершится неудачно, и master и stable ветки будут отключены. Никакие изменения в любой ветви не могут быть отражены, пока расхождение не будет устранено.
При включенной опции "Keep divergent refs" ветвь develop пропускается, позволяя обновлять master и stable.Статус зеркала будет отражать то, что develop разошлось и было пропущено, и будет помечено как неудачное обновление.
После создания зеркала этот параметр можно изменить только через API .
Когда включено push-зеркалирование, только push фиксируется непосредственно в зеркальном репозитории, чтобы предотвратить расхождение зеркала. Все изменения попадут в зеркальный репозиторий всякий раз, когда:
- Коммиты отправляются в GitLab.
- Инициируется принудительное обновление.
Изменения, отправленные в файлы в репозитории, автоматически отправляются на удаленное зеркало по крайней мере:
- В течение пяти минут после получения.
- В течение одной минуты, если включен параметр «Only mirror protected branches» (только защищенные зеркалом ветви).
Вы можете отправлять только защищенные ветки из GitLab в удаленный репозиторий.
В случае разветвленной ветви вы увидите ошибку, указанную в разделе «Mirroring repositories».
Вы также можете создавать и изменять push-зеркала проекта через API удаленных зеркал.
¶ Извлечение из удаленного репозитория
Вы можете настроить репозиторий так, чтобы его ветки, теги и коммиты автоматически обновлялись из вышестоящего репозитория.
Это полезно, когда интересующий вас репозиторий находится на другом сервере, и вы хотите иметь возможность просматривать его содержимое и его активность с помощью знакомого интерфейса GitLab.
Чтобы настроить вытягивание зеркала для существующего проекта:
- Перейдите в "Settings" -> "Repository" и разверните раздел "Mirroring repositories".
- Введите URL-адрес репозитория.
- Выберите "Pull" в списке от "Mirror direction".
- При необходимости выберите метод аутентификации в раскрывающемся списке "Authentication method".
- При необходимости установите следующие флажки:
- Overwrite diverged branches. (перезаписать расходящиеся ветви)
- Trigger pipelines for mirror updates. (запускайте конвейеры для обновлений зеркал)
- Only mirror protected branches.(только зеркально защищенные ветви)
- Нажмите кнопку «Mirror repository» , чтобы сохранить конфигурацию.
Поскольку GitLab теперь настроен на получение изменений из вышестоящего репозитория, вам не следует отправлять коммиты напрямую в репозиторий GitLab. Вместо этого любые коммиты следует отправлять в вышестоящий репозиторий. Изменения, отправленные в вышестоящий репозиторий, будут перенесены в репозиторий GitLab либо:
- Автоматически в течение определенного периода времени.
- Когда инициируется принудительное обновление.
Если вы вручную обновите ветку в репозитории GitLab, ветка будет отделена от восходящей, и GitLab больше не будет автоматически обновлять эту ветку, чтобы предотвратить потерю любых изменений. Обратите внимание, что удаленные ветки и теги в исходном репозитории не будут отражены в репозитории GitLab.
Для более подробной информации можно перейти по ссылке: Repository mirroring
¶ Коммит
Создать коммит (commit) - значит зафиксировать изменения любых файлов, входящих в репозиторий.
Любые файлы, созданные или измененные вами и для которых вы не выполнили git add после редактирования, не войдут в ваш коммит. Они останутся измененными файлами на вашем диске.
git commit- это команда для записи индексированных изменений в репозиторий Git.
Пример работы с коммитом можно посмотреть в разделе "Быстрый старт в Git"(в блоке "Что такое коммит?").
¶ Если коммиты с другой почты
В статистике Git, размещенной в Личном кабинете, учитываются коммиты, сделанные только с почты с доменом @miem.hse.ru.
Если вы сделали часть коммитов с другой почты, то необходимо добавить ее в настройках аккаунта.
Для этого выполните следующие действия:
- Нажмите на иконку профиля в правом верхнем углу;
- Перейдите в "Settings";
- Выберите раздел "Emails" в боковом меню;
- Там вы сможете указать дополнительную почту:
Обязательно перейдите по ссылке из письма с подтверждением, которое придет на указанный адрес. Чтобы статистика появилась в личном кабинете, необходимо сделать хотя бы один коммит в репозиторий после добавления почты.
¶ Просмотр истории коммитов
После того, как вы создали несколько коммитов или же склонировали репозиторий с уже существующей историей коммитов, вам может понадобится возможность посмотреть, что было сделано, то есть историю коммитов. Для этого используется команда git log.
Если вы запустите команду git log в папке склонированного проекта, то увидите следующий вывод:
По умолчанию (без аргументов) git log перечисляет коммиты, сделанные в репозитории в обратном к хронологическому порядке: последние коммиты находятся вверху.
¶ Поиск коммитов по разным критериям
Команда git log имеет большое количество опций для поиска коммитов по разным критериям. Рассмотрим наиболее популярные из них.
- Одним из самых полезных аргументов является
-pили--patch, который показывает разницу (выводит патч), внесенную в каждый коммит. Вы можете ограничить количество записей в выводе команды; используйте параметр-2для вывода только двух записей:
Эта опция отображает аналогичную информацию, но содержит разницу для каждой записи. Удобно использовать данную опцию для код ревью или для быстрого просмотра серии внесенных изменений.
- Существует возможность использовать серию опций для обобщения. Например, если вы хотите увидеть сокращенную статистику для каждого коммита, вы можете использовать опцию
--stat:
Опция --stat печатает под каждым из коммитов список и количество измененных файлов, а также сколько строк в каждом из файлов было добавлено и удалено.
- Рассмотрим опцию
--pretty. Она меняет формат вывода. Существует несколько встроенных вариантов отображения:
- Опция
onelineвыводит каждый коммит в одну строку, это удобно, если вы просматриваете большое количество коммитов. - Опции
short,fullиfullerделают вывод приблизительно в том же формате, но с меньшим или большим количеством информации соответственно:
- Опция
formatпозволяет указать формат для вывода информации. Это полезно, когда вы хотите сгенерировать вывод для автоматического анализа. Так как вы указываете формат явно, он не будет изменен даже после обновления Git:
Полезные опции для git log --pretty=format отображает наиболее полезные опции для изменения формата.
- Наиболее распространенные опции для команды
git logсодержат описание как уже рассмотренных, так и нескольких новых опций, которые могут быть полезными в зависимости от нужного формата вывода.
¶ Разница между автором и коммитером.
Автор – это человек, изначально сделавший работу, а коммитер – это человек, который последним применил эту работу. Другими словами, если вы создадите патч для какого-то проекта, а один из основных членов команды этого проекта применит этот патч, вы оба получите статус участника: вы как автор и основной член команды как коммитер.
¶ Ограничение вывода
В дополнение к опциям форматирования вывода, команда git log принимает несколько опций для ограничения вывода – опций, с помощью которых можно увидеть определенное подмножество коммитов. Вы уже видели одну из таких опций — это опция -2, которая показывает только последние два коммита.
- В действительности вы можете использовать
-n, где n – это любое натуральное число и представляет собой n последних коммитов. На практике вы не будете часто использовать эту опцию, потому что Git по умолчанию использует постраничный вывод и вы будете видеть только одну страницу за раз.
Полезны такие опции для ограничения вывода по времени, как --since и --until. Например, следующая команда покажет список коммитов, сделанных за последние две недели:
git log --since=2.weeks
Эта команда работает с большим количеством форматов. Вы можете указать определенную дату ("2020-10-20") или же относительную дату, например, "2 years 1 day 3 minutes ago".
Можно фильтровать список коммитов по заданным параметрам. Опция --author дает возможность фильтровать по автору коммита, а опция --grep искать по ключевым словам в сообщении коммита.
Допускается указывать несколько параметров
--authorи--grepдля поиска, которые позволят найти коммиты, сооветствующие любому указанному --author и любому указанному--grepшаблону; однако применение опции--all-matchзаставит искать коммиты соответствующие всем указанным--grepшаблонам.
-
Опция
-Sпринимает аргумент в виде строки и показывает только те коммиты, в которых изменение в коде повлекло за собой добавление или удаление этой строки. Например, если вы хотите найти последний коммит, который добавил или удалил вызов определенной функции, вы можете запустить команду:git log -S <название функции> -
Опция "путь". Если вы укажете директорию или имя файла, вы ограничите вывод только теми коммитами, в которых были изменения этих файлов. Эта опция всегда указывается последней после двойного тире
--, что отделяет указываемый путь от опций.
Опции для ограничения вывода команды git log вы можете увидеть эти и другие распространенные опции.
¶ Ветки
Ветка в Git — это простой перемещаемый указатель на один из таких коммитов. По умолчанию имя основной ветки в Git — master.
Как только вы начнете создавать коммиты, ветка master будет всегда указывать на последний коммит. Каждый раз при создании коммита указатель ветки master будет передвигаться на следующий коммит автоматически.
¶ Создание новой ветки
Что происходит при создании ветки? Создаётся новый указатель для дальнейшего перемещения.
Чтобы создать ветку и сразу переключиться на нее, можно выполнить команду git checkout с параметром -b: git checkout -b testing.
Это тоже самое что и:
$ git branch testing
$ git checkout testing
Здесь мы сначала создали ветку, затем перешли на нее.
Вы всегда можете отследить, на какой ветке находитесь, с помощью команды
git status.
¶ Работа с веткой master
По умолчанию master ветка защищенная (protected). То есть в нее может пушить только Maintainer. Лучше всего работать в другой ветке и делать merge request в master. Либо (не рекомендуется) - убирать защиту с master ветки.
¶ Как сделать merge request
Merge request позволяет перед коммитом в master ветку отправить внесенные изменения другим разработчикам проекта. Это аналог pull request в git. Merge request позволяет предотвратить внесение некорректных изменений, которые сломают проект.
Для начала создадим и перейдем на ветку, с которой будем работать:
git checkout -b <имя ветки> - создание новой ветки и переключение на нее; вместо <имя ветки> мы укажем development.
git add . - точка после git add означает, что git будет следить за всеми файлами;
git commit -m "Комментарий" - вместо <Комментарий> - комментарий к коммиту;
git push -u origin <имя ветки> - вместо <имя ветки>, куда пишем (в нашем случае development)
Далее нужно перейти в настройки вашего проекта, в боковой меню нажмите на "Merge Requests".
В открывшемся окне нажмите на кнопку "New Merge Request" для создания нового запроса на слияния одной ветки с другой.
В разделе выберите ветку, из которой хотите добавить изменения (в нашем случае development). В качестве "Target branch" выберите master.
Затем нажмите на кнопку "Compare branches and continue".
Если не возникло конфликтов, на новой странице задайте заголовок, описание и в поле Assignee выберите своего руководителя.
Рекомендуем вам делать при слиянии веток сквош: объединять коммиты. Это помогает избежать путаницы и длинного списка коммитов. Для этого просто поставьте галочку около пункта "Squash commits when merge request is accepted". Далее нажмите на "Merge".
Подробнее о правильной работе с GitFlow можно прочитать здесь:
Модель ветвления Gitflow