Как стать автором
Обновить

Как облегчить себе жизнь при использовании Git (а также подборка материалов для глубокого погружения)

Время на прочтение 13 мин
Количество просмотров 34K
Всего голосов 64: ↑63 и ↓1 +62
Комментарии 12

Комментарии 12

Спасибо, полезная статья
Радует не только содержание, но и приличное качество перевода. В последнее время многие не утруждают себя даже слегка облагораживать текст после прогона через «гуглтранслейт»!
Вот вроде 2020 год, насколько вообще продуктивно использовать эти команды? Есть уже пару отличных клиентов, почему бы не рассматривать их(Fork как я понинимаю лидер, но он стал платным, GitHub desktop для гитхаба )
Какой-то клиент умеет в $ git rebase -i --exec «yarn test» d294ae9
Опять же, не все описные настройки вынесены в «preferences» клиента. lost-found вроде тоже не встречал.

Сначала хотел сказать, что статья вообще не о командах, которые может выполнить любой GUI клиент, но кажется каждый видит то, что он хочет. Пересмотрел -действительно значительная часть статьи о них.
Насколько я понимаю основной рекомендацией работы с системой контроля версий и стратегий бранчей является — выбрать самый простой вариант, и усложнять его только если это действительно нужно проекту. Если вы в этой стадии усложнения дошли до команд которые не поддерживаются популярными клиентами, то может быть надо остановиться и пересмотреть стратегию?
Не раз наблюдал такую картину:
Разработчик пользуется клиентом. Все идет вроде бы хорошо, всем удобно.
Но тут что-то случается. Причем то, чего он не понимает.
Начинает гуглить по ключевым словам. а все решения предлагается делать в консоли.
И он уже сидит с больной головой, потому что то, что он видит в клиенте не совсем такое же, как в консоли.

Хороший разработчик после этого пойдет и начнет читать Pro GIT.
И после прочтения он откроет для себя великую истину, что веток то на самом деле нет, а все это только label на commit(можно заменить на любой другой пример). И только из одного этого понимания, у него многие процессы в git встанут на свои места.
И т.к. он теперь немного понимает как работает git внутри, он открывает свой клиент, видит там какую-то кнопку, и не совсем понимает, какие именно действия будут произведены по ее нажатию. Сомневается. Идет в консоль и выполняет именно те действия, что ему нужны.
Можно конечно пойти в документацию к клиенту и выяснять что там будет происходить, но получается двойная работа.

Не считаю себя супер-специалистом по git, но с командами я точно знаю что будет сделано.
Для меня вывод
git branch -avv
git remote -v
log --graph --pretty=format:'%C(red bold)%h%Creset -%C(yellow dim)%d%Creset %s %Cgreen(%cr)%Creset' --abbrev-commit --date=relative --all
дают больше понимания, чем красивые кружочки в клиентах.
Конечно тут еще играет роль элементарная привычка, но думаю, что в меньшей степени.
Я что-то не понял зачем разработчику вообще что-то гуглить. Флоу кода(какие бранчи использовать, куда коммитить, что делать с кодом который надо отложить и пр..) и все возможные варианты вообще должны описаны до начала кодирования и согласованы внутри команды. В каком случае то понадобиться что-то гуглить? все ж должны работать одинаково.
Гуглить придется тогда, когда произойдет что-то нештатное.
Например сделал commit, а потом понял, что находится не в той ветке.
Начал пытаться исправлять, что-то пошло не так, и понял, что этот commit вообще теперь нигде не виден.
Идти и разбираться с такой ситуацией не получится имея только github desktop.
Придется залезть в команды.
Чтобы залезть в команды и не наделать еще больше проблем — нужно изучать git.
А изучив git, клиент становится менее понятным, чем команды. Я ровно об этом.
Клиент нужен в тех случаях, когда изучение git — лишнее.
Например у нас несколько аналитиков правят файлы в проекте. У них стоит клиент и я показал, что после изменений, нужно нажать вот сюда и вот сюда.
Но им и не нужно разбираться в этом на столько глубоко.
Спасибо большое. У себя подняли Git сервер для внешних разработчиков. Руководство сразу поставило ряд вопросов по организации взаимодействия и контроля. Сочинять ничего не буду, просто покажу эту статью.
Спасибо за статью. По-тихоньку буду ознакамливаться :)
К пунктам про gitconfig хочется добавить, что все-таки можно переиспользовать конфиг между разработчиками
Для этого нужно положить конфиг-файл(с актуальными для проекта настройками) в репозиторий
И потом после клонирования, подключить его командой
git config --local include.path "../.gitconfig"

Теперь достаточно только одной команды, вместо отдельных, для каждой настройки
Кроме того, если понадобится добавить еще одну настройку, достаточно будет закомитить ее в этот файл, а не рассылать уведомления с просьбой выполнить очередную команду всем участникам разработки
А лучше ещё написать скрипт, который эту команду выполнит) И прописать его запуск в инструкцию по началу работы.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий