How to become an author
Search
Write a publication
Pull to refresh

Comments 21

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

Ещё rebase может послужить, когда нужно поменять коммиты местами.
Total votes 3: ↑3 and ↓0+3
Interactive rebase вообще мощная штука.

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

Реже, чтобы поправить метаданные какого-нибудь коммита в середине (например, если забыл указать автора какого-нибудь патча).
Total votes 3: ↑3 and ↓0+3
Вместо рекомендуемой автором пары
git add .
git commit --amend

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

Хотя большую часть действий я выполняю из командной строки. Tig, в основном, используется для быстрой навигации по изменениям.
Total votes 2: ↑2 and ↓0+2
разница есть, git add. имеет локальную область действия, начиная от текущего каталога, плюсом добавит untracked, если есть
git commit -a предложит закоммитить только измененые по всему реапозиторию, вне зависимости от относительного пути
Total votes 2: ↑2 and ↓0+2
Хорошее правило, — не использовать git commit -a или git add .. Чтобы лишнего не коммитить, лучше указывать список файлов явно. Если ветка своя, то можно так и не париться.
This comment wasn’t rated yet0
Я люблю использовать git add -p, реже git add -i. Заодно и беглый обзор изменений.
Total votes 1: ↑1 and ↓0+1
А у нас git add -p — это категорическое требование к разработчикам :)
Total votes 2: ↑2 and ↓0+2
Прошелся по хабу GIT, и к своему удивлению заметил, что мало статей собственно о теме.
На счет данного поста — всегда обходился soft reset-ом, но это явно лучше, практически ничего не меняя (не убивая существующих коммитов) делаешь маленькие правки. И вроде знал о такой возможности, но руки не доходили почитать мануал. Спасибо автору, занес в избранное.
Total votes 1: ↑0 and ↓1-1
Sign up to leave a comment.

Articles

Show the best of all time

Your account

Sections

Information

Services

Support
© 2006–2024, Habr