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