Comments 25
Зачем усложнять-то? Лично я против merge-commit-ов в мастере, так что делаю примерно так:
$ git remote add alice git://bitbucket.org/alice/bleak.git
$ git checkout master
$ git fetch alice
$ git merge --ff-only alice/master < — если упадет из-за конфликта или старого пулл реквеста, то просим Алису переделать пулл реквест
$ git diff origin/master < — смотрим вносимые изменения
$ git rebase -i origin/master < — опционально, если хотим поменять коммиты Алисы, собрать их в один коммит например
$ git push origin master < — готово
$ git remote add alice git://bitbucket.org/alice/bleak.git
$ git checkout master
$ git fetch alice
$ git merge --ff-only alice/master < — если упадет из-за конфликта или старого пулл реквеста, то просим Алису переделать пулл реквест
$ git diff origin/master < — смотрим вносимые изменения
$ git rebase -i origin/master < — опционально, если хотим поменять коммиты Алисы, собрать их в один коммит например
$ git push origin master < — готово
Зачем так усложнять?
> git merge feature-branch
и готово.
А то желание не иметь мердж коммиты в мастере стоит вам потерей связей между правками и их авторами после ваших ребейзов.
> git merge feature-branch
и готово.
А то желание не иметь мердж коммиты в мастере стоит вам потерей связей между правками и их авторами после ваших ребейзов.
Сам по себе rebase не меняет автора коммита, так что если у ревьювера есть право пушить коммиты с чужим именем, то все ок.
Мердж коммиты плохи по двум причинам — сильно загромождают историю правок, т.к. по хистори не всегда можно понять, где был мастер, а где добавленное изменение. И второе — при разработке отдельной фичи считается хорошим тоном коммитить часто, но в хистори мастера лучше иметь фичу целиком в виде одного коммита. Автор пулл реквеста конечно может сквошить сам, но это неудобно, т.к. пулл реквест еще может дорабатываться после создания.
Хотя дело вкуса конечно. Можно потратить какие-то усилия и иметь чистую историю, а можно и не тратить и не иметь — это не критично для разработки в конце концов.
Мердж коммиты плохи по двум причинам — сильно загромождают историю правок, т.к. по хистори не всегда можно понять, где был мастер, а где добавленное изменение. И второе — при разработке отдельной фичи считается хорошим тоном коммитить часто, но в хистори мастера лучше иметь фичу целиком в виде одного коммита. Автор пулл реквеста конечно может сквошить сам, но это неудобно, т.к. пулл реквест еще может дорабатываться после создания.
Хотя дело вкуса конечно. Можно потратить какие-то усилия и иметь чистую историю, а можно и не тратить и не иметь — это не критично для разработки в конце концов.
Но при таком условии кто-то ведь всё равно сквошить должен: или создатель коммита, или тот, кто в Вашем сценарии мёржит в master, правильно? Так что это одинаково удобно (или неудобно), на мой взгляд.
Кроме того, сквошить можно в любой момент, даже после ревью, прямо перед слиянием пулл реквеста, — он это спокойно переваривает.
Что касается чистой истории, это вопрос, как Вы отметили, спорный. К тому же, git умеет фильтровать из неё merge коммиты.
Кроме того, сквошить можно в любой момент, даже после ревью, прямо перед слиянием пулл реквеста, — он это спокойно переваривает.
Что касается чистой истории, это вопрос, как Вы отметили, спорный. К тому же, git умеет фильтровать из неё merge коммиты.
А ещё можно мержить без фаст форворда. Тогда в ветке останутся все маленькие авторские коммиты, а в мастер они вольются одним коммитом, без необходимости сквоша.
Именно так и поступает алгоритм pull request-а, описанный в статье. Если интересно, я могу привести точную последовательность git операций, которую выполняет Bitbucket Server для показа диффа pull request-а и для его слива в целевую ветку.
В этой ветке речь зашла о том, какие коммиты хочется видеть в истории: кто-то предпочитает избегать merge-коммитов, кто-то любит историю с одним коммитом на фичу, кому-то больше по душе маленькие авторские коммиты.
Однако задача pull request-а состоит не в том, чтобы организовать коммиты, а в том, чтобы аккуратно и достоверно отобразить, к какому состоянию целевой ветки приведёт сливание его содержимого в неё, и именно её аспекты рассматриваются в этой статье.
В этой ветке речь зашла о том, какие коммиты хочется видеть в истории: кто-то предпочитает избегать merge-коммитов, кто-то любит историю с одним коммитом на фичу, кому-то больше по душе маленькие авторские коммиты.
Однако задача pull request-а состоит не в том, чтобы организовать коммиты, а в том, чтобы аккуратно и достоверно отобразить, к какому состоянию целевой ветки приведёт сливание его содержимого в неё, и именно её аспекты рассматриваются в этой статье.
я не против merge-commit-ов в мастере, но тем не менее согласен с тем, что усложнено через чур
git:(master) $ git pull
git:(master) $ git checkout feature/alice
git:(feature/alice) $ git rebase -i master < — догоняем мастер
git:(feature/alice) $ git push -f
git:(master) $ git pull
git:(master) $ git checkout feature/alice
git:(feature/alice) $ git rebase -i master < — догоняем мастер
git:(feature/alice) $ git push -f
> git push -f
а в это время где-то в далёкой-далёкой галактике
vasya $ git pull
vasya $ fuck
а в это время где-то в далёкой-далёкой галактике
vasya $ git pull
vasya $ fuck
Делаю то же самое только чуть более идиоматично
# Делаем ребейс при пулле по умолчанию. Выполняем лишь один раз
git config pull.rebase true
# Создаем рабочий бранч и указываем upstream
git checkout -b my_feature_branch --track origin/master
# Тянем изменения и автоматически делаем ребейс
git:(my_feature_branch) git pull
# Делаем ребейс при пулле по умолчанию. Выполняем лишь один раз
git config pull.rebase true
# Создаем рабочий бранч и указываем upstream
git checkout -b my_feature_branch --track origin/master
# Тянем изменения и автоматически делаем ребейс
git:(my_feature_branch) git pull
Не могу согласиться с тем, что описанный Вами способ проще. Он, на самом деле, очень похож на описанный в статье процесс, за исключением того, что вместо merge-коммита Вы предлагаете разрешать только fast forward. В таком варианте невозможно отобразить, какие именно конфликты произошли, поскольку если они есть, merge вообще не происходит.
Необходимость же повторения этого процесса в случае, если master тем временем изменился, никуда не девается. Это то, что в статье называется пересмотром пулл реквеста (rescope).
Если же Вы имели в виду исключительно ручной процесс, то он не позволяет иметь более одного ревьюера (собственно, выполняющего эти команды), что является сильно урезанным пулл реквестом. Ну, и на более-менее живом проекте придётся делать много рутинных операций, чтобы догонять постоянно убегающий master.
Необходимость же повторения этого процесса в случае, если master тем временем изменился, никуда не девается. Это то, что в статье называется пересмотром пулл реквеста (rescope).
Если же Вы имели в виду исключительно ручной процесс, то он не позволяет иметь более одного ревьюера (собственно, выполняющего эти команды), что является сильно урезанным пулл реквестом. Ну, и на более-менее живом проекте придётся делать много рутинных операций, чтобы догонять постоянно убегающий master.
Есть существенный минус при таком подходе. Код Алисы разрабатывался и тестировался на какой-то конкретой ревизии. Если заставить ее отребейзить код на текущий мастер, исчезает уверенность в том, что ее изменения работают. Эти изменения в мастере могли что-то изменить, что пагубно скажется на работоспобности кода.
Давайте тогда вообще ничего не ребейсить и не мержить, пусть те, кому нужна фича а, юзают ветку алисы, а кому фича б — ветку боба. А те неудачники, кому зачем-то нужно несколько фич, пусть ставят несколько копий приложения из разных веток. А для надёжности, чтоб они уж точно никак друг другу не помешали, сделаем в формате обрабатываемых данных для каждой ветки маленькие, но совершенно несовместимые друг с другом различия.
По названию статьи почему-то ожидал какой то коммит, который был максимально публично заплюсован/зазвезден/закомментин положительно или еще что в таком духе. Не выспался видать =)
Тот самый из бамблби?
Странно, а по моему, первым делом на ум должно приходить решение этого вопроса. Я уж думал, забодали их в конец и сделали-таки
del
Склонение английских word-ов по правилам русской грамматики — интересный трюк :)
Полагаю, в разговорной речи большинство так и говорит: «коммитить», «пушить», «пуллить» и т.д. Это, безусловно, неправильно, но и переходить на «зафиксировать», «протолкнуть», «затянуть» совсем не хочется. В общем, какой-то компромисс…
del
Вот смотрите, есть русское слово «фиксировать», оно есть в словаре, но как перевод «commit» в этом контексте — не очень привычно. Есть такое, тоже русское, слово «коммит», его нет в словаре, но все его знают и спокойно употребляют в разговорной речи. А есть английское слово «commit». Оно тоже хорошее, и его вполне можно употребить в статье на русском языке. Какой из этих трёх вариантов выбрать — дело автора. Меня просто смутила попытка впихнуть английские слова в русскую грамматику.
Странно что никто не дал ссылку https://github.com/theonion/fartscroll.js/pull/9 как пример… Лучшего пулл риквеста
Sign up to leave a comment.
Лучший Pull Request