я руководствовался этой статьей при настройке терминала на mac www.freecodecamp.org/news/jazz-up-your-zsh-terminal-in-seven-steps-a-visual-guide-e81a8fd59a38/ про другие системы подсказать не могу
Создание отдельного рабочего дерева да, требует больше действий, stash в этом плане выигрывает. Но worktree можно создать один раз и больше не создавать для какой-то цели. По сути рядом будет лежать копия проекта, но слинкованная с основным. И после этого уже не надо создавать заново worktree, а просто каждый раз (будь то ревью или фикс) открывать в отдельном окне IDE ту версию и не сташить ничего. Мы на работе например пишем на go, проект достаточно разросшийся (такая увесистая монорепа), пользуемся кодогенерацией, но результаты этой генерации не пушим, и генерим отдельно. И каждый раз при переключении веток для локального запуска тестов надо заново делать генерацию, которая может занимать минуту и больше. Или же в процессе работы может быть поднят дебаг из исходного кода. Если работать тут же, а не в отдельном дереве, то надо тушить дебаг и заново потом поднимать. Но, возможно, в Вашем случае с процессами и языком который Вы используете worktree может и не дать преимуществ, тут все зависит.
@@suchkov-tech А в чём принципиальный выигрыш по сравнению с склонировать проект в отдельную папку и переключить ветку там? Если мы всё равно открываем новое окно ide. Ещё, на мой взгляд, упущено - считает ли гит новую папку, созданную через worktree, как незакомиченное изменение в оригинальной ветке.
@@ILyaCyclone я бы выделил два основных преимущества. Первое - это размер. Если клонировать отдельную копию, то занимать ровно столько же места. Если Вы пользуетесь worktree, то полная копия не создается - это все части одного репозитория. На моем рабочем примере: ``` $ du -hs api/.git 1.4G api/.git ``` и ``` $ du -hs api-worktree-hotfix/.git 4.0K api-worktree-hotfix/.git ``` разница существенная. Второе - эти две части гит репозитория знают друг о друге, в отличие от независимого клонирования. Если я подтяну свежий мастер в api, и перейду потом в api-worktree-hotfix и отбранчуюсь от мастера там - я отбранчуюсь от свежей версии мастера. То есть мне не нужно отдельно управлять и освежать основные ветки (develop и master) - достаточно сделать в одном из пространств
какой смысл во всех этих командах, если скорее всего у разработчика под рукой есть ide с уже имеющимся графическим интерфейсом через который вполне удобно можно работать с гитом? И еще интересно как команда maintenance будет работать на винде у которой нет крона
@@vovka_goodwin видимо имелся ввиду ввиду возраст. Приведу пример, в любой IDE можно посмотреть историю файла - команда такая: git log --follow /path/to/file. Но ни в одной IDE нельзя искать коммиты, которые редактировали конкретные диапазоны строк или строковые литералы: git log -L1,10 /path/to/file. По литералам: git log :"function_name" /path/to/file (кажется так). Зная эти команды (или даже написав удобный алиас на них, чтобы не превратиться в пианиста), можно быстрее искать нужные коммиты. Сойдемся на том, что терминальное гитоводство - вопрос предпочтений.)
Я частично UI пользуюсь, частично терминалом. Через UI смотрю изменения в файлах, добавляю файлы (стейджу) и имя коммита пишу. Все остальное через терминал.
возможно я не правильно был понят: команда switch обрывает выполнение операции если это может привести к потере данных. "The operation is aborted however if the operation leads to loss of local changes, unless told otherwise" git-scm.com/docs/git-switch
Хотелось бы увидеть как наиболее эффективно работать по git-flow
~~~
Спасибо за видео. Оставляйте комменты чтобы продвинуть перспективный канал!
Просто комментарий в поддержку канала, мне нравится вас слушать.
Очень хорошо объясняете, продолжайте в том же духе! Приятно слушать. Такое качество редкость для русскоязычного Ютуба.
git checkout -b branchname - сразу и создает ветку и переключается на нее. тем самым мы точно не забудем переключиться
Спасибо ❤
Можно также использовать git switch -c branch_name
Спасибо, надо будет попробывать
праймажен всегда про ворктри говорил много, но у меня так руки не доходили посмотреть. а щас узнал наконец в чем прикол
Alt + dot в терминале - можно вставлять последний аргумент предыдущей команды, и не вбивать по 10 раз feature/readme.
В маковском терминале не работает(
@@megaman13able Очень жаль, а в Аrch и в Manjaro Linux работает на ура - zsh in XFCE terminal.
Отличное видео. О worktree не знал. Спасибо.
work tree кажется полезной, часто приходится переключать контекст, нужно попробовать на досуге, спс
мене одному git кажется неудобным?
отличный контент!
Одному
Ура, новое видео
Ура
Топ
Здорово!
Спасибо 👍
Кайф, спасибо ))
❤🔥
отличное видео. го k8s пж 😊
как настроить свой терминал чтобы была такая же удобная подсветка?
я руководствовался этой статьей при настройке терминала на mac www.freecodecamp.org/news/jazz-up-your-zsh-terminal-in-seven-steps-a-visual-guide-e81a8fd59a38/
про другие системы подсказать не могу
@@suchkov-tech значит нужно Мак покупать ))))
Достаточно несложно делается через использование starship в любом относительно свежем эмуляторе терминала, например kitty
Хм, не заметил преимуществ worktree перед stash-ем, больше действий требует производить.
Создание отдельного рабочего дерева да, требует больше действий, stash в этом плане выигрывает. Но worktree можно создать один раз и больше не создавать для какой-то цели. По сути рядом будет лежать копия проекта, но слинкованная с основным. И после этого уже не надо создавать заново worktree, а просто каждый раз (будь то ревью или фикс) открывать в отдельном окне IDE ту версию и не сташить ничего.
Мы на работе например пишем на go, проект достаточно разросшийся (такая увесистая монорепа), пользуемся кодогенерацией, но результаты этой генерации не пушим, и генерим отдельно. И каждый раз при переключении веток для локального запуска тестов надо заново делать генерацию, которая может занимать минуту и больше.
Или же в процессе работы может быть поднят дебаг из исходного кода. Если работать тут же, а не в отдельном дереве, то надо тушить дебаг и заново потом поднимать.
Но, возможно, в Вашем случае с процессами и языком который Вы используете worktree может и не дать преимуществ, тут все зависит.
@@suchkov-techприкольно, надо будет разобрать. Это еще и быстрый переход в другую ветку, по cd)
@@suchkov-tech А в чём принципиальный выигрыш по сравнению с склонировать проект в отдельную папку и переключить ветку там? Если мы всё равно открываем новое окно ide.
Ещё, на мой взгляд, упущено - считает ли гит новую папку, созданную через worktree, как незакомиченное изменение в оригинальной ветке.
@@ILyaCyclone я бы выделил два основных преимущества.
Первое - это размер. Если клонировать отдельную копию, то занимать ровно столько же места. Если Вы пользуетесь worktree, то полная копия не создается - это все части одного репозитория.
На моем рабочем примере:
```
$ du -hs api/.git
1.4G api/.git
```
и
```
$ du -hs api-worktree-hotfix/.git
4.0K api-worktree-hotfix/.git
```
разница существенная.
Второе - эти две части гит репозитория знают друг о друге, в отличие от независимого клонирования. Если я подтяну свежий мастер в api, и перейду потом в api-worktree-hotfix и отбранчуюсь от мастера там - я отбранчуюсь от свежей версии мастера. То есть мне не нужно отдельно управлять и освежать основные ветки (develop и master) - достаточно сделать в одном из пространств
Нередко случается, когда стэшить приходится не один и на два раза. И работать со стэш-листом уже становится крайне неприятно.
Первый кейс заменить на git checkout -b "new-branch"
git switch -c new_branch
Как поставить 10 дизлайков на этот комментарий?
@@GigaMozg с 10 аккаунтов
какой смысл во всех этих командах, если скорее всего у разработчика под рукой есть ide с уже имеющимся графическим интерфейсом через который вполне удобно можно работать с гитом?
И еще интересно как команда maintenance будет работать на винде у которой нет крона
Ты еще не дорос просто
@@ryanlashkevich9615 это все аргументы в пользу командной строки?) Или я не дорос знать как это будет работать на винде?)
@@ryanlashkevich9615 Ну я склонен считать что перерос)
@@vovka_goodwin видимо имелся ввиду ввиду возраст. Приведу пример, в любой IDE можно посмотреть историю файла - команда такая: git log --follow /path/to/file. Но ни в одной IDE нельзя искать коммиты, которые редактировали конкретные диапазоны строк или строковые литералы: git log -L1,10 /path/to/file. По литералам: git log :"function_name" /path/to/file (кажется так). Зная эти команды (или даже написав удобный алиас на них, чтобы не превратиться в пианиста), можно быстрее искать нужные коммиты.
Сойдемся на том, что терминальное гитоводство - вопрос предпочтений.)
Кому-то значит интересно. Торвальдс ещё гитом занимается?
Суровые команды. Интересно, как много людей пользуются консольным гитом, а не всякими tui/gui для гита?
Немало
Я частично UI пользуюсь, частично терминалом. Через UI смотрю изменения в файлах, добавляю файлы (стейджу) и имя коммита пишу. Все остальное через терминал.
Как минимум все те, кто засветились на конфе - th-cam.com/video/aolI_Rz0ZqY/w-d-xo.html - у Скота Чакона
Когда только начинал осваивать гит, без гуя просто не мог. Сейчас - только консоль.
Ни разу не пользовался ui версией, только консоль
А что за шрифт в терминале? Красивый.
шрифт Fira Mono for Powerline
как же я оказывается отвык за последние пару лет от ветки master 😂 интересно остались ли западные компании не переименовавшие её в main 🤔
Остались
Если не секрет, что за тема в терминале?
я использую iTerm2 + zsh + oh-my-zsh, на видео тема Agnoster.
@@suchkov-tech спасибо))
Спасибо! Узнал много нового для себя.
Ерунда, не нашёл команды которая бы заинтересовала
Неи никакиз дополнительных проверок данных у команды switch. Это сетевой миф. Читайте доки.
возможно я не правильно был понят: команда switch обрывает выполнение операции если это может привести к потере данных.
"The operation is aborted however if the operation leads to loss of local changes, unless told otherwise" git-scm.com/docs/git-switch