Как стать автором
Обновить

Комментарии 21

Главное в туториалах по rebase — не делайте этого с комитами, доступными не только вам.
То же касается и amend и вообще любых правок репозитория после того как сделан git push. Кстати, об этом неплохо-бы написать в статье, пусть даже многие сервера и не принимают такие правки.
А ещё не делать git pull --rebase после мержа веток.
А если надо? Можно прекрасно сделать rebase даже с общими ветками, и даже без последствий типа merge у остальных.
Зачем надо? Либо остальные тоже будут вынуждены править историю, либо такие манипуляции сильнее испортят историю.
Это слишком большой холивар merge vs rebase.
Я лишь сказал что можно это сделать легко без последствий, даже если работаешь группой в одной ветке.
Зачем надо или зачем не надо, это другой вопрос.
Извините, но капитанская статья… Очень хочется увидеть примеров вышеописаных действий. Вот допустим я нагадил накомитил в мастер, опомнился, захотел вынести в ветку — а не тут то было, пуш уже сделан.
Допустим вариант с анпабликом ветки, исправления косяков, и обратный паблик. Просто я не особо много в команде успел поработать, но думаю что в команде просто так в мастер не покомитишь, а в своей ветке сколько угодно можешь исправлять. Или я не прав?
В таких случаях лучше сделать git revert, я думаю. Хотя еще лучше в своей ветке работать, тогда таких ситуаций возникать не должно.
Кстати хорошая идея статьи для хабра — «Что делать, если вы нагадилинакоммитили в мастер».
В разделе мана про теги есть фраза о том, как переименовать тег: "Just admit you screwed up, and use a different name."
Думаю, эта статья должна начинаться так же.
«Just admit you screwed up, and use a different job
А самое интересное начинается, когда начинаются конфликты.

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

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

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

достаточно одной команды:
git commit -a --amend
Я бы порекомендовал вменяемый gui-клиент типа git extensions, где можно неспеша посмотреть на изменения, добавить и закоммитить без использования консоли. Гитом можно эффективно пользоваться из UI клиента.
Я обычно пользуюсь tig (git ncurses frontend). Добротный консольный клиент с хорошим текстовым gui (tui).

Хотя большую часть действий я выполняю из командной строки. Tig, в основном, используется для быстрой навигации по изменениям.
разница есть, git add. имеет локальную область действия, начиная от текущего каталога, плюсом добавит untracked, если есть
git commit -a предложит закоммитить только измененые по всему реапозиторию, вне зависимости от относительного пути
Хорошее правило, — не использовать git commit -a или git add .. Чтобы лишнего не коммитить, лучше указывать список файлов явно. Если ветка своя, то можно так и не париться.
Я люблю использовать git add -p, реже git add -i. Заодно и беглый обзор изменений.
А у нас git add -p — это категорическое требование к разработчикам :)
Прошелся по хабу GIT, и к своему удивлению заметил, что мало статей собственно о теме.
На счет данного поста — всегда обходился soft reset-ом, но это явно лучше, практически ничего не меняя (не убивая существующих коммитов) делаешь маленькие правки. И вроде знал о такой возможности, но руки не доходили почитать мануал. Спасибо автору, занес в избранное.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.