Comments 15
Мне вот это форматирование логов понравилось
https://habr.com/ru/articles/886538/#comment_27985468
ИМХО, git rebase лучше стараться избегать, практически всегда можно обойтись без переписывания истории, а если уж очень понадобилось это, то сделать временную новую ветку на текущем коммите: если что-то пойдет не так, к ней можно будет всегда легко вернуться.
Просмотр истории/веток/диффов и прочего все-таки сильно удобнее через UI, вроде Git Graph плагина к VS Code, в результате я из консоли использую только следующее, остальное через UI:
git init/clone
git commit
git push/pull/fetch
git remote
git reset/abort
git checkout - только на больших репозиториях с множеством веток когда вдруг надо перкключится на какую-то старую ветку до которой долго листать UI, обычно между ветками нагляднее через UI переключаться.
Кстати, в статье не хватает git blame - оно нужно чтоб найти кто изменения сделал, хотя опять-же, оно удобнее в UI смотреть.
Интересно, с чем именно несогласны минусующие люди: с тем, что переписывание истории лучше стараться избегать, с тем, что с git какие-то вещи, удобнее делать через UI, или с тем, что git blame очень полезная вещь на больших проектах надо которыми работает много людей?
Не знаю как остальные, но почему поставил минус я:
git rebase лучше стараться избегать, практически всегда можно обойтись без переписывания истории
rebase не про переписывание истории, это только одна из возможностей
Просмотр истории/веток/диффов и прочего все-таки сильно удобнее через UI, вроде Git Graph плагина к VS Code
это вкусовщина которая мне "не отзывается", единственное что мне удобнее делать в UI это разрешение конфликтов
git checkout - только на больших репозиториях с множеством веток когда вдруг надо перкключится на какую-то старую ветку до которой долго листать UI, обычно между ветками нагляднее через UI переключаться
снова вкусовщина - имхо, автодополнение и fzf в консоли удобнее, чем глазами искать имя ветки, + вместо checkout рекомендуется switch
в статье не хватает git blame - оно нужно чтоб найти кто изменения сделал
с этим согласен; вообще многого в статье не хватает, например флага --patch для add/restore, но для заголовка "Основные" - пойдет
rebase не про переписывание истории, это только одна из возможностей
Угу, понятно, что ее назначение другое, вот только под капотом у нее переписывание истории, хорошо если только локальной. Самая большая головная боль, когда делаешь rebase по ветке, где есть активные изменения в файлах, которые меняются твоей веткой, приходится разруливать конфликты чуть ли ни на каждом коммите. Лично для меня мерж удобнее и безопаснее: в случае конфликтов, разруливаешь их не на каждом коммите, а с итоговой текущей версией. Я понимаю, что кому-то ребейз милее, поэтому и написал в самом начале большими буквами ИМХО.
это вкусовщина которая мне "не отзывается", единственное что мне удобнее делать в UI это разрешение конфликтов
Угу, можно просто сделать status и затем add всего сразу, но у меня выработалась привычка перед тем как добавлять файл - проверять изменения в этом файле, не раз спасало когда что-нибудь закомментишь или сделаешь шорткат для теста и забудешь убрать. Ну как-бы да, вкусовщина, кому-то норм диффы в консоли смотреть, мне удобнее в UI.
Лично для меня мерж удобнее и безопаснее: в случае конфликтов, разруливаешь их не на каждом коммите, а с итоговой текущей версией.
Это если squash включен, + есть rerere
можно просто сделать status и затем add всего сразу, но у меня выработалась привычка перед тем как добавлять файл - проверять изменения в этом файле
перед add всегда делаю diff ровно с той же целью, + примерно в половине случаев add с флагом --patch
Спасибо, что подробно и с примерами
Очень классная, подробная статья!
Я бы в самом начале добавил два абзаца:
1) инфа о том, чем принципиально отличается git от многих других аналогов, существовавших до него, и почему (именно поэтому) он стал стандартом де-факто в больших проектах.
2) замечание о том, что синтаксис многих команд Git не симметричен (как сказал бы физик теории поля), или не согласован. То есть, зная одну команду, часто совершенно невозможно предсказать, как выглядит похожая команда. Поэтому команды надо просто выучить. Причина несогласованности? Git писали ну очень гикнутые гики)
Я недавно проходил собес и завалил его, вопрос комментаторам: часто ли вы используете git reflog?
Я саму консоль гита открываю тогда, когда уже что-то сломали. В IDE все повседневные функции для работы реализованы.
Знаю, что он существует, но за 10+ лет с Git ни разу не использовал. Вот сейчас (почти) первый раз в жизни запустил, чтобы посмотреть на отличия от git log. Ничего полезного для моих убогих нужд не увидел.
Основные команды GIT