LINUX.ORG.RU

Вопрос по пул-реквестам

 , pull-request, запрос на слиятние, ,


0

1

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

Это значит что для отдельных пул-реквестов нужно делать отдельные бранчи/ветки, ну типа «transtale A to B», «translate C to B» и делать пул-реквесты от них? Дожил, никогда подряд пулл-реквесты не присылал, а если и присылал то после того как предыдущий примут, поэтому с таким не сталкивался =)

Только так можно разделять коммиты по отдельным пул-реквестам? Типа «ФичаА», «ФичаБ».

Не бейте сильна :)

Ответ: Да

★★★★★

Последнее исправление: LINUX-ORG-RU (всего исправлений: 1)

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

Опять же, проще будет поправить, если попросят.

kardapoltsev ★★★★★
()
Ответ на: комментарий от kardapoltsev

Спасибо.
Просто подумалось что можно как то указать пару коммитов и автоматически разделить на ветки или ещё чёнить или у гитхаба неявно как-то можно на ходу разделить коммиты по пул-реквестам.

LINUX-ORG-RU ★★★★★
() автор топика
Ответ на: комментарий от LINUX-ORG-RU

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

shell-script ★★★★★
()
Ответ на: комментарий от shell-script

Там переводы расширений cinnamon. У них там каталог с десятком расширений. Переводы разных расширений поэтому вот задумалось разделять. Ой ладно бы ещё это, одни (в прочтименя) просят контрибутить в этот сборник, другие просят контрибутить в свою оригинальную репу, а потом этот сборник будет автоматически забирать изменения себе (надеюсь ибо там некоторые пулл реквесты с прошлых годов висят). А у других вапще реп нету :D и 404 страница они ничего не просят и их репа сохранилась лишь в коллекции у минт циннамона. Сложна, ну да ладно, надеюсь не запутаюсь :) Буду как могу тихонько локализовать. Погляжу, если за месяц циннамон себе из внешних реп изменения не притянет, буду делать запросы и туда и туда. Но не хочется такого, морока и лишние телодвижения :3

А так побоялся что наругают, а там сказали ваще пофигу, спосибо что принёс, ну и нормально :D

LINUX-ORG-RU ★★★★★
() автор топика

Если ты делаешь перевод на один язык, то смысла делать ветки особо нет, обычно достаточно разделить на обидельные коммиты.

Но в случае расширений действительно лучше разделить на разные pull request - это не будет тормозить процесс принятия одного из переводов.

grem ★★★★★
()
Последнее исправление: grem (всего исправлений: 2)
Ответ на: комментарий от max_lapshin

Не я делаю штук по 10 сразу бранчей сейчас, в каждом своё доделываю, затем 10 раз git push origin branch_A; git push origin branch_B и так далее, а потом в вебгуйне уже 10 раз кнопки жму отправки сразу кучи пулл-реквестов от каждого бранча по одному. Если всё норм то удаляю их и за другое берусь. Так, норм. Главное чтобы пока я там своё делаю мастер не поменялся, я понятия не имею как разрешать всякое пересекающееся. Для меня гит был всегда просто как история правок, а вот эта бюрократия как-то всегда мимо обходила :3

А ветки от ветки… Не, у меня крыша поедет, тут ты прав, запутаюсь и всё сломаю. Проще забить.

LINUX-ORG-RU ★★★★★
() автор топика
Последнее исправление: LINUX-ORG-RU (всего исправлений: 2)
Ответ на: комментарий от dataman

Скажем так, не гитхабом единым =) Для меня он ничем от сорсфоржа например не отличается, просто часть проектов в которые я тыкаюсь расположились на гитхабе, вот и всё. Но так-то да, удобно, не спорю.

LINUX-ORG-RU ★★★★★
() автор топика
Последнее исправление: LINUX-ORG-RU (всего исправлений: 1)
Ответ на: комментарий от shell-script

А сколько раз ты туда закоммитишь в процессе её решения - не так важно.

Более того, зачастую потом все равно все коммиты сквошатся в один. Ну или вручную соединяются в логические группы. Так что можно в рамках ПРа лепить хоть 20 коммитов вида +++ или Updates.

Zhbert ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

Не я делаю штук по 10 сразу бранчей сейчас, в каждом своё доделываю, затем 10 раз git push origin branch_A; git push origin branch_B и так далее, а потом в вебгуйне уже 10 раз кнопки жму отправки сразу кучи пулл-реквестов от каждого бранча по одному. Если всё норм то удаляю их и за другое берусь. Так, норм.

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

Syncro ★★★★★
()
Последнее исправление: Syncro (всего исправлений: 1)
Ответ на: комментарий от Syncro

Ну это лучше, да. Хотя часто при мерже выбирается все равно «Сквош и мерж». Я все равно коммиты стараюсь в итоге привести в более менее адекватному виду перед ревью.

Zhbert ★★★★★
()
Ответ на: комментарий от Syncro

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

Zhbert ★★★★★
()
Последнее исправление: Zhbert (всего исправлений: 1)
Ответ на: комментарий от Zhbert

Хотя часто при мерже выбирается все равно «Сквош и мерж».

Да более того, за что-то отличное от «Сквош и мерж» в иных командах могут и побить. Пулл-реквест по сути своей предполагает некоторое ревью, исправление косяков, прохождение авторестов и так далее - в процессе работы будут коммиты, и никому они нахрен не нужны после мерджа. Это бесит всех, когда в блейме видишь тупые фикс-апы и коммиты вида «Fix typo», никому это не надо видеть в истории изменений

FishHook
()