Comments
Частые коммиты логически разделяют добавленную функциональность и позволяют откатывать отдельные ее части при необходимости. Однако нет никакой необходимости пушить каждый коммит на сервер: единственное, к чему это приведет – засорение истории изменений. Пушьте только тогда, когда ваша фича готова

А разве после пуша пачки коммитов, они каким то магическим образом будут сгруппированы?
Наверное, имеется в виду локальный rebase со squash коммитов в один.
Возможно, только вот коммиты все равно должны быть пачкой. Лучше уж сразу применять модель: функция = ветка.
Из коробки нету такого поведения.
Долго искал грамотное решение, так как считаю rebase опасным в неопытных руках.
Я откатываюсь на коммит, в котором рабочая ветка была создана, делаю новую ветку для мержа с мастером в этом месте и пишу
git merge --squash 1234567
С этой командой все изменения можно будет как один коммит добавить.
С одной стороны всё это можно узнав, прочитав официальную документацию.
С другой стороны, каждый раз лезть в документацию неохота.

Мне кажется лучшим решением было бы дополнительно к статье создать cheat sheet (на cheatography по git уже есть, но того, что описано в статье, там нет).
Практически все 8 советов можно прочитать чуть ли не на первой страничке официальной документации по GIT.
https://git-scm.com/doc

Например Git cheat sheet: https://services.github.com/kit/downloads/github-git-cheat-sheet.pdf
Теперь можно переключиться на другую ветку для внесения срочных изменений

Рекомендую использовать для этих целей worktree. Это куда удобнее бесконечных stash → checkout → checkout → stash pop. Единственное что GUI клиенты ещё не научились с этим корректно работать. SmartGit и gitg по крайней мере.

IDEA относительно недавно умеет worktree, и очень давно — «smart checkout» (stash → checkout → stash pop)

Чего действительно мне не хватает в stash — это возможности применять его к конкретным файлам, а в идеале — к частям файла, наподобие git add $filename -p.
Сейчас приходится извращаться через коммит и его резет. Никто случайно не знает нормального пути?

Через консоль наверно такого нет, а вот SourceTree умеет частитчно патчить файлы из stash

Можно пользоваться git stash -p, правда, без указания имени файла, придется отбирать изменения через все файлы.

Помогло, спасибо! И не думал, что такая штука есть, если пофайлового сташа нет.

Еще можно добавить в индекс то, что не должно в stash попасть:


git add files/to/not/stash
git stash --keep-index
Писать алиасы для однословных комманд так себе план — автодополнение же есть. А вот для чего-нибудь вроде submodule update --init --checkout или rebase master --autostash уже намного более реалистично
Для checkout так себе автодополнение — там есть команда check, которая подставляется первой, поэтому co гораздо удобнее.
А еще более эффективная работа (если вы под виндой) — использование TortoiseGit, чтобы не страдать с командной строкой.
Не соглашусь с вами:
  • GUI реализует не все возможности командной строки.
  • Работа с командной строкой — не страдание, если ты знаешь, что делаешь. Кроме того, есть штуки типо Oh-My-Zsh, которые делают процесс работы в командной строке еще более удобным.
  • Если говорить о разработке, GUI-интерфейсы интегрированы во все современные IDE.
Да, возможности может не все, но «минимально-рабочий набор» вам обеспечен. На личном опыте — мои коллеги крайне редко сидят в git в командной строке. Допустим подключается человек — технический писатель, с git ему работать надо, да его можно учить «знать что ты делаешь», но смысла нет. Конечно это дело вкуса, лично одного человека точно знаю кто любит именно командную строку, но вопрос не такой однозначный. Что используем мы: обновись, коммит, пуш, создай ветку. Мерж делают уже далеко не все — это забота тим-лида сложить все воедино. Git ведь дает много чего, когда первое время мы его внедряли — реально пугало сложностью, теперь уже все проще, но уверен что многие возможности ни я ни коллеги просто не знаем и не применяем, но и работать без них тоже можно.
Тоже пользуюсь тортиллой. В консоли удобно делать повторяющиеся действия из нескольких команд, типа checkout/pull/checkout/rebase, можно названия веток вынести в переменные, и копи-пастить весь набор команд в консоль. Или разные хитрые вещи для управления репозиторием, которых нет в GUI.
А вещи, которые требуют внимания, выбора, и работы с текстом, удобнее делать в GUI — diff файлов перед коммитом, разбиение/слияние коммитов, интерактивный rebase, разрешение конфликтов. Дело личных предпочтений, конечно, но при правильном применении GUI помогает сэкономить время.
Не знаю как в Git, но интерфейс в TortoiseHg достаточно удобен, не представляю, как выборочно коммитить части файлов из командной строки, работать с очередями заплаток и тому подобное.
TortoiseGit? Пробираться через дебри вложенных меню так себе удовольствие. Тогда уж SmartGit, хотя всё это вкусовщина.

Добрый день! Спасибо за статью!


Пробовал создавать алиасы через git config --global alias.co checkout, но они почему-то не сохраняются. И после каждого перезапуска терминала их нужно создавать заново. Поэтому использую для хранения алиасов файл ~/.bashrc. Но вариант с ~/.gitconfig тоже хорошо подходит, просто он у меня не прижился.

git pull --rebase (удобный способ подтянуть обновление, что не нужно было делать дополнительные коммиты)
git diff --staged (показать что пойдёт в коммит)
git status (показать состояния файлов: новые, изменённые, добавленные для коммита)

Only those users with full accounts are able to leave comments. Log in, please.