Как называется такая практика и является ли она приемлемой?

Question

[Вадим]

Диаграмма:



Приведена на рисунке ветка мастер .
1. Является ли нормальной практикой для разработчика создать ветку feature1 от не последнего коммита мастера, то бишь не от "g" и потом смерджить feature1 с коммитом X2 в мастер затирая изменения f и g?
2. Какой git командой это можно сделать?

Comments

[WbICHA]

затирая изменения f и g?

Какой в этом практический смысл? Неговоря уже о рисках потерять нужные изменения.

[Вадим]

практический смысл в том, что он хочет увильнуть от нормального revert changes и если ему срочно нужно задеплоить в продакшен свои изменения, а изменения f & g еще не протестированны, то он таким образом их просто избегает. Делает H1, тестирует свои изменения только, а я хочу определить паттерн и запретить такие практики в самом пайплайне - если возможно конечно !

[WbICHA]

Вадим, на продакшан должна идти отдельная релизная ветка (в идеале для каждого релиза своя), а затирать изменения (особенно чужие) на любой ветке — это это не то, что антипаттерн, это чуть ли не противозаконно.
Если ему надо что-то на прод, пусть делает соответствующую ветку. В крайнем случае самый простой и быстрый вариант, оставить ваш мастер как есть и его на прод заливать, создать новую ветку (прим: develop) и в девлоп все коммиты лить, а в мастер тогда хард ресетить до нужных изменений. Это всё ещё так себе, но проще и на порядок лучше.

[WbICHA]

Вадим, и да, отвечай нормально, я не экстрасенс, чтобы знать кто мне что пишет без упоминания.

[Вадим]

WbICHA,

Напишу все предысторию... в начале не написал, сам разбирался что там было вообще !
1. один разраб (2) обратился ко мне, когда один фрукт (разраб 1) предложил ей создать ветку из предыдущего коммита "e" и перезаписить/удалить изменения в 2-х предыдущих коммитах (мастера), после мерджи ветки feature 1 с мастером. Я пытаюсь понять как этот фрукт это реализует если прямая запись в ветку мастер у нас на удаленном хранилище запрещена. Наверное просто делает Pull Request, кот удаляет предыдущие два изменения - но в истории они сохраняются, просто пытаюсь понять как это сделать чисто командным способом, без того, чтобы ручками их удалять ! В коммитах f и g изменений очень много !
2. Можно ли это как-то отследить - хотя вряд ли конечно !

[WbICHA]

Вадим, что-то тут не то. Если они есть в истории, значит измения есть и никуда они не пропали. Технически можно сделать новый коммит, скопипастив в него старую реализацию (до этих 2ух коммитов), но, опять же, этот окммит будет в истории.
Удалить изменения без удаления коммитов из истории или добавления нового коммита просто нельзя.

[Вадим]

WbICHA, новый коммит добавляется конечно, после мерджа с мастером. Я вот просто думаю, как он в pull request сразу все изменения отменяет, что бы ли в f и g

[WbICHA]

Вадим, из банального можно тупо откатиться на нужный коммит, клонировать всю репу, далее подтянуть все последние изменения и скопировать клонированную репу обратно.
Можно ли это сделать с помощью гита понятия не имею, как минимум не вижу никакого практического смысла в этом вообще.

[Сергей Кузнецов]

Вадим,

новый коммит добавляется конечно, после мерджа с мастером

Почему вы решили что после? Коммит, отменяющий действия f и g появляется в ветке feature1 ДО слияния конечно. И делать это легко. Нужно первым делом подтянуть к себе в тематическую ветку актуальную master, затем сделать банальный revert коммитов f и g. Либо сделать это одним шагом, создав синтетический коммит отменяющий всё новое в мастере и затем уже отправлять Pull Request в master. Все эти манипуляции в любом случае являются вандализмом и должны быть заблокированы на этапе рецензирования Pull Request.

[Дмитрий]

Мне кажется у вас проблема в этом:

а изменения f & g еще не протестированны

У вас непротестированные f & g лежат в мастере? Определенно им место в отдельной ветке.

[Вадим]

Дмитрий, имелось ввиду - не посланы в продакшн

Answer 1

[Сергей Кузнецов]

Такая практика называется вандализмом и не является приемлемой.

Создать коммит Х2, который отменит все новые изменения master можно например так

# Вредоносные действия делаем в своей ветке, 
# так как не можем коммитить напрямую в master
git switch feature
# Якобы подтягиваем изменения из master, но по факту отменяем.
git merge --ff $(git commit-tree -p master -p feature1 -m "X2" feature1^{tree})
# Отправляем Pull Request обратно в master

Но зачем? Практика перезатирания чужих правок ненормальна, если только это не исправление ошибок.

Чтобы бороться с вандализмом используется рецензирование, когда Pull Request не вливается в основную ветку пока другие люди не просмотрят изменения и не одобрят.

Comments

[Вадим]

я говорю, что хочу запретить подобную практику - поэтому и спрашиваю. Правда как запретить - не знаю... можно ли на уровне пайплайна это как-то проверять git коммандой?

[Сергей Кузнецов]

Вадим, запретить только через ручное рецензирование. Потому что машина не умеет различать хорошие правки от вандальных.

И в вашем вопросе не было ни слова про запретить.

[Вадим]

Сергей Кузнецов,

сначало просто понял, а потом понял что следует запретить )) Ручное рецензирование - во время Pull Request?

спасибо !

[Сергей Кузнецов]

Вадим, Да, Pull Request предназначен для рецензирования (Review). Когда у разработчика нет прав напрямую коммитить в мастер. И желательно даже отобрать права на самостоятельное Merge Pull Request. Пусть этим занимается другой специально-обученный человек. И слияние разрешать только когда как минимум два рецензента одобрили (Approve).

Answer 2

[jcmvbkbc]

Является ли нормальной практикой для девелопера создать ветку feature1 от не последнего коммита мастера, то бишь не от "g"

Да. В частности это стандартная практика разработчиков ядра linux: фичи должны расти от релизов или релиз-кандидатов, а не от каких-то случайных коммитов.

и потом смерджить feature1 с коммитом X2 затирая изменения f и g?

Из вопроса непонятно, это требование -- затирать, или это побочный эффект которого хочется избежать?
Если делать обычный git merge, то никакого затирания не будет. Будут конфликты, если изменения касаются одних и тех же мест, иначе будет объединение изменений ветки и мастера.
Чтобы затирать изменения можно делать git merge --strategy=ours -- в результате мёржа изменения сделанные в ветке которая мёржится будут потеряны.

Comments

[Вадим]

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

[Сергей Кузнецов]

Вадим, уничтожать чужую работу это сомнительная практика. Вы точно уверены что тот разработчик так делает?

[Вадим]

Смотрите Сергей Кузнецов, что он делает. Коммиты f и g остаются в истории, но после всего ветка мастер становится такой

a - b - c -d -e -f -g - H1 - причем в H1 нету изменений сделанных в "g" и "f". Как это происходит, не совсем понимаю. То ли после rebase переименовывает feature1 в master?

[Дмитрий Беляев]

a - b - c -d -e -f -g - H1

Вадим, ну и где же здесь затерлись f и g и если они остались в истории?
А делает так обычный git merge со стратегией fast-forward, которая применяется по умолчанию, когда в ветках не пересекаются изменения в одних и тех же файлах, то есть например коммит f поменял файл f, коммит g - файл g, а коммит H1 - файл h, конфликтов тут точно не будет и git merge применяет стратегию fast-forward

[Сергей Кузнецов]

Вадим, такой эффект реализовать не сложно. Только скажите зачем вам это?

[Вадим]

Сергей Кузнецов, и @bingo347

1. один разраб (2) обратился ко мне, когда один фрукт (разраб 1) предложил ей создать ветку из предыдущего коммита "e" и перезаписить/удалить изменения в 2-х предыдущих коммитах (мастера), после мерджи ветки feature 1 с мастером. Я пытаюсь понять как этот фрукт это реализует если прямая запись в ветку мастер у нас на удаленном хранилище запрещена. Наверное просто делает Pull Request, кот удаляет предыдущие два изменения - но в истории они сохраняются, просто пытаюсь понять как это сделать чисто командным способом, без того, чтобы ручками их удалять ! В коммитах f и g изменений очень много !
2. Можно ли это как-то отследить - хотя вряд ли конечно !

[jcmvbkbc]

как это сделать чисто командным способом, без того, чтобы ручками их удалять

Вадим, в свою ветку замёржить мастер со стратегией ours, после этого замёржить свою ветку в мастер.

[Сергей Кузнецов]

Вадим,

удаляет предыдущие два изменения - но в истории они сохраняются, просто пытаюсь понять как это сделать чисто командным способом, без того, чтобы ручками их удалять !

я вам подробно объяснил какой командой это сделать в ответе.
Отменённые коммиты разумеется останутся в истории, мы же не удаляем их, а фактически делаем revert.

[Сергей Кузнецов]

@jcmvbkbc
git merge --strategy=ours отменит только те изменения, которые конфликтуют с нашими, а не все. Так что это не то.

[jcmvbkbc]

git merge --strategy=ours отменит только те изменения, которые конфликтуют с нашими, а не все. Так что это не то.

Сергей Кузнецов, нифига, команды которые я привёл делают ровно то, о чём говорит ОП. Не надо путать стратегию ours c опцией разрешения конфликтов ours стратегии recursive.

[Сергей Кузнецов]

jcmvbkbc, спасибо, не знал.

Answer 3

[Saboteur]

Ветка отпочковывается от любого коммита. Обычно руками никто не создает ветку из старых коммитов, делают из последнего свежего.
Просто весь смысл ветки в том, чтобы свою фичу пилить не блокируя мастер или релиз

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

P.S. в фичаветку можно периодически мержить из мастера, чтобы держать свою ветку "свежей" и в конце, при мерже в мастер, вероятность конфликтов была меньше.

А так - обычный feature-branch flow

Answer 4

[Vitsliputsli]

Последний коммит в ветке сегодня, завтра уже может и не быть таковым.
Merge коммиты не "затирает" - пишите команды, которые используете.

Comments

[Вадим]

как вопрос по команде был один из них...

что знаю

git checkout hash_of_commit_e
git checkout -b feature1
.... changes
git add -A && git commit -m "commit1"
.... changes
git add -A && git commit -m "commit2"

дальше команда которая затирает изменения f и g, но сохраняет их в истории git log на ветке мастер

[Vitsliputsli]

Вадим, что за секретная команда?
Если коммиты в логе, значит не "затерты". После merge у вас будет в истории разветвление - это нормально. Ветка - это ярлык на коммите, поэтому что предыдущие коммиты принадлежат ветке можно говорить лишь условно.
Если такая ситуация не нравится, то нужно делать не merge, а rebase на последний коммит master. Будет выглядеть "красивее", но так как это перезапись истории, то обычно не любят этот вариант.