Comments 26
Используйте "-" для возврата к предыдущей веткеИ не только. Например, можно делать слияние с предыдущей веткой.
git merge -
stevelosh.com/blog/2013/04/git-koans
Над этим работают. Например, вместо части применений git checkout существуют, пока что экспериментальные, git switch для смены ветки (опционально с созданием новой) и git restore для восстановления отдельных файлов в историческое состояние.
К сожалению, часто более удобные и продуманные альтернативы не получают достаточной для выживания популярности. Меркуриал по юзабилити на порядок лучше гита, по функционалу вполне сравним с гитом, но… не судьба.
Наиболее простое решение — взять и закоммитить всё с комментарием WIP (распространённая аббревиатура от «Work In Progress»).
Этот подход настолько понравился нашей команд, что завели даже отдельные алиасы для git:
[alias]
wip="!git add . && git commit -m 'WIP'"
rewip="reset --soft HEAD^"
Очень удобно делать
git wip
git checkout <another branch>
...do something here...
git checkout -
git rewip
gunwip='git log -n 1 | grep -q -c "\-\-wip\-\-" && git reset HEAD~1'
gwip='git add -A; git rm $(git ls-files --deleted) 2> /dev/null; git commit --no-verify --no-gpg-sign -m "--wip-- [skip ci]"'
А в случае использования zsh советую глянуть на настройку Oh My Zsh и его планиг git, который содержит много интересных alias и для меня этот плагин послужил хорошей ознакомительной базой для наиболее используемых опций в командах git
В нашем случае две ветки ориентированы на разные версии Unity, 2018.4 и 2019.4. Практика показала, что если попробовать переключиться с 2018 на 2019 Editor просто будет долго думать, а при переходе с 2019 на 2018 проще удалить всю папку и зачекаутить её — иначе возникает множество глюков, не всегда заметных с первого взгляда. Дешевле в плане времени загрузки просто держать их в разных папках.
Предлагаю дополнить пункт 11 установкой msys. В итоге получаем автодополнение в консоли.
Некоторые предпочитают использовать git pull --rebase, но не всегда это возможно, например, когда вы локально смержили другую ветку из origin в master и перед пушем делаете pull (надеюсь, не надо напоминать, чем в данном случае может грозить rebase).
Сделал как раз позавчера и поздновато понял, в чём проблема :)
За что люблю git, так это за возможность всё исправить.
git config --global alias.excludegit config --global alias.sapply
git config --global alias.ignore \
'!gi() { curl -sL https://www.toptal.com/developers/gitignore/api/$@ ;}; gi'
А потом git ignore list, git ignore node,intellij > .gitignore
И голова не болит, что туда прописать )
P.S.: статье однозначный плюс!
Также в моей практике был случай, когда в рабочих репозиториях надо было пользоваться строго рабочей почтой, при этом в своих локальных репозиториях я продолжал пользоваться личной. Чтобы даже случайно нельзя было перепутать где что, я удалил user.name/email из глобального конфига, каждый раз указывая их заново в локальном, держа процесс под контролем.
Более удобно это делать так:
$ cat ~/.gitconfig
...
[user]
name = Self-Perfection
email = <Personal e-mail>
[includeIf "gitdir/i:CORPNAME/"]
path = ~/.git_identity_mycompany
$ cat ~/.git_identity_mycompany
[user]
email = CORPEMAIL
name = Alexander Mescheryakov
# vim: ft=gitconfigКак работает: если в пути к .git директории текущего репозитория есть директория с названием corpname (проверка ignore case), то инклюдится дополнительный файл, который переопределяет ранее заданные user и e-mail. Справка: https://git-scm.com/docs/git-config#_conditional_includes
В одной лодке с «ублюдком»: 11 продвинутых советов по использованию Git