LINUX.ORG.RU
ФорумTalks

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

 ,


0

1

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

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

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

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

★★★★★

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

Сам пошутил, сам посмеялся. Молодец!

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

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

Сам пошутил, сам посмеялся. Молодец!

Ну так ты тоже остряк, как я погляжу.
Не, я не люблю гит не потому, что сам СВНщик. Просто меня раздражает эта многофункциональная опасная бритва с мануалом размером в «войну и мир» и сотней команд с ключами. А ведь это ВСПОМОГАТЕЛЬНЫЙ инструмент, схрена ли он вообще требует к себе такого внимания.

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

Просто меня раздражает эта многофункциональная опасная бритва с мануалом размером в «войну и мир» и сотней команд с ключами. А ведь это ВСПОМОГАТЕЛЬНЫЙ инструмент, схрена ли он вообще требует к себе такого внимания.

Понятия не имею. Я не читал эти мануалы. Мне вполне хватает базовых команд: init, clone, fetch, pull, push, rebase, merge, log, commit, checkout, reset. Если нужно что-то сложнее, спасает гугл, но это требуется примерно полтора раза в год. Так что я бы не сказал, что гит как-то сложен в использовании.

hateyoufeel ★★★★★
()

Сорри, не читал пост, т.к. при чтении загоовка сразу возник вопрос (возможно уже задавали): ПомЕрЯть, чтоб узнать размеры или помИрИть, чтоб прекратить вражду?

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

Позор на мою голову. Ты прав. Забываю русский язык. Конечно же, помирить, от слова «мир».

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

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

Да... Линус Торвальдс сходит на месяцок в отпуск, разрулит все концептуальные проблемы, сделает рефакторинг кодовой базы Git, напишет новую документацию и обучит юзеров заново. Вот и всё. Явно проблема не в твоей невнимательности. Надо просто немного поправить легаси.

Не стоит париться, и тратить своё время отпуска.

Mirage1_
()

Лови лайфках – перед любой сложной операцией с git нужно выполнять команду:

tar -czvf project-backup.tar.gz <git_project_dir>
Aber ★★★★★
()
Ответ на: комментарий от Aber

этого мне не нужно, т.к. я проверяю историю коммитов (хэши) перед тем как пушить в главную development ветку. А фича-ветку не жалко. Плюс надо придерживаться правила commit faster commit earlier и склонять коллег к agile, XP, devops и всевозможным мокам и эмуляторам. К сожалению, не все это понимают. Кто-то до сих пор живет в мире систем из 90х.

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

А как надо кодить?

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

Или если ты в процессе исправления бага решил поправить что-то ещё, там форматирование поменять или сигнатуру метода, чтобы API сделать поудобнее?

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

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

Новую ветку, делаеш фикс. Потом мерджиш фикс со своей фичей.

Или если ты в процессе исправления бага решил поправить что-то ещё, там форматирование поменять или сигнатуру метода, чтобы API сделать поудобнее?

Не делай так.

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

Новую ветку, делаеш фикс. Потом мерджиш фикс со своей фичей.

Это муторно и оверхедно. Зачем, если я могу писать как пишется, в процессе коммитить всё написанное мелкими кусочками через git add -p, а в конце сделать interactive rebase? Чтобы что?

Не делай так.

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

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

ачем, если я могу писать как пишется, в процессе коммитить всё написанное мелкими кусочками через git add -p, а в конце сделать interactive rebase? Чтобы что?

Это не муторно и оверхедно? Ну Ок.

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

Это не муторно и оверхедно? Ну Ок.

Это даёт дополнительные возможности уже после того, как сделал коммит. Зачем вырубать коммиты в камне, пока они в своей фичеветки и от них никто не бранчевался? То, что решая задачу ты только к концу понимаешь, как сделать будет лучше - это скорее правило, а не исключение. И тогда почему бы не перестроить свои коммиты под это новое лучшее решение, как будто «оно тут так и лежало»?

Когда твой код влит и с ним работают другие люди (+ ты из будущего), их как правило не волнуют твои муки выбора и творческий путь. Им нужно в коде разобраться. И для них имеет смысл оформлять красивые коммиты, а не «сохранять всё как было».

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