Комментарии 25
Частые коммиты логически разделяют добавленную функциональность и позволяют откатывать отдельные ее части при необходимости. Однако нет никакой необходимости пушить каждый коммит на сервер: единственное, к чему это приведет – засорение истории изменений. Пушьте только тогда, когда ваша фича готова
А разве после пуша пачки коммитов, они каким то магическим образом будут сгруппированы?
Долго искал грамотное решение, так как считаю rebase опасным в неопытных руках.
Я откатываюсь на коммит, в котором рабочая ветка была создана, делаю новую ветку для мержа с мастером в этом месте и пишу
git merge --squash 1234567
С этой командой все изменения можно будет как один коммит добавить.С другой стороны, каждый раз лезть в документацию неохота.
Мне кажется лучшим решением было бы дополнительно к статье создать cheat sheet (на cheatography по git уже есть, но того, что описано в статье, там нет).
Теперь можно переключиться на другую ветку для внесения срочных изменений
Рекомендую использовать для этих целей worktree. Это куда удобнее бесконечных stash → checkout → checkout → stash pop. Единственное что GUI клиенты ещё не научились с этим корректно работать. SmartGit и gitg по крайней мере.
Чего действительно мне не хватает в stash — это возможности применять его к конкретным файлам, а в идеале — к частям файла, наподобие git add $filename -p
.
Сейчас приходится извращаться через коммит и его резет. Никто случайно не знает нормального пути?
Вроде git stash --patch
будет эквивалентно add <file> -p
, нет?
Можно пользоваться git stash -p
, правда, без указания имени файла, придется отбирать изменения через все файлы.
Еще можно добавить в индекс то, что не должно в stash попасть:
git add files/to/not/stash
git stash --keep-index
- GUI реализует не все возможности командной строки.
- Работа с командной строкой — не страдание, если ты знаешь, что делаешь. Кроме того, есть штуки типо Oh-My-Zsh, которые делают процесс работы в командной строке еще более удобным.
- Если говорить о разработке, GUI-интерфейсы интегрированы во все современные IDE.
А вещи, которые требуют внимания, выбора, и работы с текстом, удобнее делать в GUI — diff файлов перед коммитом, разбиение/слияние коммитов, интерактивный rebase, разрешение конфликтов. Дело личных предпочтений, конечно, но при правильном применении GUI помогает сэкономить время.
Добрый день! Спасибо за статью!
Пробовал создавать алиасы через git config --global alias.co checkout
, но они почему-то не сохраняются. И после каждого перезапуска терминала их нужно создавать заново. Поэтому использую для хранения алиасов файл ~/.bashrc
. Но вариант с ~/.gitconfig
тоже хорошо подходит, просто он у меня не прижился.
git diff --staged (показать что пойдёт в коммит)
git status (показать состояния файлов: новые, изменённые, добавленные для коммита)
8 советов для более эффективной работы с Git