Comments 12
Спасибо, полезная статья
+2
Радует не только содержание, но и приличное качество перевода. В последнее время многие не утруждают себя даже слегка облагораживать текст после прогона через «гуглтранслейт»!
+6
Вот вроде 2020 год, насколько вообще продуктивно использовать эти команды? Есть уже пару отличных клиентов, почему бы не рассматривать их(Fork как я понинимаю лидер, но он стал платным, GitHub desktop для гитхаба )
0
Какой-то клиент умеет в $ git rebase -i --exec «yarn test» d294ae9
Опять же, не все описные настройки вынесены в «preferences» клиента. lost-found вроде тоже не встречал.
Сначала хотел сказать, что статья вообще не о командах, которые может выполнить любой GUI клиент, но кажется каждый видит то, что он хочет. Пересмотрел -действительно значительная часть статьи о них.
Опять же, не все описные настройки вынесены в «preferences» клиента. lost-found вроде тоже не встречал.
Сначала хотел сказать, что статья вообще не о командах, которые может выполнить любой GUI клиент, но кажется каждый видит то, что он хочет. Пересмотрел -действительно значительная часть статьи о них.
0
Насколько я понимаю основной рекомендацией работы с системой контроля версий и стратегий бранчей является — выбрать самый простой вариант, и усложнять его только если это действительно нужно проекту. Если вы в этой стадии усложнения дошли до команд которые не поддерживаются популярными клиентами, то может быть надо остановиться и пересмотреть стратегию?
0
Не раз наблюдал такую картину:
Разработчик пользуется клиентом. Все идет вроде бы хорошо, всем удобно.
Но тут что-то случается. Причем то, чего он не понимает.
Начинает гуглить по ключевым словам. а все решения предлагается делать в консоли.
И он уже сидит с больной головой, потому что то, что он видит в клиенте не совсем такое же, как в консоли.
Хороший разработчик после этого пойдет и начнет читать 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
дают больше понимания, чем красивые кружочки в клиентах.
Конечно тут еще играет роль элементарная привычка, но думаю, что в меньшей степени.
Разработчик пользуется клиентом. Все идет вроде бы хорошо, всем удобно.
Но тут что-то случается. Причем то, чего он не понимает.
Начинает гуглить по ключевым словам. а все решения предлагается делать в консоли.
И он уже сидит с больной головой, потому что то, что он видит в клиенте не совсем такое же, как в консоли.
Хороший разработчик после этого пойдет и начнет читать 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
дают больше понимания, чем красивые кружочки в клиентах.
Конечно тут еще играет роль элементарная привычка, но думаю, что в меньшей степени.
0
Я что-то не понял зачем разработчику вообще что-то гуглить. Флоу кода(какие бранчи использовать, куда коммитить, что делать с кодом который надо отложить и пр..) и все возможные варианты вообще должны описаны до начала кодирования и согласованы внутри команды. В каком случае то понадобиться что-то гуглить? все ж должны работать одинаково.
-1
Гуглить придется тогда, когда произойдет что-то нештатное.
Например сделал commit, а потом понял, что находится не в той ветке.
Начал пытаться исправлять, что-то пошло не так, и понял, что этот commit вообще теперь нигде не виден.
Идти и разбираться с такой ситуацией не получится имея только github desktop.
Придется залезть в команды.
Чтобы залезть в команды и не наделать еще больше проблем — нужно изучать git.
А изучив git, клиент становится менее понятным, чем команды. Я ровно об этом.
Клиент нужен в тех случаях, когда изучение git — лишнее.
Например у нас несколько аналитиков правят файлы в проекте. У них стоит клиент и я показал, что после изменений, нужно нажать вот сюда и вот сюда.
Но им и не нужно разбираться в этом на столько глубоко.
Например сделал commit, а потом понял, что находится не в той ветке.
Начал пытаться исправлять, что-то пошло не так, и понял, что этот commit вообще теперь нигде не виден.
Идти и разбираться с такой ситуацией не получится имея только github desktop.
Придется залезть в команды.
Чтобы залезть в команды и не наделать еще больше проблем — нужно изучать git.
А изучив git, клиент становится менее понятным, чем команды. Я ровно об этом.
Клиент нужен в тех случаях, когда изучение git — лишнее.
Например у нас несколько аналитиков правят файлы в проекте. У них стоит клиент и я показал, что после изменений, нужно нажать вот сюда и вот сюда.
Но им и не нужно разбираться в этом на столько глубоко.
+1
Спасибо большое. У себя подняли Git сервер для внешних разработчиков. Руководство сразу поставило ряд вопросов по организации взаимодействия и контроля. Сочинять ничего не буду, просто покажу эту статью.
0
Спасибо за статью. По-тихоньку буду ознакамливаться :)
0
К пунктам про gitconfig хочется добавить, что все-таки можно переиспользовать конфиг между разработчиками
Для этого нужно положить конфиг-файл(с актуальными для проекта настройками) в репозиторий
И потом после клонирования, подключить его командой
Теперь достаточно только одной команды, вместо отдельных, для каждой настройки
Кроме того, если понадобится добавить еще одну настройку, достаточно будет закомитить ее в этот файл, а не рассылать уведомления с просьбой выполнить очередную команду всем участникам разработки
Для этого нужно положить конфиг-файл(с актуальными для проекта настройками) в репозиторий
И потом после клонирования, подключить его командой
git config --local include.path "../.gitconfig"
Теперь достаточно только одной команды, вместо отдельных, для каждой настройки
Кроме того, если понадобится добавить еще одну настройку, достаточно будет закомитить ее в этот файл, а не рассылать уведомления с просьбой выполнить очередную команду всем участникам разработки
+1
Sign up to leave a comment.
Как облегчить себе жизнь при использовании Git (а также подборка материалов для глубокого погружения)