Это способ избежать разветвления ветвления, когда git тянуть?

Question

Я и мой друг подтвердили, затем я отправил свои изменения, он тоже попробовал pu sh, но GitLab отказался, и это хорошо,

но затем он вытащил изменения, и на графике появилось «ответвление» и «ответвление». Это способ избежать этого явления и заставить его отменить свои изменения?

dev-3 защищен в GitLab.

Answer 1

Ранее в мае 2015 года я задокументировал: « Может ли« git тянуть »автоматически ставить sh и выдавать ожидающие изменения? », как локально настроить Git для git pull to rebase:

git config --global pull.rebase true
git config --global rebase.autoStash true

Это означает, что это локальная конфигурация на стороне клиента, а не настройки GitLab на стороне сервера.

Это будет воспроизведение (с простым git pull ) их собственный #123 коммит поверх origin/dev3.

Answer 2

Там есть пара разных вопросов ...

Если вы хотите, чтобы ваша долгосрочная история выглядела "линейной" (т.е. без ветвей / слияний), то, как вы заметили, вы бы использовали rebase. В этом случае, если вы тянете для того, чтобы иметь возможность набрать sh, вам нужно перебросить пул, а не объединять изменения. Вы можете сделать это с git pull -r. (Также возможно настроить локальное репо для этого по умолчанию, но, пожалуйста, обратитесь к документации git config, если вы хотите это учитывать; это считается потенциально рискованной конфигурацией.)

Вы также спросили если вы можете «заставить» других разработчиков отменить свои изменения. Как правило, я бы переосмыслил «форсирование» того или иного поведения, но в любом случае, если команда хочет применять только ребазинг, это можно сделать в удаленном репо. В общем случае с git вы будете использовать ловушку предварительного получения, которая будет отклонять толчки, которые не «следуют правилам». Для размещенных репозиториев (github, gitlab и др. c.) У вас может не быть прямого доступа к перехватчикам на стороне сервера, поэтому вам придется обращаться к документации этих сервисов.

(обратите внимание, что «когда разработчик пытается сделать sh "довольно позднее время, чтобы уловить проблему, поскольку разработчик мог случайно нарушить правило и основать кучу работы на этой ошибке. Чтобы смягчить это, локальное репо может быть настроено с помощью ловушка pre-commit, которая применяет то же правило во время коммита. Но конфигурация ловушки на стороне клиента не может быть «принудительной», поэтому вы начинаете с ловушки на стороне сервера.)

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