A
а там revert-ы (( которые позже по времени
Size: a a a
2021 March 17
A
реверты старых комитов откатят черипики, даже если их сделать поверх?
AA
не откатят
SG
черрипик да, но рано или поздно фичу придется мерджить в мастер
я бы спросил на stackoverflow, там есть супер монстры
AA
черипик это новый коммит
SG
вопрос звучит нетривиально
A
вот, гуру подтянулись
A
черипик это новый коммит
разве? по-моему на тот же коммит просто ставится метка
SG
разве? по-моему на тот же коммит просто ставится метка
AS
Как вариант: сделать в фича-бранч рибейз мастера и потом сделать реверт ревертов
AA
@jitbit проверил еще раз
A
почти оно, спасибо! думал обойтись без доп.коммитов просто... вот тут чтото такое https://stackoverflow.com/questions/727994/git-skipping-specific-commits-when-merging/729723
L
Можно ещё по идее сделать новый бранч от мастера и смержить туда фича бранч
A
Lev
Можно ещё по идее сделать новый бранч от мастера и смержить туда фича бранч
кстати крутая идея.
ES
разве? по-моему на тот же коммит просто ставится метка
Нет, это новый коммит.
git ~~ блокчейн, умеет только создавать новые коммиты (с >= 1 родителем, кроме initial commit, у него может быть ноль) и двигать ветку (ветка == указатель на коммит).
Соответственно, revert == новый коммит, у которого в описании написали "откатывает то-то". Никак с исходным коммитом не связан.
Если где-то сделали squash-merge, то это называется "создали новый коммит с таким же содержимым, как и ветка, и в описании написали, что он к ней имеет отношение". При этом сама ветка никакого отношения к этому коммиту не имеет. Чтобы начала иметь — можно вмёржить мастер в эту ветку и тем самым сообщить гиту, что они теперь и по сути тоже синхронизированы.
git ~~ блокчейн, умеет только создавать новые коммиты (с >= 1 родителем, кроме initial commit, у него может быть ноль) и двигать ветку (ветка == указатель на коммит).
Соответственно, revert == новый коммит, у которого в описании написали "откатывает то-то". Никак с исходным коммитом не связан.
Если где-то сделали squash-merge, то это называется "создали новый коммит с таким же содержимым, как и ветка, и в описании написали, что он к ней имеет отношение". При этом сама ветка никакого отношения к этому коммиту не имеет. Чтобы начала иметь — можно вмёржить мастер в эту ветку и тем самым сообщить гиту, что они теперь и по сути тоже синхронизированы.
ES
Нет, это новый коммит.
git ~~ блокчейн, умеет только создавать новые коммиты (с >= 1 родителем, кроме initial commit, у него может быть ноль) и двигать ветку (ветка == указатель на коммит).
Соответственно, revert == новый коммит, у которого в описании написали "откатывает то-то". Никак с исходным коммитом не связан.
Если где-то сделали squash-merge, то это называется "создали новый коммит с таким же содержимым, как и ветка, и в описании написали, что он к ней имеет отношение". При этом сама ветка никакого отношения к этому коммиту не имеет. Чтобы начала иметь — можно вмёржить мастер в эту ветку и тем самым сообщить гиту, что они теперь и по сути тоже синхронизированы.
git ~~ блокчейн, умеет только создавать новые коммиты (с >= 1 родителем, кроме initial commit, у него может быть ноль) и двигать ветку (ветка == указатель на коммит).
Соответственно, revert == новый коммит, у которого в описании написали "откатывает то-то". Никак с исходным коммитом не связан.
Если где-то сделали squash-merge, то это называется "создали новый коммит с таким же содержимым, как и ветка, и в описании написали, что он к ней имеет отношение". При этом сама ветка никакого отношения к этому коммиту не имеет. Чтобы начала иметь — можно вмёржить мастер в эту ветку и тем самым сообщить гиту, что они теперь и по сути тоже синхронизированы.
Хм, это вроде ответ вообще не на тот вопрос, прошу прощения.
A
Нет, это новый коммит.
git ~~ блокчейн, умеет только создавать новые коммиты (с >= 1 родителем, кроме initial commit, у него может быть ноль) и двигать ветку (ветка == указатель на коммит).
Соответственно, revert == новый коммит, у которого в описании написали "откатывает то-то". Никак с исходным коммитом не связан.
Если где-то сделали squash-merge, то это называется "создали новый коммит с таким же содержимым, как и ветка, и в описании написали, что он к ней имеет отношение". При этом сама ветка никакого отношения к этому коммиту не имеет. Чтобы начала иметь — можно вмёржить мастер в эту ветку и тем самым сообщить гиту, что они теперь и по сути тоже синхронизированы.
git ~~ блокчейн, умеет только создавать новые коммиты (с >= 1 родителем, кроме initial commit, у него может быть ноль) и двигать ветку (ветка == указатель на коммит).
Соответственно, revert == новый коммит, у которого в описании написали "откатывает то-то". Никак с исходным коммитом не связан.
Если где-то сделали squash-merge, то это называется "создали новый коммит с таким же содержимым, как и ветка, и в описании написали, что он к ней имеет отношение". При этом сама ветка никакого отношения к этому коммиту не имеет. Чтобы начала иметь — можно вмёржить мастер в эту ветку и тем самым сообщить гиту, что они теперь и по сути тоже синхронизированы.
"вмерджить в мастер ветку" не очень получается, ибо реверты из мастер откатывает все изменения ветки
ну я уже делаю "Revert the Revert" как в ссылке @samatg прошу у всех прощения, что сам ее не нашел
ну я уже делаю "Revert the Revert" как в ссылке @samatg прошу у всех прощения, что сам ее не нашел
K
други подскажите по гиту, я чтото уже голову сломал и нагуглить ничего не могу...
было два бранча - фича и мастер. Фичу смерджили в мастер и накатили в прод. И с тех пор еще успели накоммитить всякого в мастер.
через два дня выяснили что фича сыровата в одном супер-экзотическом edge-case. Что сделали: git revert для мердж-коммита в мастере (это был PR squash merge) и еще парочку git revert для других коммитов связанных с "фичей". Это видимо не очнеь правильно, но мы спешили.
и продолжаем работать над фичей в бранче.
НО теперь если мы захотим апдейтнуть фича-бранч из мастера - он попытается смерджить из него revert-коммиты!!
какой бестпректис в таких случаях?
PS. может git merge -s ours master?
было два бранча - фича и мастер. Фичу смерджили в мастер и накатили в прод. И с тех пор еще успели накоммитить всякого в мастер.
через два дня выяснили что фича сыровата в одном супер-экзотическом edge-case. Что сделали: git revert для мердж-коммита в мастере (это был PR squash merge) и еще парочку git revert для других коммитов связанных с "фичей". Это видимо не очнеь правильно, но мы спешили.
и продолжаем работать над фичей в бранче.
НО теперь если мы захотим апдейтнуть фича-бранч из мастера - он попытается смерджить из него revert-коммиты!!
какой бестпректис в таких случаях?
PS. может git merge -s ours master?
В будущем делать отключаемые через конфиг фичи и можно будет не откатывать, если неудачно смерджили? Ну как один раз вариантов
IV
что люди не придумают лишь бы не делать trunk based development с feature toggles