Gitlab как разрешить force push

Запрет push в ветку master

Как сделать, чтобы обновить ветку master могли только путём merge. Итого с веткой master могут выполняться только действия: merge fetch pull Сейчас же любой джуниор может «повесилить» всю команду. Да откатили, да наругали — но не он первый, не он последний. Если на сервер залить какой-то скрипт проблема будет, то можно же наверно и локально устанавливать с bash’ем скрипт, который запретит делать «беду»

Отслеживать

rikimaru2013

задан 2 янв 2016 в 19:32

rikimaru2013 rikimaru2013

2,653 1 1 золотой знак 19 19 серебряных знаков 23 23 бронзовых знака

возможно, настало время воспользоваться gitolite-ом?

2 янв 2016 в 20:20

@alexanderbarakin состовьте ответ — отмечу пологающе. Пока, что я помню, что это серверная вещь, которая на github не прокатит

Шпаргалка по Git. Решение основных проблем

В том случае, если изменения, внесённые пользователем, находятся в режиме накопления, применить их к ветке можно с помощью команды git stash apply. Также можно запустить git diff — эта команда поможет выявить различия. Для того, чтобы затем избавиться от накопленных данных, нужно запустить команду:

git stash drop 

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

git stash list затем можно применить его, воспользовавшись его индексом:

git stash@

Необходимо учитывать, что отсчёт индексов ведётся от нуля.

Восстановление удалённого тега

В том случае, если необходимо восстановить случайно удалённый тег, начать можно с его поиска:

git fsck --unreachable | grep tag 

После того, как нужный тег найден, его следует восстановить:

git update-ref refs/tags/название-тега 

Восстановление удалённого файла

Если вы случайно удалили файл, его можно быстро восстановить:

git checkout myfile.txt 

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

git checkout $commit~1 myfile.txt 

Восстановление удалённой ветки

С помощью комманды git reflog можно узнать хеш (SHA1) последнего коммита в удалённой ветке. Скопируйте этот хеш и используйте в команде:

git checkout

После этого восстановить удалённую ветку можно будет вот такой командой:

git checkout -b

Изменение сообщения коммита перед его отправкой

Изменить сообщение коммита можно с помощью команды git commit —amend , она откроет редактор, в котором можно будет внести необходимые поправки в последнее сообщение.

Сообщение можно изменить и напрямую с помощью команды

git commit --amend -m "Новое прекрасное сообщение" 

Изменение сообщения коммита после его отправки

В данном случае процесс занимает два шага. Сначала нужно изменить сообщение с помощью комманды git commit —amend , а затем перезаписать историю коммитов локальной ветки: git push —force

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

Использование алиасов команд в командной строке

Устали каждый раз печатать git status? Этой команде можно присвоить простой алиас, который проще и быстрее вбивать в git.

git config --global alias.st status 

— теперь нужно писать только git st

Можно пойти дальше и присвоить алиасы более сложным командам:

git config --global alias.logme 'log -p --author=Rob' 

Теперь алиас git logme будет выводить все наши коммиты.

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

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

git checkout -b название-новой-ветки. 

А затем переключиться к оригинальной ветке:

git checkout название-оригинальной-ветки 

. и «откатиться» до последнего коммита, который нужно сохранить.

Чтобы это сделать, можно воспользоваться командой git log и сохранить хеш (SHA1) последнего коммита, который нужно оставить. Например, это a31a45c.

Теперь его нужно сбросить: git reset —hard a31a45c и отправить получившийся результат.

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

Обновление конкретного подмодуля

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

git submodule update --remote --merge

Откат к конкретному коммиту в истории

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

git reset --hard HEAD~1 

Эта команда установит HEAD на конкретный коммит. Также можно воспользоваться хешем коммита.

Отмена коммита до публикации изменений

Если вы сделали коммит, который впоследствии понадобилось отредактировать или полностью стереть, поможет команда git reset.

git reset HEAD~1 # отменить последний коммит, сохранить изменения git reset --hard HEAD~1 # отменить последний коммит, стереть изменения 

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

Чтобы сохранить сообщение коммита, наберите: :

git commit -i ORIG_HEAD 

Отмена коммита после отправки его в master-репозиторий

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

git revert b712c3c 

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

git revert HEAD^ 

Простая отмена последнего коммита:

git revert -n HEAD 

Отмена локальных изменений файлов

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

git checkout myfile.txt 

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

git checkout -- путь-до-файла 

Отображение всех коммитов одного файла

Если вы хотите просмотреть все коммиты с изменениями конкретного файла, воспользуйтесь командой git log —follow -p — myfile

Аргумент —follow позволяет вывести все изменения над файлом, даже если в процессе работы он был переименован.

Если опустить опцию -p, то система выведет только сообщения коммитов, но не их содержимое.

Отображения числа коммитов от каждого участника

Хотите узнать, сколько коммитов сделал каждый участник команды?

Эта команда выведет список, отсортированный в порядке убывания количества коммитов: git shortlog -s -n

Отобразить коммиты, содержащие удалённые файлы

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

git log --diff-filter=D --summary 

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

Отсортировать коммиты по автору

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

git log --author="Имя автора" 

Очистка всех скрытых состояний

Очистить все скрытые состояния можно следующей командой:

git stash clear 

Переименование локальной и удалённой ветки

Предложим, у вас есть ветка «fix-bug25», которую вы захотели переименовать в «hotfix-users». Прежде всего, нужно будет изменить локальную ветку:

git branch -m fix-bug25 hotfix-users 

А затем — удалённую ветку: переименовать её напрямую нельзя, поэтому нужно будет её удалить, и затем опубликовать заново уже с новым именем. Прежде чем приступать к этим процедурам, следует убедиться, что никто из членов команды не работает с этой веткой! Удаляем ветку: git push origin :fix-bug25

А теперь заново публикуем её с новым именем: git push origin hotfix-users

Переименование тега

Чтобы переименовать существующий тег:

git tag новое-название-тега старое-название-тега git tag -d старое-название-тега git push origin :refs/tags/старое-название-тега git push --tags 

Перестать отслеживать существующие файлы

Если вы хотите перестать отслеживать файлы, которые уже есть в репозитории, но при этом желаете сохранить его локально, осуществите коммит изменений и запустите команду:

git rm -r --cached 

Она удалит изменённые файлы из зоны подготовленных файлов (staging area). Затем нужно запустить команду:

git add . 

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

Подготовка удалённых файлов

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

git add -u 

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

git add -u . 

Поиск конкретного сообщения во всех коммитах

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

git log --grep

Пометить конфликтующий файл, как разрешённый

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

git add название-файла 

Затем можно запустить git commit, чтобы разрешить конфликты и опубликовать изменения.

Просмотр всех неотправленных коммитов

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

git log --branches --not --remotes 

Кроме того, можно использовать:

git log origin/master..HEAD 

Просмотр старой ревизии файла

Существует возможность просмотреть содержимое файла в конкретный момент времени в прошлом. Для этого нужно использовать команду:

git show commitHash:myfile.txt 

Публикация локальной ветки для удалённого редактирования

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

git push -u origin название-моей-новой-ветки 

Теперь они тоже смогут вносить изменения в эту ветку.

Сброс локальной ветки до состояния удалённой

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

Прежде всего нужно получить свежие обновления из удалённой ветки:

git fetch название-удалённой-ветки. 

А затем нужно сообщить git, что локальную ветку следует «откатить» до состояния удалённой:

git reset --hard origin/название-локальной-ветки. 

При наличии коммита, который нужно сохранить, перед сбросом нужно создать новую ветку и произвести коммит: git commit -m «Обновление»

git branch название-новой-ветки 

Синхронизировать ветку с master-репозиторием

Чтобы синхронизировать последние изменения в репозитории master (или с любой другой веткой, с которой вы работали) необходимо «перебазировать» локальную ветку. Предположим, вы работаете над веткой foobar:

git checkout foobar 

А затем осуществляете «перебазирование»:

git rebase master 

После этого будут применены коммиты origin из master. После разрешения конфликтов процесс можно продолжить с помощью команды git rebase —continue. Теперь можно продолжать работу над своей веткой или осуществить её слияние (merge) с главным репозиторием.

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

Это можно сделать прямо в процессе стандартного слияния (merge). Вам стоит сохранить историю слияний используя флаг —no-ff, что означает no fast forward.

Перейдите в ветку, в которую будут вливаться изменения, убедитесь в её актуальности и запустите процесс:

git merge --no-ff 

Затем появится сообщение о коммите merge X into Y branch, после чего вы можете смело запушить ваше слияние.>

Совмещение двух и более коммитов

Здесь нам понадобится произвести интерактивное перебазирование. Если перебазирование происходит относительно master-ветки, то начать следует с команды git rebase -i master. Однако, если перебазирование происходит не относительно ветки, то нужно будет перебазироваться относительно HEAD.

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

git rebase -i HEAD~2. 

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

Совмещение коммитов по конкретной функции для добавления в ветку релиза

Если вы решите совместить и опубликовать коммиты, то возникнет новый коммит в ветке релиза, поэтому история ветки конкретной функции останется неизменной.

Ниже представлен пример того, как достичь подобного эффекта:

git fetch origin git checkout [release-branch] git rebase origin/[release-branch] git merge —squash —no-commit [feature-branch] git commit -m 'Merge X into Y' 

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

Создание новой ветки с изменениями текущей

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

git checkout -b название-моей-новой-ветки 

Эта команда перенесёт файлы из текущей ветки в новую, которую потом уже можно «закоммитить».

Убрать файл из буфера

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

git reset HEAD unlovedfile.txt 

Удаление внешней ветки

Если вы хотите удалить ветку, введите команду:

git push origin --delete название-ветки 

Удаление неотслеживаемых файлов и папок

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

git clean -f 

Чтобы в принципе удалить их:

git clean -fd 

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

git clean -n 

Удаление старых веток, стёртых из внешнего репозитория

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

git-remote prune название-удалённой-ветки. 

Она удалит старую ветку под названием название-удалённой-ветки, которая уже была стёрта из внешнего репозитория, но всё ещё доступна локально в remotes/название-удалённой-ветки.

Удаление файла из git с сохранением его локальной копии

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

git rm --cached myfile.txt 

Больше статей о Git

• Полезные команды для работы с Git
• Как работать с GitHub в большой команде
• Как бесплатно залить сайт на хостинг GitHub Pages

«Доктайп» — журнал о фронтенде. Читайте, слушайте и учитесь с нами.

Читать дальше

5 частых ошибок при работе с Git

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

• 27 августа 2023

Работа с Git через консоль

Задача: форкнуть репозиторий в GitHub, создать ветку и работать с кодом.

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

Когда мы пишем код, мы постоянно туда что-то добавляем, удаляем, и иногда всё может ломаться. Поэтому перед любыми изменениями стоит сделать копию проекта. Если собирать проекты в папки с именами проект1 , проект1_финал и проект2_доделка , вы быстро запутаетесь и точно что-нибудь потеряете. Поэтому для работы с кодом используют системы контроля версий.

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

Git — самая популярная система контроля версий. С Git можно работать через командную строку (или терминал). В каждой системе своя встроенная программа для работы с командной строкой. В Windows это PowerShell или cmd, а в Linux или macOS — Terminal. Вместо встроенных программ можно использовать любую другую — например, Git Bash в Windows или iTerm2 для macOS.

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

Но давайте по порядку — установим Git на компьютер.

• 7 августа 2023

GitHub Desktop: обзор и первая настройка

Самая короткая инструкция о том, как сохранить файлы в GitHub и ничего не сломать. И самое главное — никакой консоли, всё через окошки и с помощью мышки. Для этого используем GitHub Desktop.

Внимание! GitHub Desktop не работает на Windows 7×32, поэтому если у вас эта версия системы, обновитесь до Windows 10 или воспользуйтесь программой GitKraken.

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

• 7 августа 2023

Как склеить коммиты и зачем это нужно

Когда вы открываете пулреквест и ваш код смотрят и комментируют другие, бывает нужно что-то исправить. Обычно такие изменения мы комментируем сообщением вроде «Увеличил шрифт на 2px » или «Поменял оттенок фона в шапке». Такие маленькие изменения интересны, только пока они в пулреквесте. Ревьювер (человек, который смотрит ваш код), может легко узнать, что и когда вы изменили, а не читать весь diff заново, а вы можете легко откатить коммит, если он не нужен. Но когда приходит время вливать пулреквест, эти маленькие коммиты теряют свою ценность. Поэтому лучше их склеить в один.

• 14 июня 2023

Основные команды для работы с Git

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

☝ В некоторых командах мы будем писать URL-адрес удалённого репозитория и название проекта в квадратных скобках, вот так — [ссылка на удалённый репозиторий] . Мы делаем это только для наглядности. Вам квадратные скобки ставить не нужно.

• 22 февраля 2023

Как бесплатно залить сайт на GitHub Pages

Допустим, вы сделали какой-то проект, например, собрали себе портфолио по шаблону, и теперь хотите выложить его в интернет. Если вы использовали только HTML и CSS, то необязательно платить деньги, чтобы загрузить сайт куда-то. Вы можете бесплатно выложить сайт на сервис GitHub Pages. Всё, что нужно — аккаунт на Гитхабе.

• 29 ноября 2022

Регистрация на GitHub

Создание нового аккаунта на GitHub состоит всего из 10 шагов — и вся регистрация занимает меньше пяти минут.

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

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

Ввод почты. На следующем шаге начинается регистрация. Подтвердите свою почту с прошлого шага и нажмите Continue (Продолжить).

Пароль. Придумайте сложный пароль, чтобы его никто не взломал. Например, Гитхаб просит, чтобы в пароле было не меньше 15 символов или 8 символов, но тогда должны быть и латинские буквы, и цифры.

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

Если имя недоступно, Гитхаб вам об этом скажет. А если доступно — жмите Continue.

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

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

Подтверждение почты. После капчи вам придёт письмо с кодом на почту. Введите его на следующей странице.

Вот здесь. Главное — не ошибайтесь.

Общая информация о вас и вашей команде. Если вы регистрируете аккаунт для себя, выбирайте Just me. Второй пункт — студент вы или учитель. Выбирайте «Студент», если вы не учитель.

Интересы. Дальше Гитхаб спросит вас об интересах — то есть о том, зачем вы регистрируете аккаунт. Из вариантов:

• Совместная разработка и код ревью.
• Автоматизация. CI/CD, API и другие админские вещи.
• Безопасность. Двухфакторная аутентификация, ревью, сканирование кода и списки зависимостей.
• Приложения. Выбирайте, если будете использовать GitHub Mobile, CLI, Desktop.
• Управление проектами. Проекты, метки, ишьи, вики и другие управленческие дела.
• Управление командами. Организации, приглашения, роли, домены.
• Сообщество. Выбирайте, если Гитхаб интересен вам как соцсеть.

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

Выбор тарифа. На выбор бесплатный тариф или платный GitHub Pro. Практика показывает, что для большинства личных проектов хватит бесплатного тарифа. В сентябре 2022 в него входили:

• Безлимитное количество репозиториев.
• 2000 минут CI/CD в месяц.
• 500 мегабайт места в хранилище пакетов.
• Поддержка сообщества.

Выбор тоже можно пропустить, тогда у вас будет бесплатный тариф.

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

• 28 сентября 2022

Работа с Git в Visual Studio Code

Если вы вёрстаете сайты или пишете код в редакторе Visual Studio Code, то Git за пять минут настраивается прямо внутри редактора. Не нужно запоминать команды для консоли, не нужно тыкать в лишние приложения.

Следуйте инструкции и всё получится.

• 16 сентября 2022

Markdown за 5 минут

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

Главный пример использования маркдауна, с которым мы часто сталкиваемся — файлы readme.md , которые есть в каждом репозитории на Гитхабе. md в имени файла это как раз сокращение от markdown.

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

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

• 5 октября 2021

Полезные команды для работы с Git

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

• 1 января 2020

Управление правилом защиты ветвей

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

Кто может использовать эту функцию.

People with admin permissions or a custom role with the «edit repository rules» permission to a repository can manage branch protection rules.

Protected branches are available in public repositories with GitHub Free and GitHub Free for organizations, and in public and private repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server. For more information, see «GitHub’s plans.»

About branch protection rules

You can create a branch protection rule in a repository for a specific branch, all branches, or any branch that matches a name pattern you specify with fnmatch syntax. For example, to protect any branches containing the word release , you can create a branch rule for *release* .

You can create a rule for all current and future branches in your repository with the wildcard syntax * . Because GitHub uses the File::FNM_PATHNAME flag for the File.fnmatch syntax, the * wildcard does not match directory separators ( / ). For example, qa/* will match all branches beginning with qa/ and containing a single slash, but will not match qa/foo/bar . You can include any number of slashes after qa with qa/**/* , which would match, for example, qa/foo/bar/foobar/hello-world . You can also extend the qa string with qa**/**/* to make the rule more inclusive.

For more information about syntax options, see the fnmatch documentation.

Note: Although GitHub supports File::FNM_PATHNAME in fnmatch syntax, File::FNM_EXTGLOB is not supported.

If a repository has multiple protected branch rules that affect the same branches, the rules that include a specific branch name have the highest priority. If there is more than one protected branch rule that references the same specific branch name, then the branch rule created first will have higher priority.

Protected branch rules that mention a special character, such as * , ? , or ] , are applied in the order they were created, so older rules with these characters have a higher priority.

To create an exception to an existing branch rule, you can create a new branch protection rule that is higher priority, such as a branch rule for a specific branch name.

For more information about each of the available branch protection settings, see «About protected branches.»

Note: Only a single branch protection rule can apply at a time, which means it can be difficult to know how which rule will apply when multiple versions of a rule target the same branch. For information about an alternative to branch protection rules, see «About rulesets.»

Creating a branch protection rule

When you create a branch rule, the branch you specify doesn’t have to exist yet in the repository.

Note: Actors may only be added to bypass lists when the repository belongs to an organization.

1. On GitHub.com, navigate to the main page of the repository.
2. Under your repository name, click

Settings. If you cannot see the «Settings» tab, select the

dropdown menu, then click Settings.

Note: If you select Dismiss stale pull request approvals when new commits are pushed and/or Require approval of the most recent reviewable push, manually creating the merge commit for a pull request and pushing it directly to a protected branch will fail, unless the contents of the merge exactly match the merge generated by GitHub for the pull request. In addition, with these settings, approving reviews will be dismissed as stale if the merge base introduces new changes after the review was submitted. The merge base is the commit that is the last common ancestor between the topic branch and the base branch. If the merge base changes, the pull request cannot be merged until someone approves the work again.

• Under «Protect matching branches», select Require a pull request before merging.
• Optionally, to require approvals before a pull request can be merged, select Require approvals. Select the Required number of approvals before merging dropdown menu, then click the number of approving reviews you would like to require on the branch.
• Optionally, to dismiss a pull request approval review when a code-modifying commit is pushed to the branch, select Dismiss stale pull request approvals when new commits are pushed.
• Optionally, to require review from a code owner when the pull request affects code that has a designated owner, select Require review from Code Owners. For more information, see «About code owners.»
• Optionally, to allow specific actors to push code to the branch without creating pull requests when they’re required, select Allow specified actors to bypass required pull requests. Then, search for and select the actors who should be allowed to skip creating a pull request.
• Optionally, if the repository is part of an organization, select Restrict who can dismiss pull request reviews. Then, in the search field, search for and select the actors who are allowed to dismiss pull request reviews. For more information, see «Dismissing a pull request review.»
• Optionally, to require someone other than the last person to push to a branch to approve a pull request prior to merging, select Require approval of the most recent reviewable push. For more information, see «About protected branches.»

• Select Require status checks to pass before merging.
• Optionally, to ensure that pull requests are tested with the latest code on the protected branch, select Require branches to be up to date before merging.
• In the search field, search for status checks, selecting the checks you want to require.

• Select Lock branch.
• Optionally, to allow fork syncing, select Allow fork syncing.

• Select Restrict who can push to matching branches.
• Optionally, to also restrict the creation of matching branches, select Restrict pushes that create matching branches.
• In the search field, search for and select the people, teams, or apps who will have permission to push to the protected branch or create a matching branch.

• Select Everyone to allow everyone with at least write permissions to the repository to force push to the branch, including those with admin permissions.
• Select Specify who can force push to allow only specific actors to force push to the branch. Then, search for and select those actors.

For more information about force pushes, see «About protected branches.»

Editing a branch protection rule

1. On GitHub.com, navigate to the main page of the repository.
2. Under your repository name, click

Settings. If you cannot see the «Settings» tab, select the

dropdown menu, then click Settings.

Deleting a branch protection rule

1. On GitHub.com, navigate to the main page of the repository.
2. Under your repository name, click

Settings. If you cannot see the «Settings» tab, select the

dropdown menu, then click Settings.

¶ Git и GitLab

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

GitLab — веб-приложение и система управления репозиториями программного кода для Git. Обычно GitLab используется вместе с Git и даёт разработчикам возможность сохранять их код онлайн, а затем взаимодействовать с другими разработчиками в разных проектах.

¶ Установка Git

Перед началом работы с GitLab установите себе на устройство приложение Git по ссылке.

Найти подробную инструкцию по установке Git можно здесь.

¶ Авторизация в GitLab

Авторизуйтесь в сервисе GitLab через корпоративную почту @miem.hse.ru.

Затем выберите в верхней панели раздел «Groups». Щелкните на «Your Groups». На этой странице должна находиться группа с номером и названием вашего проекта. Нажмите на нее, чтобы открыть.

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

¶ Установка пароля

После авторизации нужно установить пароль для вашего аккаунта в GitLab.

1. Нажмите на вашу иконку в правом верхнем углу и перейдите в раздел «Настройки» (settings).
2. Затем перейдите во вкладку «Пароль» (password).

1. Укажите ваш новый пароль и сохраните его.

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

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

Репозиторий (хранилище) — место, где хранятся и поддерживаются данные. Чаще всего данные в репозитории хранятся в виде файлов.

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

Узнать более подробную информацию можно перейдя по ссылке: что такое репозиторий?

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

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

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

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

Если вы не видите в разделе «Your group» команду вашего проекта, то обратитесь в Техподдержку.

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

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

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

Рекомендуем установить галочку напротив «Инициализировать репозиторий файлом README» — в репозитории появится документ «README. md», в котором можно описывать файлы, содержащиеся в этом репозитории.
Если вы хотите залить сюда файлы из уже существующего репозитория, то можеть не создавать новый «README. md».

Шаг 6.

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

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

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

Переместить проект может человек только с ролью «Maintainer»(подробнее в разделе участники и роли)

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

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

Нужно обязательно выбрать «Repo by URL«, в остальных случаях импорт не всегда проходит успешно

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

¶ Локальная работа с репозиторием

Откройте нужный репозиторий и нажмите на кнопку «Clone». Скопируйте ссылку.

¶ Переход в консоль

Далее вам нужно перейти в консоль.

Как это сделать?

1. Нажмите на значок поиска на Панели задач или кнопку Пуск.
2. Далее нажимите «Выполнить».

1. В строке поиска напечатайте «cmd».

1. В результате вы увидите окно консоли.

Не на всех видах Windows консоль открывается так, как указано выше. НО на всех можно нажать Win+R и ввести cmd .

1. В строке поиска Spotlight введите слово «Терминал» и нажмите Enter .
2. В результате вы увидите окно терминала.

• Linux
  Для открытия консоли (терминала) нажмите сочитание следующих клавиш: Alt+Ctrl+F1 .

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

Для получения копии существующего Git-репозитория необходимо ввести в терминале команду git clone .

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

Клонирование репозитория осуществляется командой:
git clone

После вы должны ввести имя пользователя и пароль от своей учетной записи в GitLab.

Обратите внимание, что имя пользователя — это имя вашей корпоративной почты до символа «@», а пароль — это пароль, который мы ранее установили в GitLab.
Если у вас возникают ошибки авторизации, обязательно проверьте, какой у вас логин: нажмите на крайнюю кнопку справа сверху на главной странице GitLab и посмотрите, что указано под вашей фамилией.

Вы можете в любой момент перейти к папке с вашим репозиторием с помощью команды:
cd путь/к/директории

Следующая команда показывает, что файл «README.md» скачался и лежит в нашей папке:
dir (ls в Unix)

клонирование репозитория прошло успешно

¶ Заполнение данных

Первое, что вам следует сделать после установки Git — указать ваше имя и адрес электронной почты. Каждый коммит в Git, сделанный вами, будет содержать эти данные. Это информация о разработчике, который вносит изменения.
Используем следующие команды:
git config —global user.name «Иван Иванов»
git config —global user.email ivivanov@miem.hse.ru

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

Если вы хотите проверить используемую конфигурацию, можете использовать команду git config —list , чтобы показать все настройки, которые Git найдёт:

¶ Добавление файлов в репозиторий

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

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

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

¶ Встроенный редактор GitLab

GitLab предоставляет простой способ внести небольшие изменения в файлы проекта. Это среда разработки, встроенная в сайт GitLab. Чтобы её запустить, найдите файл, который нужно отредактировать и щелкните по его названию. На открывшейся странице вы увидите содержимое файла и две кнопки: Edit и Web IDE . Первая кнопка откроет файл для простого редактирования, вторая запустит встроенную среду разработки.

Также на сайте предусмотрена возможность создавать новые файлы. Для этого на странице репозитория нажмите на кнопку «+» и выберите «New file» . В открывшемся редакторе введите имя файла и нужное содержимое. Не забудьте нажать на кнопку Commit changes по завершении редактирования.

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

¶ Изменения в существующем файле

Чтобы внести изменения в файл, который скопировался вместе с репозиторием, просто перейдите в папку с копией репозитория на компьютере и откройте этот файл. В нашем случае, это файл «README.md». Он должен содержать описание репозитория, отображаемое на его странице на сайте. Добавьте в него новую строку и сохраните:

Если вы выполните команду git status , то увидите свои неотслеживаемые изменения в файле:

Мы видим, что у нас есть недобавленные изменения.

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

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

Коммит — это сохранение, фиксация (в архиве, репозитарии и т.д.) изменений в программном коде.

Команда git commit берёт все данные, добавленные в индекс с помощью git add , и сохраняет их слепок во внутренней базе данных, а затем сдвигает указатель текущей ветки на этот слепок.

При коммите данных их необходимо комментировать, чтобы в дальнейшем каждое изменение в проекте было с описанием действий. Для этого используется команда
git commit -m «комментарий»

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

¶ Добавление нового файла в удаленный репозиторий

Для того чтобы залить изменения в удаленный репозиторий, который находится на git.miem.hse.ru, нужно использовать команду git push .

Рассмотрим пример:
Создадим новый файл «text.txt» в папке «main» и выполним следующие действия:

Шаг 1. Добавим файл в нашу папку main;

Шаг 2. Зафиксируем изменения и узнаем текущее состояние файла;

Шаг 3. Отправим изменения в локальное хранилище (то есть выполним коммит).

С помощью команды git push отправим данные локального репозитория на удаленный репозиторий (Origin — это наш репозиторий).

Заходим в GitLab и видим, что отправка данных прошла успешно.

¶ Отмена действий

Если вы добавили файлы в состояние ожидания, но передумали и не хотите добавлять некоторые из них, то нужно использовать команду:
git rm —cached «название файла»

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

¶ Проблемы при входе

• Если вы ввели неправильно пароль (на Windows), а во второй раз ваши данные не запрашиваются, то вам нужно сделать следующие действия:
  панель управления -> учетные записи -> диспетчер учетных данных -> удалить данные GitLab
  После чего заново повторить первые шаги с вводом ваших данных.
• Чтобы на устройствах Linux/Mac каждый раз не запрашивался пароль, нужно использовать следующую команду:
  git config credential.helper store

¶ Полезные ссылки:

1. Основные понятия: Ветки
2. Основные понятия: Зеркалирование репозитория
3. Управление командой: Различия прав доступа
4. Навигация: Уровень видимости проекта