LINUX.ORG.RU

git(hub): вопрос по управлению коммитами в рамках большого проекта.


0

1

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

- форкнул себе репозиторий
- склонировал на рабочую машину
- внес изменения
- сделал коммит
- запушил на гитхаб
- сделал pull request, его приняли

Но за время между клонированием репозитория и принятием пулл реквеста в апстриме сделали уже много других коммитов. Я сделал так:

- git remote add upstream <???.git>
- git fetch upstream
- git merge
- git push

Теперь на гитхабе в моем форке имеется актуальная копия апстрима, но когда я ради интереса снова нажал pull request, то обнаружил, что мой мерж считается коммитом и по идее я в следующий раз отправлю его в рамках реквеста.

Вопросы:

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

Я знаю, что я недостаточно вкурил гит и распределенные системы контроля версий :)

★★★

git pull --rebase может помочь.

slapin ★★★★★
()

В принципе в merge нет ничего плохого, но если не нравится, можно сделать rebase, примеров даже на русском полно

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

Дык я не против мержа. Я просто не хочу, чтобы в следующий мой pull request к владельцам проекта включился этот дурацкий коммит (в котором даже 0 файлов изменено), который сформировался на гитхабе (!) по факту мержа. Как мне сделать rebase на гитхабе в веб-интерфейсе? Или я чего-то вообще не догоняю?

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

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

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

Чтоб перетащить цепочку коммитов, делаешь так:
git rebase --onto КУДА ОТКУДА ДО_КУДА

где куда, откуда и до_куда - хэш коммита или название ветки/тега

xorik ★★★★★
()

git fetch upstream
git checkout master (локальный бранч, который чиним)
git reset --hard upstream/master (нужный бранч в апстриме)
git push --force (принудительно толкаем правильную историю на гитхаб)

Есть более красивый способ? :#

ratvier ★★
()

После того, как твою веточку вмержили в апстрим, просто убей её. Захочешь ещё что-то накодить — сделаешь новый форк (то бишь новую ветку).

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

Такое сработало, спасибо! Только что же, так нужно делать каждый раз, как я локально у себя что-нибудь пофиксю?

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

Если самому не трогать master (кроме merge upstream/master), то таких проблем не будет.

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

Ну так смотри в чём был вопрос: локальные изменения уже приняли в апстим, но «что-то пошло не так» в истории

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

А, да, тогда все правильно, приношу извинения.

slapin ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.