случайно вмерджил изменения по чужому ПР в свой.
заметил очень не сразу. как избавиться от мусора в моем ПР с наименьшей кровью? сейчас в голову приходит только порезать лишние изменения вручную из предыдущему моему коммиту состоянию, закоммитить, потом в том ПР, который вмерджил также вручную восстановить и привязать соответственно к нему. может можно проще?
Здравствуйте, nikkit, Вы писали:
N>случайно вмерджил изменения по чужому ПР в свой. N>заметил очень не сразу. как избавиться от мусора в моем ПР с наименьшей кровью? сейчас в голову приходит только порезать лишние изменения вручную из предыдущему моему коммиту состоянию, закоммитить, потом в том ПР, который вмерджил также вручную восстановить и привязать соответственно к нему. может можно проще?
Очевидно, что это вопрос не по Git — в нём вообще нет понятия PR (pull request) — а конкретному серверному средству (GitHub? Gitlab? Bitbucket? что-то иное?)
N>Очевидно, что это вопрос не по Git — в нём вообще нет понятия PR (pull request) — а конкретному серверному средству (GitHub? Gitlab? Bitbucket? что-то иное?)
N>Уточни.
Bitbucket
N>Или это ещё в локальной копии?
нет. в ориджине. и куча всего сверху положена. не сразу спохватился.
Здравствуйте, nikkit, Вы писали:
N>нет. в ориджине. и куча всего сверху положена. не сразу спохватился.
Ветка твоя или что-то типа master, main, release? Если твоя, то можно историю переписать.
S>>Тогда ничего. Общая история — неизменяема, это аксиома.
vsb>Почему это? Берёшь и меняешь, потом остальным говоришь, чтобы скачали репозиторий заново.
Технически да, но представь, что на эту историю уже насобиралось билдов, тестировщики по-написали/по-закрывали bug`ов, workitem`ы ассоциировались.
А тут раз — и нет этих коммитов
Обычно такие ситуации разрешает владелец ветки согласно некоторому регламенту, а у ТС и прав-то скорее всего нет на перезапись истории.
Здравствуйте, Skorodum, Вы писали:
S>Здравствуйте, nikkit, Вы писали:
N>>ну типа релиза — для фиксов. общая в общем. S>Тогда ничего. Общая история — неизменяема, это аксиома.
Не совсем. В мане git rebase есть даже глава "Recovering from upstream rebase", которая пригодна ко всем таким случаям.
Но это существенные неудобства в момент обновления, которые надо решать врукопашную, поэтому предпочитают так не делать.
Здравствуйте, vsb, Вы писали:
vsb>Не знаю, что такое ПР, а так — создай ветку от последнего нормального коммита и чирипикай остальные коммиты.
Это "Pull Request", но — как уже писали выше — это не связано непосредственно с Git.
Здесь надо обращаться к администратору сервиса Вашего репозитория.
Здравствуйте, vsb, Вы писали:
vsb>Почему это? Берёшь и меняешь, потом остальным говоришь, чтобы скачали репозиторий заново.
Если есть такая опция, то всего лишь локальную ветку удалить надо.
Здравствуйте, netch80, Вы писали:
N>Но это существенные неудобства в момент обновления, которые надо решать врукопашную, поэтому предпочитают так не делать.
Из личного опыта: ~10% разработчиков знают и понимает git rebase.
Здравствуйте, Skorodum, Вы писали:
N>>Но это существенные неудобства в момент обновления, которые надо решать врукопашную, поэтому предпочитают так не делать. S>Из личного опыта: ~10% разработчиков знают и понимает git rebase.
OK. Только в чём причина — остальных просто не учат, или они не в состоянии это понять?
Это принципиальный вопрос.
А то, например, многие сервера без rebase не пускают мержить при конфликтах.
Здравствуйте, netch80, Вы писали:
N>OK. Только в чём причина — остальных просто не учат, или они не в состоянии это понять? N>Это принципиальный вопрос.
Точно не знаю, но есть еще один вариант: не считают нужным учить, и мне кажется, что это наиболее часто встречаемый вариант.
N>А то, например, многие сервера без rebase не пускают мержить при конфликтах.
Они конфликтов бояться как огня и зовут коллег помочь если случаются конфликты.
Немного КСВ-шного оффтопа: в программированиие есть несколько таких моментов, которые люди либо понимают, либо совем не понимают и используют совсем неправильно.
Вот с непониманием чего приходилось сталкиваться:
1. Переменные, массивы, циклы и функции.
2. Классы.
3. Шаблоны.
4. Функциональное программирование.
5. Граф зависимостей и сборка проекта (CMake, qbs or whatever).
6. Контроль версий, особенно распределенные системы типа гита.
Здравствуйте, nikkit, Вы писали:
N>сейчас в голову приходит только порезать лишние изменения вручную из предыдущему моему коммиту состоянию, закоммитить,
Когда вы с коллегой будете сливать оба своих коммита в мастер-ветку, с т.з гита твои манипуляции будет выглядеть так: коллега добавил изменения, а ты их убрал.
Воспользуйся советом vsb
Здравствуйте, netch80, Вы писали:
N>OK. Только в чём причина — остальных просто не учат, или они не в состоянии это понять? N>Это принципиальный вопрос. N>А то, например, многие сервера без rebase не пускают мержить при конфликтах.
Какой-то там ребейз: тут вообще мрак
Здравствуйте, vsb, Вы писали:
vsb>Почему это? Берёшь и меняешь, потом остальным говоришь, чтобы скачали репозиторий заново.
А так же все ветки которые уже успели создаться от старой ветки, если работаешь 1 над веткой еще хоть как то можно это оправдать, но если эта ветка влита в релиз, нее, проще через revert
