LINUX.ORG.RU

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

 , ,


3

1

У меня ситуация, когда програмист тыкает палочкой в код ( те делает кучу мелких коммитов), иногда ошибается и переделывает. Причем тыкает он не у себя локально, а на тестовом сервере с автодеплоем. В общем, по кейсу в резулате на гите куча коммитов, которые не информативны и нафиг не нужны. Хотелось бы , чтобы он тыкал в каком-нить бранче, а потом при мерже оставался один коммит со всеми изменениями по задаче.

Как это сделать?

★★★★

Как это сделать?

git log

ищешь хеш нужного коммита.

git rebase -i "хеш нужного коммита"

Ставишь squash для всех, кроме первого (он же ранний).

git push -f
anonymous
()

Я обычно --amend использую для таких вещей.

urxvt ★★★★★
()

А в чем хостится репозиторий? Гитлаб например предлагает опцию в Merge Request делать squash перед merge.

chkalov
()
Ответ на: комментарий от chkalov

Гитлаб например предлагает опцию в Merge Request делать squash перед merge.

А с branch-ами он так умеет?

anonymous
()

Как это сделать?

Ещё вариант - добавить кого-нибудь в контрибуторы, кто умеет с гитом справляться.

anonymous
()
Ответ на: комментарий от eternal_sorrow

git rebase -i => fixup

+1

Я так делаю.

anonymous
()

Спасибо за ответы!

constin ★★★★
() автор топика
Ответ на: комментарий от slackwarrior

push — forse

Ответ соответствует аватаке ТС с точностью до грамотности.

anonymous
()
Ответ на: комментарий от anonymous

Аналог git merge –squash

Вот это имхо самое правильное решение. Без ковыряния в коммитах и через бранч. Проблема в том, что у меня автодеплой на тесте ест бранч test, а в проде бранч master. Но это уже можно скорректировать.

Написал инструкцию для кодеров. ( странно, да)

#перед началом эксперементов создаем новый бранч "test"
git checkout -b test
#Switched to a new branch 'test'
#создаем для теста файл test1.txt
touch test1.txt
#коммитим и пушим 
git add test1.txt
git commit -m "add test1.txt"
git push --set-upstream origin test
# но ,допустим, нам понадобился еще файл "test2.txt"
touch test2.txt
git add .
git commit -m "add test2.txt"
git push
# и вот , у нас все работает как надо, но вместо одного коммита у нам два.
# время переключаться в бранч мастер мержить 
# переключаемся в мастер
git checkout master
#Switched to branch 'master'
#Your branch is up to date with 'origin/master'.
# мержим наши два бранча 
git merge --squash test
# и коммитим теперь наш итоговый код с нормальным текстом
git commit -m "задача выполнена добавлением двух файлов"
# пушим
git push
# если теперь посмотреть в гит, то там не будет наших тестовых коммитов
# будет только 1 коммит с названием "задача выполнена добавлением двух файлов" 
# который добавил два файла

constin ★★★★
() автор топика
Последнее исправление: constin (всего исправлений: 1)

мы используем git rebase -i и git push –force в ветку. Это позволяет причесать ветку перед показом коллегам и мержем.

В мастере конечно никаких форсов.

max_lapshin ★★★★★
()
Ответ на: комментарий от anonymous

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

chkalov
()
Ответ на: комментарий от anonymous

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

chkalov
()
Ответ на: комментарий от chkalov

В общем , git merge –squash овечает на вопрос, но появилась другая проблема. Тестовые бранчи с рандомными именами не проходят на тестовый сервер. Те если я отключаю фильтр бранчей на вебхуке, то тестовый сервер все равно кушает только свой бранч.

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

Те нужно все же работать в предалах одного бранча

constin ★★★★
() автор топика
Последнее исправление: constin (всего исправлений: 1)

Главный вопрос: зачем работать и коммитить на тестовый сервер, извращения должны фиксироваться, если да, для чего?

Создаешь локальную ветку от отслеживаемой ветки. Там извращаешься. Мержишь (–squash) свои извращения в отслеживаемую ветку.

anonymous
()
Ответ на: комментарий от constin

как не использовать при этом редактор

Что за проблема с редактором? Поставь nano в alternatives.

anonymous
()
Ответ на: комментарий от anonymous

Что за проблема с редактором?

дело не в выборе редактора, дело в том, что я не хочу , чтобы у середине консольной команды включался редактор. Так, например я делаю коммит git commit -m «текст» . без редактора

constin ★★★★
() автор топика
Ответ на: комментарий от constin

дело не в выборе редактора, дело в том, что я не хочу

Не вижу «проблемы». Не вижу! Покажи. Разъясни. Сделай понятным.

anonymous
()
Ответ на: комментарий от anonymous

Главный вопрос: зачем работать и коммитить на тестовый сервер, извращения должны фиксироваться, если да, для чего?

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

Создаешь локальную ветку от отслеживаемой ветки. Там извращаешься. Мержишь (–squash) свои извращения в отслеживаемую ветку.

локально никак..

constin ★★★★
() автор топика
Ответ на: комментарий от constin

я не очень представляю инфраструктуру.

Те если я отключаю фильтр бранчей на вебхуке, то тестовый сервер все равно кушает только свой бранч.

где это конфигурируется?

можно ли сделать фильтр например test/%random-branch-name% ?

то как ему определить, с каким бранчем надо работать в данный момент?

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

chkalov
()
Последнее исправление: chkalov (всего исправлений: 1)
Ответ на: комментарий от constin

локально никак..

Что даже свою рабочую директорию создать не можешь? Скопировал в свой локальный гит, извращаешься, берешь патч своих извращений и накладываешь в отслеживаемый гит.

anonymous
()
Ответ на: комментарий от anonymous

Что даже свою рабочую директорию создать не можешь?

Они не могут локально проверить работоспособность кода.

constin ★★★★
() автор топика
Ответ на: комментарий от constin

Они не могут локально проверить работоспособность кода.

Так пусть в него и не лезут тогда, коли «безрукие».

anonymous
()
Ответ на: комментарий от constin

Они не могут локально проверить работоспособность кода.

Зачем им проверять? Главное, чтобы ты локально мог. Они будут проверять только окончательный код.

В общем какой-то изврат, который не понять. Зачем делиться промежуточными результатами, которые не хочешь показывать изначально?

anonymous
()
Ответ на: комментарий от anonymous

Зачем им проверять? Главное, чтобы ты локально мог. Они будут проверять только окончательный код.

Ты все перепутал.

Есть кодеры, у которых есть тестовый сервер, куда они тыкают кучей коммитов, потому что локально код проверить им никак. Те они делают мелкий коммит и смотрят на тестовом сервере, что получилось. Когда задача решена, но на гите 20 коммитов их мучений, которые я не хочу видеть. Я хочу видеть только один итоговый коммит.

Локально не работают, потому что код можно запустить со всем окружением только на тестовом сервере.

constin ★★★★
() автор топика
Ответ на: комментарий от constin

rebase тоже шляпа.. оставляет текст первого коммита.

и еще опасная процедура.

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

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

constin ★★★★
() автор топика
Ответ на: комментарий от anonymous

Расшифруй

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

constin ★★★★
() автор топика
Ответ на: комментарий от constin

локально на своем компе кодер не может проверить работоспособность кода. если бы тестовое окружение было у кодера на компе

Так какого чорта это не так?! В этом все «грабли»! В этом все твои «проблемы»! Ты их сам себе создал, а теперь «героически» пытаешься их преодолеть с помощью отвратительнейших костылищь! Зачем?!

anonymous
()
Ответ на: комментарий от anonymous

Так какого чорта это не так?! В этом все «грабли»! В этом все твои «проблемы»! Ты их сам себе создал

Ну я бы с этим поспорил, я не строил эти приложения с нуля. Я прекресно понимаю, как оно ДОЛЖНО быть, но вот есть долбанутый кейс. Ну гипотетически представь, что например, какой-нить монолитный древний монстр весит 1000-500 гигов, жрет уйму ресурсов и еще его куски наскиданы по разным местам. И нет задачи его переделать. Я же не альтруист, и ты не альтруист.

Те вот данность, локально дома это не поднять.

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

Я бы не хотел это дальше обсуждать.

остановлюсь на git merge –squash , решив проблемы с деплоем разных бранчей и возможных конфликтов.

constin ★★★★
() автор топика
Ответ на: комментарий от constin

кодеры не хотят держать тест у себя на машине

В топку таких кодеров. Вон пошли!

anonymous
()
Ответ на: комментарий от constin

Когда задача решена, но на гите 20 коммитов их мучений, которые я не хочу видеть.

Тогда вопрос зачем кодер работает в тестовой ветке? Работать надо в рабочей ветке, тестировать - в тестовой. А изменения в основную принимать по определенным процедурам. После завершения работы рабочая ветка и соответствующая тестовая удаляются, а git gc почистить 20 коммитов мучений.

anonymous
()
Ответ на: комментарий от constin

rebase тоже шляпа.. оставляет текст первого коммита.

Ты наверное fixup использовал. Пробуй squash. Он позволит менять коммит-месседж.

Ещё как вариант можно потом отдельно с помощью amend поменять сообщение, но это дополнительное присядание.

и еще опасная процедура.

Безопасная до тех пор, пока ты в своей локальной ветке ковыряешься :) Ну а дальше git push --force-with-lease

mkam
()

Вариант 1. amend, squash, rebase
Вариант 2. не заморачиваться, пусть будут однотипные комиты (но тогда надо подписывать нормально)

p.s. anonymous советует не хорошее, force лучше не юзай

pru-mike ★★
()
Ответ на: комментарий от constin

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

а как он определяет, с каким бранчем надо работать в другой момент?

тебе решили проблему гита средствами гита, не нужно пытаться теперь решить средствами гита проблему CI

hebiro8709
()
Ответ на: комментарий от constin

Я прекресно понимаю, как оно ДОЛЖНО быть, но вот есть долбанутый кейс

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

в чем проблема запустить код из произвольной ветки? из каких палок сделан твой CI? почему ты соглашаешься с анонимусом, который уже накатил и несёт бред о том, что всё должно тестироваться на машинах разработчиков?

hebiro8709
()
Ответ на: комментарий от hebiro8709

а как он определяет, с каким бранчем надо работать в другой момент?

в webhook gitea прописан фильтр по бранчу. на самих серверах в зависимоти от ролей тоже прописано какой бранч им забирать.

но я могу сказать скрипту деплоя, чтобы он смотрел в хуке имя бранча и делал туда checkout. Тогда сервер будет работать на том бранче, который запушили на гит последним. Для теста сойдет. Надо только, чтобы кодеры не забывали мержить свои тестовые ветки.

из каких палок сделан твой CI?

в описанном случае gitea после push делает вебхук на сервис на сервере, который запускает баш скрипт, который обрабатывает payload и пулит изменения с гита.

в чем проблема запустить код из произвольной ветки?

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

Я уже протестировал вариант с git merge –squash и checkout последнего бранча в вебхуке на сервере. Если нет лучшей практики, то оставлю этот вариант.

constin ★★★★
() автор топика
Последнее исправление: constin (всего исправлений: 1)
Ответ на: комментарий от constin

из каких палок сделан твой CI?

в описанном случае gitea после push делает вебхук на сервис на сервере, который запускает баш скрипт, который обрабатывает payload и пулит изменения с гита.

то есть нормального CI в принципе нет, вместо него башскрипт?

в чем проблема запустить код из произвольной ветки?

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

это не проблема веток вообще. это проблема с тем, что вместо CI сервера у вас башскрипт, при чём совершенно непонятно почему – установка и настройка jenkins занимает ну час времени вместе с перекурами

hebiro8709
()
Ответ на: комментарий от hebiro8709

а кто будет тесты писать? дядя Вася? у меня его нет.

там вначале вообще все имели рут доступ до прода и правили код прямо там. теперь хотя бы деплой только через git.

баш скрипт не тестирует ничего, он просто делает пул

так то я хочу проект на кубах с ci/cd , где все покрыто тестами , с командой, которая работает по agile и прочие штуки. не надо о грустном.

constin ★★★★
() автор топика
Ответ на: комментарий от constin

а кто будет тесты писать? дядя Вася? у меня его нет.

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

anonymous
()
Ответ на: комментарий от anonymous

Тебе нужен дядя Вася, умеющий гит и назначенный админом этого самого гита.

те вместо того, чтобы организовать процедуры, надо просто посадить за деньги человека, котрый будет чистить говно?

constin ★★★★
() автор топика
Ответ на: комментарий от constin

надо просто посадить за деньги человека, котрый будет чистить говно?

Ну разумеется! Сам порядок никак не наведётся! Мысль о таком - это бред!

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