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 ()
Ответ на: комментарий от ratvier

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

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