Изменение коммитов в Git

[gagoman]

Главное в туториалах по rebase — не делайте этого с комитами, доступными не только вам.

[Shark]

То же касается и amend и вообще любых правок репозитория после того как сделан git push. Кстати, об этом неплохо-бы написать в статье, пусть даже многие сервера и не принимают такие правки.

[A1lfeG]

А ещё не делать git pull --rebase после мержа веток.

[taliban]

А если надо? Можно прекрасно сделать rebase даже с общими ветками, и даже без последствий типа merge у остальных.

[starius]

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

[taliban]

Это слишком большой холивар merge vs rebase.
Я лишь сказал что можно это сделать легко без последствий, даже если работаешь группой в одной ветке.
Зачем надо или зачем не надо, это другой вопрос.

[hell0w0rd]

Извините, но капитанская статья… Очень хочется увидеть примеров вышеописаных действий. Вот допустим я нагадил накомитил в мастер, опомнился, захотел вынести в ветку — а не тут то было, пуш уже сделан.
Допустим вариант с анпабликом ветки, исправления косяков, и обратный паблик. Просто я не особо много в команде успел поработать, но думаю что в команде просто так в мастер не покомитишь, а в своей ветке сколько угодно можешь исправлять. Или я не прав?

[Zoberg]

В таких случаях лучше сделать git revert, я думаю. Хотя еще лучше в своей ветке работать, тогда таких ситуаций возникать не должно.

[weirded]

Кстати хорошая идея статьи для хабра — «Что делать, если вы нагадилинакоммитили в мастер».

[vbabaev]

В разделе мана про теги есть фраза о том, как переименовать тег: "Just admit you screwed up, and use a different name."
Думаю, эта статья должна начинаться так же.

[spacediver]

«Just admit you screwed up, and use a different job.»

[evil_random]

А самое интересное начинается, когда начинаются конфликты.

Ещё rebase может послужить, когда нужно поменять коммиты местами.

[grossws]

Interactive rebase вообще мощная штука.

Я им, как правило пользуюсь для подготовки истории следующими способами:
— изменение порядка коммитов,
— слияние/разделение коммитов (чтобы в репозитории оставались только рабочие коммиты),
— ради переработки сообщений (в частности, с описанием номера исправленного недостатка для redmine).

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

[tyomitch]

Вместо рекомендуемой автором пары

git add .
git commit --amend

достаточно одной команды:

git commit -a --amend

[tenzink]

Я бы порекомендовал вменяемый gui-клиент типа git extensions, где можно неспеша посмотреть на изменения, добавить и закоммитить без использования консоли. Гитом можно эффективно пользоваться из UI клиента.

[grossws]

Я обычно пользуюсь tig (git ncurses frontend). Добротный консольный клиент с хорошим текстовым gui (tui).

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

[themiron]

разница есть, git add. имеет локальную область действия, начиная от текущего каталога, плюсом добавит untracked, если есть
git commit -a предложит закоммитить только измененые по всему реапозиторию, вне зависимости от относительного пути

[akzhan]

Хорошее правило, — не использовать git commit -a или git add .. Чтобы лишнего не коммитить, лучше указывать список файлов явно. Если ветка своя, то можно так и не париться.

[Shark]

Я люблю использовать git add -p, реже git add -i. Заодно и беглый обзор изменений.

[weirded]

А у нас git add -p — это категорическое требование к разработчикам :)

[vhytyk]

Прошелся по хабу GIT, и к своему удивлению заметил, что мало статей собственно о теме.
На счет данного поста — всегда обходился soft reset-ом, но это явно лучше, практически ничего не меняя (не убивая существующих коммитов) делаешь маленькие правки. И вроде знал о такой возможности, но руки не доходили почитать мануал. Спасибо автору, занес в избранное.