LINUX.ORG.RU
ФорумTalks

git, жизнь и как помирить их

 ,


0

1

Вчера я делал интерактивный git-rebase и похерил чанки, на которые потратил целый день, потому что вырезал не то, что надо. Но мозгов хватило, слава богу, что бы не запороть чужую работу. И самое главное, что я всегда при таких операциях с переписыванием истории обычно начинаю с одного большого диффа всех локальных изменений, но на этот раз я поспешил закоммитить в полпервого ночи и обосрался.

Как вы думаете, мне пора в отпуск, меня гнать из профессии ссаными тряпками или ваш вариант?

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

P.P.S. с gerrit такой проблемы не было бы, т.к. он создает патчсеты перед ревью, и можно создавать Change даже когда есть только идеи предварительного кода, а ребейза фича-веток нет, gerrit сам все что надо ребейзит/мерджит, и можно в любой момент откатить на самый первый патчсет.

★★★★★

Последнее исправление: hobbit (всего исправлений: 1)

Не нужно работать в час ночи и все будет ок 🤗

garik_keghen ★★★★★
()

Всегда получилось восстанавливать код даже после самого запоротого rebase используя reflog.

emorozov
()

Вчера я делал интерактивный git-rebase и похерил чанки, на которые потратил целый день

use git reflog, Luke

eternal_sorrow ★★★★★
()

Почему никто не советует reflog?

grem ★★★★★
()

интерактивный git-rebase

Интерактивный rebase лучше делать в временной ветке. Потом достаточно будет сделать reset --hard на нее в целевой.

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

но на этот раз я поспешил закоммитить в полпервого ночи и обосрался

в полпервого ночи

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

theNamelessOne ★★★★★
()

Использовал бы patch-, а не snapshot-based VCS, таких проблем бы не было.

utf8nowhere ★★★
()

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

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

Потому что система контроля версий должна сама безальтернативно логировать все действия разработчика (свн)

SVN сосёт.

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

reflog помогает вроде </нытьё>

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

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

https://gitready.com/intermediate/2009/02/09/reflog-your-safety-net.html

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

Это если ты git prune не делал. Или твоя гуи-обёртка над гитом, тайком. Хотя это конечно не твой случай, у тебя все действия были недавно. А вот спустя длительное время есть немаленькая вероятность что оно таки случилось и то, что не попало в активные ветки, уже физически удалено из репы и логи не помогут его достать.

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

Лучше полпервого, чем в три ночи. Я один раз сделал пару комитетов, а потом отвлёкся и забыл, что не переключился на другую ветку и сделал hard reset на origin

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

Чтобы не зафакапить ее. Например, неправильным разрешением конфликтов. Для remote веток не так актуально, а вот для локальных – более чем.

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

Это если ты git prune не делал.

да, древо не «перетрахивал»(C)

Или твоя гуи-обёртка над гитом, тайком

вот поэтому не балуюсь гуями

seiken ★★★★★
() автор топика
Ответ на: комментарий от i-rinat

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

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

да. rebase у меня завершился. Я увидел, что обосрался, только когда просмотрел дифф пулл-реквеста в битбакете.

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

А откат так проще, чем с использованием reflog

git reflog + git reset --hard $COMMIT_SHA — явно меньше возни, чем с временной веткой на каждый rebase (тем более если ты не планируешь жёстко факапить каждый первый rebase). Говорю как человек, который использует (interactive) rebase по несколько раз на дню.

theNamelessOne ★★★★★
()

Вчера я делал интерактивный git-rebase

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

подумываю настроить коммит хук

Ты ещё хук на архивацию исходников в tar.gz сделай.

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

Говорю как человек, который использует (interactive) rebase по несколько раз на дню.

…зачем? Для меня интерактивный ребейз это исключительное событие. Копаться в рефлоге ради одного исключительного события явно сложнее, чем сделать git switch -c tmp.

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

зачем?

Стараюсь держать аккуратную историю изменений в фича-ветках для упрощения ревью, поэтому регулярно переписываю историю на этапе подготовки PR к ревью и во время ревью — сливаю/редактирую/удаляю коммиты, меняю их местами, иногда разбиваю на несколько (сильно помогает во всем этом, конечно, magit). Это позволяет проводить ревью, просто просматривая коммиты по порядку, т.к. каждый коммит — это какое-то одно осмысленное, изолированное изменение.

Для меня интерактивный ребейз это исключительное событие. Копаться в рефлоге ради одного исключительного события явно сложнее

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

  1. переключиться с целевой на временную ветку;
  2. выполнить рибейз;
  3. переключиться обратно на целевую ветку;
  4. сделать git reset --hard.

В то время как мне:

  1. просто выполнить рибейз без бессмысленных скачков по веткам;
  2. (в исключительно редком случае, наверно в 2% всех рибейзов) посмотреть reflog и сделать reset, если сильно зафакапил.

Ну и не надо утверждать, что reflog — это что-то сложное.

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

например, я делаю коммиты на некоторые части более крупного изменения, потому что не знаю заранее, что войдет в пулл-реквест, а что нет. Потом вдруг мне надо в автосервис там или к врачу или в кинцо, ну и просто пушаю всё сорс-ветку, с которой будет создал пулл-реквест. Потом на следующий день не еду в офис, а с фирменного лэптопа разгребаю что накоммитил вчера и выкидываю все ненужное сворачивая все части в один коммит. Идея конечно в том, что один коммит должен быть на один пулл-реквест, не более. Иначе надо к каждой части писать коммит мессадж с развернутым описанием, ссылками на джайра таски и проч, что муторно.

А всё с лэптопа без пуша на сервер мне мешает паранойа, типа, если со мной не дай бог что случится (помрет дальний родственник-миллионер, и я перееду жить на Мальдивы, всё бросив), вся работа будет на сервере компании.

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

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

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

я со смартфона даже в шахматы уже стрессую

seiken ★★★★★
() автор топика

Ну круто. А я ветки удаляю сразу как залил. Дурень, вот оно что оказывается, случиться может

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

rebase не нужен, merge наше все.

Вот имено.

 merge --sqash

Хватит всем

Psilocybe ★★★★
()

Пришёл в этот тред, чтобы посоветовать reflog :)

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

Стараюсь держать аккуратную историю изменений в фича-ветках для упрощения ревью, поэтому регулярно переписываю историю на этапе подготовки PR к ревью и во время ревью — сливаю/редактирую/удаляю коммиты, меняю их местами, иногда разбиваю на несколько (сильно помогает во всем этом, конечно, magit). Это позволяет проводить ревью, просто просматривая коммиты по порядку, т.к. каждый коммит — это какое-то одно осмысленное, изолированное изменение.

ППКС

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

поэтому регулярно переписываю историю на этапе подготовки PR к ревью и во время ревью — сливаю/редактирую/удаляю коммиты, меняю их местами, иногда разбиваю на несколько

То есть кодишь как придется, а потом задним числом наводишь порядок?

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

rebase нужен для нескольких вещей:

  1. для чистого merge в основную ветку (можно заменить подмерживанием сначала основной ветки в фиче-ветку, но тогда история начинает выглядеть очень запутанной, практически нечитаемой)
  2. если где-то накосячил с порядком коммитов, или не хочется добавлять ещё один коммит вида «fixed a typo», «fixed linter issue», которые бессмысленно замусоривают историю
  3. если хочется организовать абсолютно линейную историю коммитов в репе, что я очень люблю для простых проектов, разарабатываемых силами 1-3 человек, потому что такая история прекрасно читается и понимается, в отличие от мириада переплетающихся веток

В общем, rebase полезная и нужная операция, владеть которой должен уметь каждый.

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

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

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

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

seiken ★★★★★
() автор топика

рм рф .гит && гит инит && гит адд . && гит коммит -ам «Почистил репку». И норм, всегда так делаю любой непонятной ситуации :D.

LINUX-ORG-RU ★★★★★
()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 1)
Ответ на: комментарий от theNamelessOne

Стараюсь держать аккуратную историю изменений в фича-ветках для упрощения ревью, поэтому регулярно переписываю историю на этапе подготовки PR к ревью и во время ревью

Ты молодец, что следишь за историей, такой PR, особенно если он большой, ревьювить одно удовольствие. Вот только rebase-ы во время ревью — это боль, потому что сложно отследить, как именно ты отреагировал на определенные комментарии. Гитхаб и Гитлаб умеют показывать разницу между «версиями» ветки, но это работает не всегда, и не все пользуются ими во время ревью.

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

filosofia
()

Много уже советовали reflog, да, это способ решения проблемы. Я же посоветую способ избегания такой проблемы в будущем. Делай потенциально опасные изменения в отдельной ветке. Git checkout -b rebase, основная ветка остаётся в безопасности, делаешь rebase и, если все хорошо, переименовываешь эту ветку обратно в основную. Или можешь просто делать бэкап ветки перед ребейзом (по сути то же самое).

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

Нет конечно, кодить/коммитить в процессе тоже стараюсь аккуратно, просто невозможно все заранее предугадать.

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

понял. Запомнил на будущее. Спасибо.

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

как именно ты отреагировал на определенные комментарии

Ответил на комментарий, что исправил

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

Стараюсь не ждать, пока мне напомнят о ребейзе, тем более, что коммит (diff) исправляющий одну вещь нагляднее, чем >=2 коммитов исправляющих одну вещь

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