Комментарии 107
Использую "VS Code" с плагином и вообще не знаю ни одной команды GIT, на все есть готовые кнопочки...
Никогда не понимал приверженость консольных команд при наличие интерактивных инструменов...
До поры до времени.
До какой поры? Если потребуется, то открывается любой из огромного числа мануалов или тот же ChatGPT.
Ну, вот например я прямо сейчас через это прохожу.
В какой-то момент я захотел выложить свои поделки на сервер, чтобы ими пользоваться. Пришлось учиться использовать systemctl, виртуальные окружения, а заодно отлаживать это на сервере.
Тут следующие стулья:
1. Сервер с графической оболочкой
2. Сервер панелью управления, где ты можешь управлять файлами и получить доступ к консоли.
Оба варианта НЕВЕРОЯТНО глючные, долгие и в какой-то момент меня достали - плюс масштаб работ стал воистину большим.
И тут я осознал, что могу из своей родной консоли подключаться по SSH.
И сразу все стало просто.
Во-первых, не нужно было копировать на сервер архив с проектом и повторять это для каждой правки - вместо этого можно просто написать git merge (или кнопку нажать), а затем git clone - и все. В первый раз еще пришлось прописать в консоли несколько команд для создания .env.
Во-вторых, если я хочу что-то скопировать на сервер, я беру и копирую. Это регулярно было большой проблемой.
Если я чего-то не знаю, например команду создания, изменения файлов в консоли, переноса папки, я просто спрашиваю у GPT. Теперь я вижу в линуксе некую системность, он и правда устроен удобно, пусть мой подкопченный тиктоком мозг не может въехать в это быстро.
для vs code есть возможность открыть проект на удаленной машине, но сам ни разу не пользовался https://code.visualstudio.com/docs/remote/ssh#:~:text=Connect to a remote host&text=In VS Code%2C select Remote,to select the type manually.
сам когда-то пользовался sshfs, чтобы локально смонтировать директорию проекта с сервера
есть web версия, например в home assistant есть такой плагин, из плюсов - доступность серверного окружения (то есть можно работать сразу в каталоге тестового проекта и тут-же смотреть результат, не нужно всю байду разворачивать локально),
но лично мне не зашло...
пробовал для синхронизации использовать на сервере команды GIT тоже не зашло
сейчас пользуюсь локально и настроил WinSCP на сравнение и синхронизацию, а гит использую исключительно как хранилище версий ну и еще немного для совместной работы над одним проектом.
GIT класная вещь например мне очень нравися как сделаны маски исключения для файлов, а вот чего мне не нравится - это то, что отсутствует блокировка файла, из за этого иногда очень сложно мержить когда доработки нескольких программистов надо устаканить в одно целое. Я конечно понимаю зачем в GIT так сделано, но реально работать внутри одной команды из за этого получается как-то криво.
я пользовался.
хост должен быть подключен к интернету. он скачает вам в домашнюю папку свой сервер, запустит его там и взаимодействие будет идти через него. это может и удобно, но совершенно не подходит для изолированных сред и/или небольших виртуальных серверов.
если Вам не нужна среда VSCode, а просто хотите красивый/удобный файловый менеджер, то можете к удалённому хосту подключить панель в Midnight Commander и работать с удалённой ФС, как с локальной.
Не знаю, насколько давно есть такая возможность, но сейчас подулючение к интернету на сервере не требуется. Лично подключался по ssh-туннелю vscode к серверу без доступа к интернету. Насколько я понял, он в состоянии скачать пакет своего сервера на клиентскую машину, передать его по ssh на сервер и установить.
Поставьте машину на FreeBSD и попробуйте повторить трюк, например.
Есть, очень удобно. Единственная проблема - запаздывание в консоли, иногда рассинхронизируется и правки в команду оболочки не туда вносит.
можно просто написать git merge (или кнопку нажать), а затем git clone - и все.
Как-то вот так?
Героически решаем решенную проблему https://code.visualstudio.com/docs/remote/ssh , два клика мышкой, один git clone и работа на удаленной машине ничем не отличается от локальной.
Так я об этом и говорил, Вы повторили мой поинт. Если потребуются консольные команды, то открывается туториал или GPT. Но в случае, когда они не нужны - проще пользоваться графическим интерфейсом. Для git я до сих пор пользуюсь SourceTree из-за удобного отображения дерева коммитов.
может вам нужен lazygit?
Странный пример, надуманный. Монитруешь удаленную папку и забот не знаешь.
Заведите репу с SHA256, например.
Что это значит?
Это значит, что используется SHA256 вместо SHA1 для формирования хэшей коммитов. Предполагается, что это заметно уменьшает вероятность создать коллизию коммитов в дереве. Но есть нюанс - поддержка такого формата практически везде отсутвует и большинство GUI (да и TUI) приложений работают с такими репозиториями из рук вон плохо.
создать коллизию коммитов в дереве
Был ли хоть один прецедент в истории человечества?
Емнип началось все с того, что в какой-то библиотеке случайно воспроизвели это. Вроде даже на хабре где-то про это статья была. Ну, сама атака воспроизводилась неоднократно, так что в теории supply chain атака может быть осуществлена за дёшево. Но сейчас атак этого класса в принципе не сказать, чтобы много, так что доподлинно вредоносного варианта вероятно пока не случалось, но я не настолько много ИБ новостей читаю.
Это быстрее чем искать кнопки
Спорно, зависит от привычек, я знаю эти команды и в целом вполне комфортно чувствую себя с гитом, но почти все делаю через idea. Просто все на горячих клавишах (правда некоторые пришлось добавить, по дефолту к примеру нету фетча и еще каких-то), дерево коммитов на виду и его можно фильтровать, в нем можно искать и т.п., плюс интерактивные ребейзы... красота. Можно мышкой накликать коммитов и сквошнуть их, можно навыделять коммитов и черрипикнуть, адекватные стеши. Можно выбрать мышкой пару коммитов и посмотреть между ними дифф, перейти из диффа в сам файл и что-то тут же отредактировать.
Да, все это можно сделать через консоль, и чаще всего это одна команда,... но вот быстрее ли.. Скорей всего и там и там можно наловчиться делать все быстро, но имхо в случае с гитом, когда визуализация реально помогает понять происходящее, графический ui на горячих клавишах очень удобен.
дерево коммитов на виду
Вот это действительно удобнее в ui, оно там наглядно. Вообще, я так безапелляционно заявил - быстрее, но зависит от человека и привычек, конечно.
Ну и я считаю, что полезно их знать. Иначе без ide ты уже ничего не можешь. Бывает, что надо на каком-нибудь удалённом рабочем столе что-то править, а что-то скачивать туда запрещено. А коммит сделать надо. Можно, конечно, нагуглить, нажыпытить и т.д. Лучше уметь, чем не уметь, короче говоря)
А мне ещё никто не смог показать как решать конфликты слияния через консоль за адекватное время. Когда над одним проектом работает более 2 человек нужен обзор дерева, который в любом gui выглядит лучше чем в консоли. При разборе ошибок и поиске виноватого быстрее в гуй, чем лупиться в двухцветную консоль после blame. Вся эта быстрота хороша для повседневных мелких операций.
Решение конфилктов к командам git не имеет никакого отношения)
В консольном git шикарные интерактивные команды:
- git mergetool
- git difftool
- git add -i
- git commit
Главное настроить любимый редактор - vim, emacs и т.д.
С помощью git mergetool + vim можно очень легко решить конфликты слияния в терминале.
чем искать кнопки
особенно когда их всё время перемещают/переименовывают/перекрашивают или, ещё хуже, меняют алгоритм их действий.
Использую кастомные алиасы уже лет 15
Никогда не понимал приверженность интерактивным инструментам при наличии консольных команд ¯_(ツ)_/¯
На вкус и цвет все фломастеры разные.
Для этого и делают разные инструменты, так как каждому удобнее по разному, это неплохо, разные подходы, разное виденье порождает разные идеи.
Для difftool что используете? Есть ли что-то лучше древнего Araxis Merge 6.5?
Конфликты при rebase всё же удобнее интерактивно разрешать.
Арахис не пробовал, в винде для решения конфликтов использую WinMerge, в линуксе - почти полный аналог ее Meld. В отличии от арахиса, и то и другое бесплатное.
Они же используются и как расширения файловых менеджеров для сравнения файлов.
Для работы с гитом под виндой - GitExtensions - все очень удобно - история, ветки, коммиты, теги - все видно сразу. Под линуксом - GittyUp. Не так удобно, но GitExtensions под линукс нет...
difftool — Meld, mergetool — KDiff3
Оставлю-ка коммент в поддержку этого комментария. Расстраивает, что на хабре, как на пикабу, банят немейнстримное мнение.
Если немного подумать, то никто не обязан использовать то, что лично ему не нужно, ради абстрактных знаний.
Мы, как инженеры, используем то, что работает, так, как нам это нужно, а не осваиваем то, что, как известно, очень крутое, значит надо. Иначе бы все до сих пор писали перьями.
На собеседованиях часто спрашивают про git-команды.
Спрашивают те, у кого нет соответствующего сотрудника, у тех, кто безработный.
И мораль не в том, что некоторые люди не могут выучить пару команд или не умеют печатать, а в том, что они не хотят тратить время на тупой ввод нескольких слов, который можно заменить нажатием одной кнопки или клавиатурным сокращением.
Гуёвые клиенты для гита все в той или иной степени ограничены, приходится играть в игру «угадай, как авторы гуйни назвали вот эту фичу гита, куда спрятали и поддерживают ли её вообще». В качестве бонуса — регулярные редизайны с необходимостью повторения шага «куда спрятали и поддерживают ли вообще».
Из интерактивных нужны в первую очередь diff/merge и это вполне себе вызывается через CLI.
Вам нужно выполнить самое простейшее действие - закоммитить все изменения в уже имеющихся файлах. У вас есть гуйня под названием иде от жытбрейнс и, для более равного счета, можем добавлять +1 клик как переключение между ide и консолью
Итак, чтобы закоммитить я нажимаю 3 кнопки - коммит (обычно шорткатом), кнопку коммит и +1 бонусное.
Вопрос - зачем мне нужно вместо этого что-то печатать в консоли? Чтобы, если вдруг что и в иде поменяется интерфейс я был готов к любым неприятностям?
Пуш это еще одно действие. Из консоли тоже не сложно запушить - ну буквально 8 символов и ентер нажать. Но зачем? Вам за это медаль дадут©? вымпел? скидку на болгенос?
Вам за это медаль дадут©? вымпел?
Нам за это дадут консольный автокомплит и отсутствие временных затрат на переключение боковой вкладки
Для кого-то дело не в скорости, а в комфорте.
Мне вот банально лень возюкать мышкой. Отсутствие раздражающих моментов в работе того стоит.
Так что, да, сам себе медаль выдаю.
Но это мой личный опыт, вам следовать ему совсем не обязательно.
Ну вы тоже молодец. Жаль не заметили, на какой коммент я отвечал и что в нем написано. Давайте зацитирую, чтобы не искали
Гуёвые клиенты для гита все в той или иной степени ограничены, приходится играть в игру «угадай, как авторы гуйни назвали вот эту фичу гита, куда спрятали и поддерживают ли её вообще». В качестве бонуса — регулярные редизайны с необходимостью повторения шага «куда спрятали и поддерживают ли вообще».
Вим программистам что-то советовать я, пожалуй, не буду - без меня справятся.
Полностью согласен - мышка в ide не нужна -тдва хоткея - один для открытия окна коммита, другой - для коммит+пуш
Можно сразу коммитить с пушем в идее. Те прям вообще только одно действие. И оно на хот кее.
а если еще и аддон gitlens поставить...
Там нет интерактивного ребейза (git rebase -i)
и в PyCharm/IDEA нету. Вместо них есть squash commits и drop commit произвольных выбранных коммитов прямо из дерева, с редактированием результирующего коммитмесседжа. То есть, львиная доля тех самых действий, для которых этот интерактивный ребейз и нужен, через него под капотом и выполняемая, только даже проще. "Причесать" ветку перед пушем с помощью этих действий - более чем достаточно. Разделить одну исходную на несколько разных тоже.
А вот переставлять коммиты местами через этот GUI нельзя, да. Тут только консоль.
Лучше знать консольные команды git'a иначе есть риск в ответственный момент тупо не выполнить самые примитивные вещи: пуш, пулл, клон и прочее. И это база. Это как решать алгебраические уравнения, не зная базовых арифметических операции сложения, вычитания, умножения и деления. Да, интерфейсы и юзер френдли гуи есть, но выше уже писали, что ситуации бывают разные, да и не просто же системные админы и люди из техподдержки сидят например на удалённых ВМ по SSH, а не через какую-то графическую оболочку, да и сами сервера убунты например без графики. Почему? Да потому что тупо удобно сразу вбивать команды в консоль, а не искать по 100 кнопок куда и как жать. Это сначала кажется неудобным текстовый формат, потом когда привыкаешь, делаешь под себя алиасы и прочее, уже сложно отказаться от консольки родной :)
А как же консоль при работе на удалённом сервере - спулиться, резетнуть, почистить лишнее?
Если это тестовые сервера, то там программеры, кто на vscode, разворачивают vscode backend, и работают как у себя на машине, и с консолью обычно не сталкиваются. Если это продовые сервера, то простых программеров туда никто не пустит, и опять же с консолью они опять не сталкиваются. Так что для начинающих взаимодействие с консолью это скорее личный выбор: кто-то упорно остается в IDE, кто-то осваивает консоль, из-под палки никого никуда не загоняют.
Но личный опыт говорит о том, что IDE для начинающих все же предпочтительнее: сначала стоит сосредоточиться непосредственно на самом коде и управлением им, а уже потом можно расширять свой набор инструментов, осваивая что-то за пределами IDE. Потому что начинающие программеры, которые пытаются сразу работать с голым git, совершают слишком много ошибок, и ловят сильную демотивацию, иногда публично.
Например довольно распространенные ошибки: заливают лишнее или забывают заливать необходимое, заливают конфликты в промежуточном состоянии, разрушая код, заливают код с грубыми синтаксическими ошибками, т.е. вообще неспособный к компиляции/запуску код, случайно заливают массовые удаления тысяч файлов, а то и всего кода проекта, даже такие случаи в практике были, и неоднократно.
Все эти ошибки - детские, грубые, легко обнаружимые и легко исправляемые, но при наличии хотя бы минимального опыта, которого у начинающих просто нет.
Консоль требует больше понимания, ответственности и внимательности, чем IDE, в консоли нет AST-анализаторов, которые в IDЕ на такое сразу пнут красными метками, нет удобного и наглядного представления, и, откровенно говоря, многих консоль пугает, она сыпет непонятными ошибками на неродном языке, что приводит к панике, а если в спешке, то и к дополнительным, более грубым, ошибкам.
Конечно на стороне инфраструктуры от таких ошибок можно защититься, но это встречается на хорошо развитой инфраструктуре: перед принятием правок в git, код должен пройти валидацию автоматическими проверками на хуках, а после еще и пройти через пайплайны CI/CD, успешно пройти тесты.
Но до сих пор много где есть только голый git с ненастроенными хуками и отсутствующим ci/cd, и без каких-либо тестов. В таких окружениях программера автоматика не подстраховывает, а потому эти ошибки неизбежно вскрываются, и все внутри команды видят их, и отлично понимают, кто именно из них так начудил. И тот, кто начудил, тоже отлично понимает, что остальные отлично видят его факап, и иногда начинает накручивать себя, загоняться, со всеми вытекающими.
В итоге эти ошибки могут дорого стоить, в первую очередь воздействуя на саму команду, на ее мотивацию. После таких факапов, программер не просто обжигается, но и понимает что теряет репутацию в глазах коллег и руководства, получает негатив, демотивацию. Усиливает ее тот факт, что даже у менее опытных коллег, которые работают в IDE, таких ошибок не возникает: их подстраховывает IDE, ярко указывая на наличие проблемы, и иногда даже предлагая автоисправление.
Чтобы пройти дальше по карьере, важно уметь этот негатив в себе подавлять: нужно держать в уме, что все мы люди, все мы человеки, все мы ошибаемся, это неизбежно. Неизбежно, но это все равно неприятно, а работать с этим мало кто умеет. Многие не дают себе права на ошибку, принимают близко к сердцу, чего делать нельзя. Иногда некоторые не дают права на ошибку не только себе, но и другим - начинают охоту на ведьм, чего делать категорически нельзя: ошибиться может каждый, обвинения не принесут пользы, только усилят демотивацию. Иногда такие ошибки даже приводят к импульсивному уходу из профессии, что вообще абсурд - нельзя получить опыт, не набив шишек. Но факт есть факт: немногие способны адекватно воспринимать свои факапы и работать над собой. Особенно больно это бьет по психике и мотивации именно начинающих. Поэтому лучше уж начинать с IDE, а уже потом осваивать консоль и git, когда будет больше опыта, понимания и уверенности.
Консоль выручает там, где нет доступа к другим инструментам. Но начинающим разработчикам о таком можно даже не задумываться - такое они встретят не скоро, а может и никогда, сильно зависит от фирмы и организации производственных процессов в ней. Будет потребность - будет и опыт, переживать об этом заранее не стоит. Тем более ничего виртуозного на практике от git в таких кейсах не требуется: всякие конфликты решаются заранее, в удобном окружении, в GUI/IDE, а вручную остается только ветку переключить на нужную. В консоли процесс может облегчить tui, но, как правило, там, где нет доступа к инструментам, нет и tui - только голый git, и это в лучшем случае.
Кто плотно работает с нативным ssh, тем тоже зайдет именно голый git: ssh позволяет со временем подстроить рабочий процесс под себя, автоматизировать всю рутину, написать конфиги и сценарии, и выполнять код удаленно, в том числе через разные гейты, прокси и vpn, одной простой командой-псевдонимом. И все это великолепие очень доступно, доступнее любой IDE, буквально под кончиками пальцев, прямо в системном шелле: нажал f12 или ctrl+alt+t, набрал 2-3 буквы, tab, enter, и нужная автоматика пришла в движение, инициировав какие-то процессы на нужном тебе сервере.
Если серверов много, у каждого свои реалии, и все это завязано на тебе - самое то. Конечно можно и на стороне сервера это автоматизировать, но это значительно сложнее: таких полномочий у разработчиков обычно нет, нужно подключать бюрократию, админов, раскатывать ci/cd - в общем людей тут задействуется гораздо больше, добро на это получить значительно сложнее, и, не смотря на то, что это корректнее и эффективнее, выгоднее бизнесу, бизнес-решения штука довольно нелогичная, на практике такое доступно далеко не всегда, а родной ssh под рукой всегда, служит тебе верно, быстро и надежно, и ни от кого, кроме тебя, не зависит.
аналогично. Пользуюсь кнопками в идее. Но если приходится черипикать или ресетить, то делаю через консольку.
Ci/CD тоже через кнопочки реализован?
Git cherry-pick не вариант для 16 команды ?
При огромном опыте работы с Гит, использовал cherry-pick один раз в жизни.
На прошлой работе каждый день делал, через ui, но всё же. Он позволяет грамотно синхронизировать файлы, коме мёрджа.
Тащу свой форк хромиума, без cherry-pick не вариант апать версию. Но там своя кухня, у гуглеров вообще свой слой на гит намазан.
постоянно пользуюсь.
особенно важно при одновременной работе для вкатывания хотфиксов.
Зависит от flow)) Любой крупный долгоживущий проект работающий по trunk based development черри-пикает патчи с завидной регулярностью.
Обычно используему cherry-pick, чтобы пробрасывать фиксы в прошлые релизы. К примеру, исправили багу в текущем релизе, но просят пробросить еще в прошлый релиз - тут как раз эта команда и нужна.
Я и так и так использую, по времени разница не значительная. В Пайчарме плохая поддержка прекомит хуков, когда нужно пропустить хуки разок, то тогда в консоль.
открыл для себя не так давно магию git worktree. как бы теперь закрыть обратно - такой бардак развел)))
У меня большинство проектов без компиляции, я так и не начал пользоваться.
git worktree prune
Nah :)
export REMOTE=$(git config --get remote.origin.url) && \
cd .. && rm -rf repo && git clone $REMOTE && cd -ага. только надо все влить что в парраллель делается и обратно развидеть worktree. чтобы не плодить сущностей)
Я чисто под задачу создаю и после завершения тут же сношу, оставляя только основную рабочую ветку, ибо нафиг :)
сидел первое время на гигттортосе, казалось удобным
на новой работе делаю всё через консольку, первые пару недель плевался, плакал, страдал
теперь привык и для тех задач,(клоне,свич,коммит,ребасе,пуше,форсе,логе) вполне достаточно консольки,а главное, все быстро. тыр-тыр-тыр и дело в шляпе. ещё и если какие ошибки, на убунту консолька сама тебе скажет, в чем проблема - в общем, удобненько
Я 95% работы делаю через консоль. Основная часть функционала гита обычно в IDE есть. Пользуюсь только для создания коммитов, написания к ним сообщений, и для diff. Остальное через консоль. Когда приходится писать на разных языках, то используешь разные IDE, а в разных IDE основной функционал гита работает по разному.
Например такой кейс - пушиш, идёшь на гитлаб, смотришь, а изменений нет. А где? А оно не запушилось. Разбираешься - IDE не даёт запушить, если не компилится. Зачем пушить то, что не компилится? Например если проект содержит подмодули и фича требует изменений сразу в нескольких. Закоммитив модуль, код которого опирается на другой модуль ещё не закомиченный, CICD начинает ругаться. Мне такое поведение IDE не нравится - если я сказал пуш, то пуш. Могу понять если будет ошибка - например, нет origin ветки. Это приемлимо - ошибка гита на уровне гита. Но когда "ошибка" кода влияет на функциональность гита, то это уже что-то не здоровое, потому что это разные уровни. Не хочу что бы IDE за меня такое решала. Да, наверное это настраивается. Но я не хочу каждую IDE брать и настраивать. Я хочу 1 раз изучить инструмент, что бы он был понятен и без приколов, и пользоваться им не задумываясь о различиях
Есть конечно какие-то отдельные графические надстройки над гитом, которые упрощают работу - ими не пользуюсь, потому что считаю избыточным что-то ставить, когда уже есть гит, который достаточно 1 раз изучить для работы и не ставить каких-то лишних прог
git rev-parse HEAD - получить хеш текущего коммита
5 гит команд покрывают 100% случаев у меня
Самое забавное - большая часть разрабов сидит в средах вроде JetBrains и поэтому они с консольным гитом могут не встречаться вообще никак.
Не хватает:
git config --global user.name "Your Name"
git config --global user.email your@email.com
git config credential.helper 'cache --timeout=3600'
git clean -d -x -n
git clean -d -x -f
git reflog - как самый простой путь починить случайно разрушенное )
В разделе про git clone, да и в других командах, нужно отдельно разобрать свитч --recurse-submodules, иначе эта команда может привести к не совсем ожидаемым последствиям, либо придётся всё удалять и скачивать заново
А что, есть какие-то другие команды?
Думаю к git rebase стоит хотя бы маленьким шрифтом дописать, что не надо так делать с уже опубликованными ветками, которыми могут воспользоваться другие люди :) а то потом из ваших волос попавшие под это коллеги сделают куклу вуду и будут кидать туда дротики на досуге
Плохой совет. Правильный совет - если пользуетесь централизованным хостингом, настраивайте там protected branches. Расчитывать на то, что никто никогда не ошибётся - безумие.
А это может быть и не защищённая ветка, а, скажем, ветка фичи в работе. Кто-то дорабатывает одно, другой на ней же пробует свой(совместимость какую настраивает, фиксы проверяте/адаптирует). И вот тут возможны проблемы, если первый сильно отличающийся ребейз запушит.
Проблемы те решаемые, хоть из консоли, хоть из gui, но требуют понимать что именно происходит, почему, и как сделать новую версию своей подветки.
Счатсливый человек писал статью, раз не вспомнил про `git reflog`)
Мне интересно, для кого эта статья и почему она набрала плюсы? Не поймите меня неправильно, я console-only пользователь гита. Просто здесь перечислены самые очевидные и популярные команды, которые консольные пользователи знают и без вас, а антиконсольные — ну, вы сами видите, что с ними, им это совершенно не нужно
Использую в git только базовые команды, узнал про команду switch.
9 цифровых клавиш на клавиатуре, которые покрывают 90 % набора всех цифр:
1 печатает единицу
2 похож на лебедя
3 удовлетворительно
4 хорошо
5 отлично
7 счастливое число
8 похоже на снеговика, кстати, вот ссылка на мой телеграм
9 без комментариев
0 ничего
Вот про git switch можно было бы и поподробнее, я по-старинке использую checkout.
15 команд Git, которые покрывают 90% повседневной работы разработчика