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