LINUX.ORG.RU

Git: помогите освоить rebase

 ,


0

1

Сначала схема (стеклянного шара) к теме:

A=https://github.com/void-linux/void-packages
# master-------------------------------------------------|------>
#                                                        |
B=https://github.com/onlylunix/void-packages (FORK)      |
# master        25277 commits behind                     |>
# firebird3upd  1 commit ahead of, 25277 commits behind  |->

C=localhost
$ git config --get remote.origin.url
git@github.com:onlylunix/void-packages.git
Давным-давно из ветки firebird3upd создал Pull request #46672 И вот сейчас эта ветка конфликтует https://ibb.co/FLS3TdM3

Знаю в каком файле конфликт, но не понимаю как действовать дальше ЧТОБЫ НЕ ЗАКРЫЛСЯ Pull request #46672
Спрашиваю потому, что, на github.com уже ругали, и теперь боюсь те кнопки нажимать в их web-интерфейсе (далее WEB), т.к. всё ломается и PR-ы приходится закрывать и создавать новые.

С опаской предполагаю варианты действий:

Вариант 1:
В WEB кнопкой [Sync fork] обновляю ветку B:firebird3upd до A:master. При этом будет конфликт. В WEB редактирую конфликтный файл (Есть такой функционал?).
На localhost выполняю: git pull, что загрузит изменения Sync-нутые и сделанные в WEB при решении конфликта.

Вариант 2:
В WEB кнопкой [Sync fork] обновляю ветку B:firebird3upd до A:master. При этом будет конфликт. Ничего не редактирую.
На localhost выполняю:
git checkout firebird3upd
git fetch
nano 'конфликтный файл' # редактирую 'конфликтный файл'
git add 'конфликтный файл'
git commit --amend --no-edit
git push --force
Вариант 3:
Все действия на localhost-е:
git checkout firebird3upd
git pull --rebase upstream master
nano 'конфликтный файл' # редактирую 'конфликтный файл'
git add 'конфликтный файл'
git commit
git push --force
Повторю что ВАЖНО ЧТОБЫ НЕ ЗАКРЫЛСЯ PR #46672
Прошу помощи!

Не удачная попытка: Git: помогите освоить rebase (комментарий) ...

★★★★★

Последнее исправление: superuser (всего исправлений: 16)
Ответ на: комментарий от Chiffchaff

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

выбор-то никто не отбирает тут: кто собственную работу построить правильно не может, у того ПР будут приниматься с ff, squash и прочим трешаком, и, естественно будут откатываться целиком, также будет теряться простая возможность куда-то их пинкуть и пр., здесь нет же никаких ожиданий, что мейнтейнер будет бегать за каждым контрибьютором и упрашивать - если по коду норм, а в СКВ бардак, то будет сливаться в один коммит (на gh правда кучу раз сталкивался с тем, что кто-то просит или на голову rebase сделать или коммиты склеить - зачем я так и не понял). Обычно можно за 1-2 ПР понять что дальше делать с конкретным индивидуумом.

И будут херачить коммиты вида «fixes», «work» до посинения. Можно повесить всюду фашистские хуки и запреты, но это - другая крайность, которая мне тоже не нравится.

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

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

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

Так и я так же делаю. Перед тем, как отдать кому-то на ревью, иду, и при помощи rebase привожу в более-менее приличный вид.

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

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

Chiffchaff
()
Ответ на: комментарий от borisych

конечно запретить, только вы же при этом топите за то, что в ПР merge делать, а не rebase, а мержем коммиты не схопываются какая альтернатива-то? reset и push --force

Мое понимание гита, что merge это и есть основной сценарий использования. А все эти --force на крайний случай, починить, например что-то (закоммитили случайно пароль).

если там все ровно изначально, то конфликтов не будет, ну а если не особо-то и ровно, то какие вопросы к апстриму?

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

urxvt ★★★★★
()