Comments 44
Среди разработчиков стандартом альтернативы Bash является Zsh
Что?
среди пользователей Zsh стандартом является использование Oh My Zsh
Очень спорный "стандарт", использовать кастомизируемый инструмент, но при этом завязываться на чужой набор кастомизаций.
Да и статья, по большому счёту о том, как использовать git-плагин Oh My Zsh.
(edited) Это Tutorial, не сразу увидел метку
Очень спорный «стандарт», использовать кастомизируемый инструмент, но при этом завязываться на чужой набор кастомизаций.
В этом и заключается стандарт – кастомизации у всех одни и те же, а не самописные костыли.
Я был удивлён, когда понял, что немногие используют эти сокращения, хоть и работают через Zsh. Поэтому в форме обучающей статьи решил показать на примерах как выглядит такой подход, и рассказать чем он удобен.
Я вот сижу на fish, для меня эта статья по сути бесполезна. С историей fish и fzf это вообщем-то и не нужно, частые комманды можно найти поиском по истории буквально по паре букв.
Я думаю что автор хотел этим сказать что zsh является дефолтной оболочкой у большинства разработчиков, а не именно "стандарт". Если это так — то соглашусь, у меня тоже много знакомых разработчиков (именно разработчиков), которые используют zsh, в т.ч. и я. Но есть и те, кто используют bash, fish…
Сложно назвать использование какой то оболочки стандартом… Это как сказать что использование ubuntu это стандарт для разработчиков.
«Не знаю, на каком языке программирования вы пишете, но уверен, что используете Гит при разработке». Знали бы как вы заблуждаетесь!
Гит хорош когда у Вас в разработке «базар» — когда один и тоже кусок кода могут править несколько человек, но промышленная или внутренняя разработка она не такая. В ней все четко разделено. Когда у вас есть сроки, требования и требования к качеству кода вам некогда заниматься слиянием/разлиянием веток, разбором конфликтов –вы просто блокируете код/интерфейсы и пишете. Изменилось поведение или изменились интерфейсы – новая значительная версия.
Гит хорош когда у Вас в разработке «базар» — когда один и тоже кусок кода могут править несколько человек, но промышленная или внутренняя разработка она не такая. В ней все четко разделено. Когда у вас есть сроки, требования и требования к качеству кода вам некогда заниматься слиянием/разлиянием веток, разбором конфликтов –вы просто блокируете код/интерфейсы и пишете. Изменилось поведение или изменились интерфейсы – новая значительная версия.
Я прекрасно понимаю, что не все пользуются Гитом. Но целевая аудитория статьи – именно пользователи Гита, поэтому уточнения только поломали бы вступление.
Однако прочитав ваш комментарий, стало интересно узнать о таком подходе промышленной и внутренней разработки. Что значит «вы просто блокируете код/интерфейсы и пишете»? И почему «новая значительная версия» не может быть добавлена при использовании СКВ? И вот тезис про «некогда» заниматься работой с СКВ странный.
Однако прочитав ваш комментарий, стало интересно узнать о таком подходе промышленной и внутренней разработки. Что значит «вы просто блокируете код/интерфейсы и пишете»? И почему «новая значительная версия» не может быть добавлена при использовании СКВ? И вот тезис про «некогда» заниматься работой с СКВ странный.
Ну в "кровавом продакшене" в конечном счете тоже зачастую используется git, просто им не обмазываются с ног до головы, используя только то, что нужно. Как правило там все оагрничивается дай бог десятком команд.
Я надеюсь, что вы просто шутите.
Ввиду того «сообщество» не переносит критики, писать могу не чаще чем раз в сутки так что ответ обобщенный.
Просто обычный банк. За 25 лет разработки не просто не возникла потребность в каких то внешних СКВ. «Репозиторий» просто файловая шара (сейчас чуть более 500 Мб исходников в 12 тыс. файлах и 300 каталогах ), с правами на файловую систему через глобальную службу аутентификации, когда была NetWare сейчас LDAP. Работа полностью автономна не требуется не грамма интернета. В репозитории разработчикам доступно обычно 2 максимум 3 версии (версии есть полное дерево в файловой системе). Первая продакшен версия, вторая может быть которая используется для пользовательского тестирования, последняя (3-ая) для разработки. Т.к. у нас изначально есть техническое задние мы можем и открывать файлы на изменение только тому кому надо. Регрессионное тестирование делается на девелперсокй версии и опять же в режиме реадонли для тестеров. Версионность поддерживается файловой системой (это отдельный том файлового хранилища). В виду использования базовых вещей — файлового доступа, работает в любых условиях хоть vim, хот ed или какой то кодогенератор. Конечно поверху наворочено куча скриптов для контроля, что нет парных доступов или не дали лишние доступы. Но мы точно знаем прежде чем что либо исправлять или добавлять мы знаем что будем делать, как писать, у нас всегда есть техзадание. Были конечно проблемы когда надо было вставить срочно ставить хотфикс на лету и он рушил девелоперскую версию, но извините у нас среда 25х8 и рабочий бизнес важнее чем текущая разработка/доработка.
И соберу еще минусов от «новомодных», у нас даже нет ни scrum ни agile. И таких новомодных просим держать свое мнение при себе и чаще всего искать другое место работы. У нас простой водопад или водопад с параллельными процессами. Нам для разработки нужно соблюсти 2 момента: сроки разработки, и соответствие ТЗ.
Попытки ввести agile и оно же с ними разбились об элементарные вопросы «Вы серьёзно будете создавать и сортировать свой бэклог, а не делать то что уже написано в ТЗ?», «Или вы серьезно считаете что информационная система без инструкции и документации это допустимо?», «Вы хотите нанять еще специалиста который будет разбираться со слиянием кода из веток?».
Так что вот так и у нас не контора по разработке ПО, а организация занимающаяся предоставлением финансовых услуг.
Просто обычный банк. За 25 лет разработки не просто не возникла потребность в каких то внешних СКВ. «Репозиторий» просто файловая шара (сейчас чуть более 500 Мб исходников в 12 тыс. файлах и 300 каталогах ), с правами на файловую систему через глобальную службу аутентификации, когда была NetWare сейчас LDAP. Работа полностью автономна не требуется не грамма интернета. В репозитории разработчикам доступно обычно 2 максимум 3 версии (версии есть полное дерево в файловой системе). Первая продакшен версия, вторая может быть которая используется для пользовательского тестирования, последняя (3-ая) для разработки. Т.к. у нас изначально есть техническое задние мы можем и открывать файлы на изменение только тому кому надо. Регрессионное тестирование делается на девелперсокй версии и опять же в режиме реадонли для тестеров. Версионность поддерживается файловой системой (это отдельный том файлового хранилища). В виду использования базовых вещей — файлового доступа, работает в любых условиях хоть vim, хот ed или какой то кодогенератор. Конечно поверху наворочено куча скриптов для контроля, что нет парных доступов или не дали лишние доступы. Но мы точно знаем прежде чем что либо исправлять или добавлять мы знаем что будем делать, как писать, у нас всегда есть техзадание. Были конечно проблемы когда надо было вставить срочно ставить хотфикс на лету и он рушил девелоперскую версию, но извините у нас среда 25х8 и рабочий бизнес важнее чем текущая разработка/доработка.
И соберу еще минусов от «новомодных», у нас даже нет ни scrum ни agile. И таких новомодных просим держать свое мнение при себе и чаще всего искать другое место работы. У нас простой водопад или водопад с параллельными процессами. Нам для разработки нужно соблюсти 2 момента: сроки разработки, и соответствие ТЗ.
Попытки ввести agile и оно же с ними разбились об элементарные вопросы «Вы серьёзно будете создавать и сортировать свой бэклог, а не делать то что уже написано в ТЗ?», «Или вы серьезно считаете что информационная система без инструкции и документации это допустимо?», «Вы хотите нанять еще специалиста который будет разбираться со слиянием кода из веток?».
Так что вот так и у нас не контора по разработке ПО, а организация занимающаяся предоставлением финансовых услуг.
Это у вас просто когда-то понавыдумывали своих велосипедов, а теперь вы боитесь тронуть то что и так работает. В принципе имеет право на жизнь, но со временем рынок вас сожрет — старые программисты уйдут на пенсию, а новые к вам не пойдут, потому что у вас даже гита нет.
Итого, плюсы и минусы вашей реализации по сравнению с введением Git-а:
+ Попрактиковались в написании своих костылей за счет заказчика
+ Ощущаете за собой право осуждать современное ПО в котором не разбираетесь (но, скорее всего, только внутри команды)
— Нет возможности правки одного файла одновременно несколькими разработчиками
— Приходится вручную контролировать доступа к файлам
— Нет нормальной истории изменений, что затрудняет поиск причины правок
— Вероятнее всего откат правок конкретных изменений одного разработчика невозможен
— Введение в проект новых разработчиков затруднено. Люди, работавшие с нормальными VCS крутят пальцем у виска.
Зачем вам отдельный специалист для слияния кода из веток тоже остается под вопросом, разобраться с Git-ом даже для джуна вопрос пары дней. А для разработчиков с 25-ти летним опытом тем более.
+ Попрактиковались в написании своих костылей за счет заказчика
+ Ощущаете за собой право осуждать современное ПО в котором не разбираетесь (но, скорее всего, только внутри команды)
— Нет возможности правки одного файла одновременно несколькими разработчиками
— Приходится вручную контролировать доступа к файлам
— Нет нормальной истории изменений, что затрудняет поиск причины правок
— Вероятнее всего откат правок конкретных изменений одного разработчика невозможен
— Введение в проект новых разработчиков затруднено. Люди, работавшие с нормальными VCS крутят пальцем у виска.
Зачем вам отдельный специалист для слияния кода из веток тоже остается под вопросом, разобраться с Git-ом даже для джуна вопрос пары дней. А для разработчиков с 25-ти летним опытом тем более.
+ Попрактиковались в написании своих костылей за счет заказчика
Не угадали. Заказчику пофигу есть у нас гит или нет, это совершенно не важно. Ему важно работает или нет ПО в установленные сроки с установленным функционалом. И мой заказчик сидит этажом выше.
+ Ощущаете за собой право осуждать современное ПО в котором не разбираетесь (но, скорее всего, только внутри команды)
Угадали. У нас разработка не ради разработки, а ради конечного продукта. Если у какого то разработчика есть время лазить по сырцам и предлагать изменить код в местах которые ему не делегированы для разработки — это проблема его руководителя что не может эффективно использовать трудовой ресурс. А современное ПО это что?
— Нет возможности правки одного файла одновременно несколькими разработчиками
Серьезно? У нас относительно спроектированная и декомпозированная структура ПО. Я не говорю что каждая константа или функция в отдельном файле, но каждый класс или хранимая процедура в отдельном. Первый признак проблем в архитектуре и в частности архитектуре сырцов потребность одновременно исправить одну функцию или одну строку кода двум разработчиками.
— Приходится вручную контролировать доступа к файлам
А вот это просто требование к системе. Как в гите можно запретить изменять конкретный файл? Как можно в гите не дать посмотреть конкретный файл пользователю? Как я писал у нас разработка не типа «базара».
— Нет нормальной истории изменений, что затрудняет поиск причины правок
Это реально смешно Вы знаете сколько раз в день разработчик или его среда разработки фиксирует через save? И как он меняет файл между этими сейвами? А я знаю и поверьте в файловой системе все ходы записаны и восстановить версию файла нет проблем. Вы сталкивались с тем что у вас все работало между 11 и12 часами и вы это поняли только в 16:00 и вопрос как откатится в гите реально решен? Вы пушите в гит после каждого изменения файла или только перед сборкой или только когда сочтете нужным?
— Вероятнее всего откат правок конкретных изменений одного разработчика невозможен
См. предыдущий комментарий и ваш вопрос не то что не вопрос, а сама суть системы.
— Введение в проект новых разработчиков затруднено. Люди, работавшие с нормальными VCS крутят пальцем у виска.
И опять не угадали! Ввиду того что используется самое простое и элементарное для хранения сырцов –файловая система. То уровень входа не то что нулевой, а как тест на профпригодность. Вы не можете сохранять проект в одни и те же файлы? – Если нет то вы нам просто не подходите как разработчик.
=Зачем вам отдельный специалист для слияния кода из веток тоже остается под вопросом, разобраться с Git-ом даже для джуна вопрос пары дней. А для разработчиков с 25-ти летним опытом тем более.
К сожалению разбирались и разобрались. Не подходи гит как система управления сырцам и их версиями. Для «базара» может быть да, но администрировать базар у нас нет задачи.
=Это у вас просто когда-то понавыдумывали своих велосипедов, а теперь вы боитесь тронуть то что и так работает. В принципе имеет право на жизнь, но со временем рынок вас сожрет — старые программисты уйдут на пенсию, а новые к вам не пойдут, потому что у вас даже гита нет.
Спишемся через 25 лет ;)
У меня нет не то что задачи, а даже желания наставить кого то на истинный путь и уж тем более научить кого то. Просто глядя на «современную разработку» диву даёшься как такое можно сделать, зачем вы все усложняете!
Не угадали. Заказчику пофигу есть у нас гит или нет, это совершенно не важно. Ему важно работает или нет ПО в установленные сроки с установленным функционалом. И мой заказчик сидит этажом выше.
+ Ощущаете за собой право осуждать современное ПО в котором не разбираетесь (но, скорее всего, только внутри команды)
Угадали. У нас разработка не ради разработки, а ради конечного продукта. Если у какого то разработчика есть время лазить по сырцам и предлагать изменить код в местах которые ему не делегированы для разработки — это проблема его руководителя что не может эффективно использовать трудовой ресурс. А современное ПО это что?
— Нет возможности правки одного файла одновременно несколькими разработчиками
Серьезно? У нас относительно спроектированная и декомпозированная структура ПО. Я не говорю что каждая константа или функция в отдельном файле, но каждый класс или хранимая процедура в отдельном. Первый признак проблем в архитектуре и в частности архитектуре сырцов потребность одновременно исправить одну функцию или одну строку кода двум разработчиками.
— Приходится вручную контролировать доступа к файлам
А вот это просто требование к системе. Как в гите можно запретить изменять конкретный файл? Как можно в гите не дать посмотреть конкретный файл пользователю? Как я писал у нас разработка не типа «базара».
— Нет нормальной истории изменений, что затрудняет поиск причины правок
Это реально смешно Вы знаете сколько раз в день разработчик или его среда разработки фиксирует через save? И как он меняет файл между этими сейвами? А я знаю и поверьте в файловой системе все ходы записаны и восстановить версию файла нет проблем. Вы сталкивались с тем что у вас все работало между 11 и12 часами и вы это поняли только в 16:00 и вопрос как откатится в гите реально решен? Вы пушите в гит после каждого изменения файла или только перед сборкой или только когда сочтете нужным?
— Вероятнее всего откат правок конкретных изменений одного разработчика невозможен
См. предыдущий комментарий и ваш вопрос не то что не вопрос, а сама суть системы.
— Введение в проект новых разработчиков затруднено. Люди, работавшие с нормальными VCS крутят пальцем у виска.
И опять не угадали! Ввиду того что используется самое простое и элементарное для хранения сырцов –файловая система. То уровень входа не то что нулевой, а как тест на профпригодность. Вы не можете сохранять проект в одни и те же файлы? – Если нет то вы нам просто не подходите как разработчик.
=Зачем вам отдельный специалист для слияния кода из веток тоже остается под вопросом, разобраться с Git-ом даже для джуна вопрос пары дней. А для разработчиков с 25-ти летним опытом тем более.
К сожалению разбирались и разобрались. Не подходи гит как система управления сырцам и их версиями. Для «базара» может быть да, но администрировать базар у нас нет задачи.
=Это у вас просто когда-то понавыдумывали своих велосипедов, а теперь вы боитесь тронуть то что и так работает. В принципе имеет право на жизнь, но со временем рынок вас сожрет — старые программисты уйдут на пенсию, а новые к вам не пойдут, потому что у вас даже гита нет.
Спишемся через 25 лет ;)
У меня нет не то что задачи, а даже желания наставить кого то на истинный путь и уж тем более научить кого то. Просто глядя на «современную разработку» диву даёшься как такое можно сделать, зачем вы все усложняете!
Заказчику пофигу есть у нас гит или нет, это совершенно не важно. Ему важно работает или нет ПО в установленные сроки с установленным функционалом
Несомненно. Но что бы сказал ваш заказчик, если бы узнал что десятки (сотни?) часов, потраченные на разработку самописной системы контроля версий можно было бы заменить готовой технологией, которая при этом во многом превосходит вашу?
Угадали. У нас разработка не ради разработки, а ради конечного продукта
Эта парадигма запрещает вам использовать любые современные инструменты, судя по всему?
Как можно в гите не дать посмотреть конкретный файл пользователю?
Это вы называете «спроектированной и декомпозированной структурой ПО»?
Вы сталкивались с тем что у вас все работало между 11 и12 часами и вы это поняли только в 16:00 и вопрос как откатится в гите реально решен? Вы пушите в гит после каждого изменения файла или только перед сборкой или только когда сочтете нужным?
Если нужно посмотреть локально я пользуюсь файловой историей. Я про возможность через пол года посмотреть по какой причине был изменена та или иная часть кода.
Просто глядя на «современную разработку» диву даёшься как такое можно сделать, зачем вы все усложняете
Вместо готовых инструментов вы используете какие-то костыли, но усложняют все, кроме вас? :)
UFO just landed and posted this here
UFO just landed and posted this here
заваливать консоль глобальными алиасами — верный путь к отстрелу ноги
у гита есть встроенный алиасер и писать git aa вместо gaa не намного длинней
у гита есть встроенный алиасер и писать git aa вместо gaa не намного длинней
Не нужно её заваливать, просто подключите 2-5 плагинов самых основных инструментов.
А в чем преимущество zsh-алиасов перед родными git? «git st» набирается так же быстро, как и «gsb», автодополнением понимается без проблем, и не захламляет глобальное автодополнение.
Кроме того, мне кажется, что многие алиасы избыточны и не нужны. gcmsg, gca — Зачем? Можно один раз сделать алиас «git ci» и писать привычные «git ci -m message» или «git ci -a -m message».
К тому же, когда в zsh вы набираете «git ci --», шелл подскажет вам список опций с описанием, что должно быть проще, чем вспоминать то ли gcn!, то ли gnc!
Кроме того, мне кажется, что многие алиасы избыточны и не нужны. gcmsg, gca — Зачем? Можно один раз сделать алиас «git ci» и писать привычные «git ci -m message» или «git ci -a -m message».
К тому же, когда в zsh вы набираете «git ci --», шелл подскажет вам список опций с описанием, что должно быть проще, чем вспоминать то ли gcn!, то ли gnc!
Не сказали самое главное: можно добавлять свои алиасы в git (вызывать git NAME)
git config --global alias.NAME '!... && ...'UFO just landed and posted this here
невероятно полезный алиас
т.е. это в разы удобнее чем
? Особого смысла не вижу
полезнее был бы даже алиас
на
Да и вообще сам синтаксис git достаточно простой, чтобы не страдать никакими алиасами, ну, мне так кажется.
git add allт.е. это в разы удобнее чем
git add *? Особого смысла не вижу
полезнее был бы даже алиас
git diffна
git diff --colorДа и вообще сам синтаксис git достаточно простой, чтобы не страдать никакими алиасами, ну, мне так кажется.
Что-то я не понял примера с git add звёздочка . Написать gaa – вот это удобно.
Разве цвет не по умолчанию прописан в конфиге Гита? Нет никакой необходимости в этом ключе git diff --color.
З.Ы. Промахнулся веткой для ответа.
ну, я про это. Может не сильно корректно написано просто:
по умолчанию не прописан --color, в RHEL по крайней мере
все эти gaa и прочее это, как уже выше заметили, верный способ выстрелить себе в ногу, да и не такая уж и значительная экономия времени, надо сказать.
Добавляем все изменения в индекс алиасом «git add all»:
по умолчанию не прописан --color, в RHEL по крайней мере
все эти gaa и прочее это, как уже выше заметили, верный способ выстрелить себе в ногу, да и не такая уж и значительная экономия времени, надо сказать.
git commit -a и git commit -am (с алиасами в статье оно же, видимо, gca и gcam) — вот это правда удобно, и позволяет допускать меньше ошибок, что ненужные файлы попадут в коммит
Чего уж тогда не до одной буквы сократили то? «a» — git add all
Алиасы безусловно полезны. Есть одно «но»: нужно убедить всех пользоваться одними и теми же алиасами в обязательном порядке, иначе при попытке помочь соседу руки будут через раз набирать автоматом алиас, а после того как он не сработает, выматерившись набирать полную команду.
UFO just landed and posted this here
Через IDE ощущения не те.
Ну, какие-то ощущения хороши для секса (в смысле получения удовольствия, а вы что подумали?), а какие-то для работы (быстро, эффективно, наглядно, без "нелепых телодвижений"). Мне нравится иногда потрогать Гит в консоли, но наглядность работы с индексом и клавиатурные сокращения вместо даже очень коротких команд, которые я имею через честно купленный Смартгит, по мне много лучше подбора магических сокращений, обеспечивающих "самое правильное состояние индекса перед коммитом". Ну и всегда можно посмотреть, что же это была за команда, чтобы при случае применить в консоли или скрипте.
Вот честно, единственное, что не смог сделать в нём — мердж с поддеревом без общих коммитов. Но и тут и консоль без яндекса не завелась, хотя учился это делать по официальным докам.
У меня противоположное мнение. Очень тяжело через Idea работать с Git. И никакой наглядности я там не ощущаю.
Я к тому, что вы субъективно любите менюшки, а кто-то консоль, поэтому что из этого кактус вопрос бессмысленный.
Я так и не понял, а какие преимущества дает использование именно zsh по сравнению с bash в контексте работы с git?
Можно привести какую то сводную таблицу. Например, в bash нельзя сделать A. Сделать B можно, но придется выполнить 10 команд, вместо одной в zsh. Или как то так.
Ибо мне после прочтения статьи совсем не понятно, какие же такие преимущества дает zsh (Oh My Zsh) в контексте работы с git в консоли. Или под хаками и продвинутой работой понималось использование алиасов?
Можно привести какую то сводную таблицу. Например, в bash нельзя сделать A. Сделать B можно, но придется выполнить 10 команд, вместо одной в zsh. Или как то так.
Ибо мне после прочтения статьи совсем не понятно, какие же такие преимущества дает zsh (Oh My Zsh) в контексте работы с git в консоли. Или под хаками и продвинутой работой понималось использование алиасов?
Если статья про zsh, то почему в заголовке написано git?
Всё это боловство. Самое полезное сокращение, что есть для гитаэто git-fire :)
UFO just landed and posted this here
Тут вопрос в оптимизации собственных действий. Кто-то обратит внимание, что 10 раз за день выполняет одну и ту же пару-тройку действий и автоматизирует этот процесс (скрипт, алиас, плагин и т.д.), а кто-то и дальше будет повторять одно и тоже. Вопрос внутреннего спокойствия, если хотите. В конце-концов IDE тоже появились из желания сократить или улучшить выполняемые операции.
UFO just landed and posted this here
Ну не только четкими кретериями мир полон. Субъективная оценка тоже роляет. Можно ли ругать разработчика, что он потратил время на переход с одной IDE на другую? Ведь нет четкого критерия, по которому можно оценить, что он стал эффективнее. Однако, возможно ему стало комфортнее жить и он от этого стал лучше работать. Тоже самое и с алиасами в bash/zsh и прочей требухой.
Не рекомендовал бы изучать гит со статью с алиасами вместо реальных команд. Алиасы это вкусовщина и оптимизация имхо, даже не знаю стоит ли об этом писать в таком ключе.
Sign up to leave a comment.
Продвинутое использование Гита или как выйти на пенсию на полгода раньше?