Продвинутое использование Гита или как выйти на пенсию на полгода раньше?

  • Tutorial


Не знаю, на каком языке программирования вы пишете, но уверен, что используете Гит при разработке. Инструментов для сопровождения разработки становится всё больше, но даже самый маленький тестовый проект, я неизменно начинаю с команды git init. А в течение рабочего дня набираю в среднем ещё 80 команд, обращаясь к этой системе контроля версий.


Я потратил кучу нервов, когда стал переучиваться на десятипальцевый метод печати. В итоге это стало самым правильным решением по улучшению личного рабочего процесса. В числе следующих по важности оптимизаций стоит углубленное освоение Гита.


На Хабр написано много статей о Гите, но они не уходят дальше официальной документации, а упрощать работу авторы предлагают самописными костылями. Я уверен, что изучать Гит нужно на конкретных примерах задач, а повышать эффективность работы с ним – стандартизированными средствами.


Кому будет полезна эта статья?


Вы уже освоили джентльменский набор Гита и готовы двигаться дальше? Существует 2 пути:


  1. Освоить сокращённые команды – алиасы. Они почти всегда составлены мнемонически и легко запоминаются. Забыть оригиналы команд проблематично, я легко их набираю, когда это требуется. Плюс не сбиваюсь с мысли, проверяя что-то в Гите в процессе написания кода.
  2. Узнать о дополнительных флагах к командам, а также их объединении между собой. Я понимаю, что кто-то ненавидит сокращения. Для вас тоже есть интересный материал в статье – как повысить полезность и удобство вывода команд, а также как решать не самые тривиальные, но часто встречающиеся на практике задачи.

Посвятите описанным в статье экспериментам пару часов сегодня, и сэкономьте по приблизительным расчётам полгода рабочей жизни.


Добро пожаловать под кат!


Подготовка


Среди разработчиков стандартом альтернативы Bash является Zsh – продвинутая программная оболочка, поддерживающая тонкую настройку. А среди пользователей Zsh стандартом является использование Oh My Zsh – набора готовых настроек для Zsh. Таким образом, установив этот комплект, мы из коробки получим набор хаков, которые годами собирало и нарабатывало для нас сообщество.


Очень важно отметить, что Zsh есть и для Linux, и для Mac, и даже для Windows.


Установка Zsh и Oh My Zsh


Устанавливаем Zsh и Oh My Zsh по инструкции одной командой:


# macOS
brew install zsh zsh-completions && sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"

# Ubuntu, Debian, ...
apt install zsh && sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"

Поскольку задача – оптимизировать взаимодействие с Гитом, добавим к Zsh пару плагинов. Откройте файл ~/.zshrc и добавьте к списку plugins:


plugins=(git gitfast)

Итого:


  • git – набор алиасов и вспомогательных функций;
  • gitfast – улучшенное автодополнение для Гита.

Установка tig


И последний штрих – установка консольной утилиты tig:


# macOS
brew install tig

# Ubuntu, Debian, ...
# https://jonas.github.io/tig/INSTALL.html

О ней поговорим дальше.


Гит на практике


Разбираться с Гитом лучше всего на примерах решения конкретных задач. Далее рассмотрим задачи из ежедневной практики и варианты их удобного решения. Для этого рассмотрим некий репозиторий с текстовыми файлами.


В жёлтых блоках указан основной алиас для решения задачи из раздела. Выучите только его, а всё остальное оставьте для общего развития.

Проверяем состояние рабочей директории


Начнём с самой базовой вещи. Мы немного поработали и теперь давайте посмотрим, что происходит в рабочей директории:


$ git status

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   e.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   b.md

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    d.md

Текущее состояние всех файлов описано очень подробно, даны дополнительные руководства к действию. Очень полезно на первых порах использования Гита, но для ежедневной работы очень много лишнего. Давайте понизим уровень шума дополнительными ключами:


$ git status -sb

## master
 M b.md
A  e.md
?? d.md

Ага, мы находимся в ветке master, изменили файл b.md (M-odified) и создали два файла, добавив первый в индекс Гита (A-dded), а второй оставив вне индекса (??). Коротко и ясно.


Осталось оптимизировать бесконечный ввод этой команды алиасом «git status with branch»:


Показать сокращённый статус рабочей директории
 
$ gsb # git status -sb


Создаём коммит


Продолжаем.


Конечно, вы умеете создавать коммиты. Но давайте попробуем оптимизировать решение и этой простой задачи. Добавляем все изменения в индекс алиасом «git add all»:


$ gaa # git add --all

Проверяем, что в индекс попало именно то, что нам нужно с помощью алиаса «git diff cached»:


$ gdca # git diff --cached

diff --git a/b.md b/b.md
index 698d533..cf20072 100644
--- a/b.md
+++ b/b.md
@@ -1,3 +1,3 @@
 # Beta

-Next step.
+Next step really hard.
diff --git a/d.md b/d.md
new file mode 100644
index 0000000..9e3752e
--- /dev/null
+++ b/d.md
@@ -0,0 +1,3 @@
+# Delta
+
+Body of article.

Хм, в один коммит должны попадать изменения, решающие единственную задачу. Здесь же изменения обоих файлов никак не связаны между собой. Давайте пока исключим файл d.md из индекса алиасом «git reset undo»:


$ gru d.md # git reset -- d.md

И создадим коммит алиасом «git commit»:


$ gc # git commit

Пишем название коммита и сохраняем. А следом создаём ещё один коммит для файла d.md более привычной командой с помощью алиаса «git commit messag:


$ gaa # Уже знакомый алиас
$ gcmsg "Add new file" # git commit -m "Add new file"

А ещё мы можем...


… коммитить изменённые файлы из индекса одной командой:


$ gcam "Add changes" # git commit -a -m "Add changes"

… смотреть изменения по словам вместо строк (очень полезно при работе с текстом):


$ gdw # git diff --word-diff

… добавлять файлы по частям (очень полезно, когда нужно добавить в коммит только часть изменений из файла):


$ gapa # git add --patch

… добавлять в индекс только файлы, уже находящиеся под наблюдением Гита:


$ gau # git add --update

Итого:


Добавить в индекс / Создать коммит
 
$ ga # git add
$ gc # git commit


Исправляем коммит


Название последнего коммита не объясняет сделанных нами изменений. Давайте переформулируем:


$ gc! # git commit -v --amend

И в открывшемся текстовом редакторе назовём его более понятно: "Add Delta article". Уверен, вы никогда не используете ключ -v, хотя при редактировании описания коммита он показывает все сделанные изменения, что помогает лучше сориентироваться.


А ещё мы можем...


… внести в коммит изменения файлов, но не трогать описание:


$ gcn! # git commit -v --no-edit --amend

… внести все изменения файлов сразу в коммит, без предварительного добавления в индекс:


$ gca! # git commit -v -a --amend

… скомбинировать две предыдущие команды:


$ gcan! # git commit -v -a --no-edit --amend

Ну и важно ещё раз отметить, что вместо набора полной регулярно используемой команды git commit -v --amend, мы пишем всего три символа:


Изменить последний коммит
 
$ gc! # git commit -v --amend


Начинаем работать над новой фичей


Создаём новую ветку от текущей алиасом «git checkout branch»:


$ gcb erlang # git checkout --branch erlang

Хотя нет, лучше напишем статью про более современный язык Эликсир алиасом «git branch с ключом move» (переименовывание в Гите делается через move):


$ gb -m elixir # git branch -m elixir

Здесь логично было бы использовать алиас gbmv, но его, к сожалению, ещё не придумали. Хороший вариант для контрибьюта.


Вносим изменения в репозиторий и создаём коммит, как уже умеем:


$ echo "# Эликсир — мощь Эрланга с изяществом Руби." > e.md
$ gaa && gcmsg "Add article about Elixir"

И запоминаем:


Создать новую ветку
 
$ gcb # git checkout --branch


Сливаем изменения


Теперь добавляем нашу новую статью об Эликсире в master. Сначала переключимся на основную ветку алиасом «git checkout master»:


$ gcm # git checkout master

Нет, серьёзно. Одна из самых часто используемых команд в три легко запоминающихся символа. Теперь мерджим изменения алиасом «git merge»:


$ gm elixir # git merge elixir

Упс, а в master кто-то уже успел внести свои изменения. И вместо красивой линейной истории, которая принята у нас в проекте, создался ненавистный мердж-коммит.


Слить ветки
 
$ gm # git merge


Удаляем последний коммит


Ничего страшного! Нужно просто удалить последний коммит и попробовать слить изменения ещё раз «git reset hhard»:


Удалить последний коммит
 
$ grhh HEAD~ # git reset --hard HEAD~


Решаем конфликты


Стандартная последовательность действий checkout – rebase – merge для подготовки линейной истории изменений выполняется следующей последовательностью алиасов:


gco elixir # git checkout elixir
grbm # git rebase master
gcm # git checkout master
gm elixir # git merge elixir

Все они так часто используются что уже отлетают от пальцев, и проделывая подобные операции, нет необходимости задумываться о том, какой набор букв нужно набирать. И не забывайте, что в Zsh можно дополнять названия веток клавишей Tab.


Сделать ребейз
 
$ grb # git rebase


Отправка изменений на сервер


Сначала добавляем origin алиасом «git remote add»:


$ gra origin git@github.com/... # git remote add origin git@github.com/...

А затем отправляем изменения напрямую в текущую ветку репозитория («gg» – удвоенное g в начале команды указывает на выполнение действия в текущую ветку):


$ ggpush # git push origin git_current_branch

Вы также можете...


… отправить изменения на сервер с установкой upstream алиасом «git push set upstream»:


$ gpsup # git push --set-upstream origin $(git_current_branch)

Отправить изменения на сервер
 
$ gp # git push


Получаем изменения с сервера


Работа кипит. Мы успели добавить новую статью f.md в master, а наши коллеги изменить статью a.md и отправить это изменение на сервер. Эта ситуация тоже решается очень просто:


$ gup # git pull --rebase

После чего можно спокойно отправлять изменения на сервер. Конфликт исчерпан.


Получить изменения с сервера
 
$ gl # git pull


Удаляем слитые ветки


Итак, мы успешно влили в master несколько веток, в том числе и ветку elixir из предшествующего примера. Они нам больше не нужны. Можно удалять алиасом «git branch delete another»:


$ gbda # git branch --no-color --merged | command grep -vE "^(\*|\s*(master|develop|dev)\s*$)" | command xargs -n 1 git branch -d

Очень красивая и хитрая команда. Обычно я забываю очищать потерявшие актуальность ветки и эта изящная команда – настоящее спасение. Если не хотите использовать алиас, просто скопируйте полный вариант команды себе в заметки, и выполняйте его по мере необходимости.


Создаём временный коммит


Работа над новой статьёй h.md про Haskell идёт полным ходом. Написана половина и нужно получить отзыв от коллеги. Недолго думая, набираем алиас «git work in progress»:


$ gwip # git add -A; git rm $(git ls-files --deleted) 2> /dev/null; git commit --no-verify -m "--wip-- [skip ci]"

И тут же создаётся коммит с названием Work in Progress, пропускающим CI и удаляющим «лишние» файлы. Отправляем ветку на сервер, говорим об этом коллеге и ждём ревью.


Затем этот коммит можно отменить и вернуть файлы в исходное состояние:


$ gunwip # git log -n 1 | grep -q -c "\-\-wip\-\-" && git reset HEAD~1

А проверить, есть ли в вашей ветке WIP-коммиты можно командой:


$ work_in_progress

Команда gwip – довольно надёжный аналог stash, когда нужно переключиться на соседнюю ветку. Но в Zsh есть много алиасов и для самого stash.


Добавить временный коммит / Сбросить временный коммит
 
$ gwip
$ gunwip


Прячем изменения


С этой командой нужно быть осторожным. Файлы можно спрятать, а затем неаккуратным действием удалить насовсем, благо есть reflog, в котором можно попытаться найти потерянные наработки.


Давайте спрячем файлы, над которыми работаем, алиасом «git stash all»:


$ gsta # git stash save

А затем вернём их обратно алиасом «git stash pop»:


$ gstp # git stash pop

Или более безопасным методом «git stash all apply»:


$ gstaa # git stash apply

Вы также можете ...


… посмотреть, что конкретно мы припрятали:


gsts # git stash show --text

… воспользоваться сокращениями для связанных команд:


gstc # git stash clear
gstd # git stash drop
gstl # git stash list

Спрятать изменения / Достать изменения
 
$ gsta
$ gstaa


Ищем баг


Инструмент git-bisect, который неоднократно спасал мне жизнь, тоже имеет свои алиасы. Начинаем с запуска процедуры «двоичного поиска ошибки» алиасом «git bisect start»:


$ gbss # git bisect start

Отмечаем, что текущий, последний в ветке, коммит содержит ошибку, алиасом «git bisect bad»:


$ gbsb # git bisect bad

Теперь помечаем коммит, гарантирующий нам рабочее состояние приложения «git bisect good»:


$ gbsg HEAD~20 # git bisect good HEAD~20

А теперь остаётся продолжать отвечать на вопросы Гита фразами gbsb или gbsg, а после нахождения виновника сбросить процедуру:


$ gbsr # git bisect reset

И я действительно пишу эти сокращения при использовании этого инструмента.


Поиск коммита с ошибкой
 
$ gbss # git bisect start
$ gbsb # git bisect bad
$ gbsg # git bisect good
$ gbsr # git bisect reset


Ищем зачинщика беспредела


Даже с высоким процентом покрытия кода тестами, никто не застрахован от ситуации, когда приложение падает и любезно указывает на конкретную строчку с ошибкой. Или, например, в нашем случае мы хотим узнать, кто допустил ошибку во второй строчке файла a.md. Для этого выполните команду:


$ gbl a.md -L 2 # git blame -b -w a.md -L 2

Видите, контрибьютеры Oh My Zsh сделали алиас не просто на команду git blame, а добавили в него ключи, которые упрощают поиск непосредственно зачинщика.


Bonus


Просмотр списка коммитов


Для просмотра списка коммитов используется команда git log с дополнительными ключами форматирования вывода. Обычно эту команду вместе с ключами заносят в кастомные алиасы Гита. Нам с вами повезло больше, у нас уже есть готовый алиас из коробки: glog. А если вы установили утилиту tig по совету из начала статьи, то вы абсолютный чемпион.


Теперь, чтобы поизучать историю коммитов в консоли в очень удобном виде, нужно набрать слово git наоборот:


$ tig

Утилита также даёт пару полезных дополнений, которых нет в Гите из коробки.


Во-первых, команда для поиска по содержимому истории:


$ tig grep

Во-вторых, просмотр списка всех источников, веток, тегов вместе с их историей:


$ tig refs

В-третьих, может быть найдёте что-то интересное для себя сами:


$ tig --help

Случайно сделал git reset --hard


Вы работали над веткой elixir весь день:


$ glog

* 17cb385 (HEAD -> elixir) Refine Elixir article
* c14b4dc Add article about Elixir
* db84d54 (master) Initial commit

И под конец случайно всё удалили:


$ grhh HEAD~2
HEAD is now at db84d54 Initial commit

Не нужно паниковать. Самое главное правило – перестаньте выполнять какие-либо команды в Гите и выдохните. Все действия с локальным репозиторием записываются в специальный журнал – reflog. Из него можно достать хеш нужного коммита и восстановить его в рабочем дереве.


Давайте заглянем в рефлог, но не обычным способом через git reflog, а более интересным с подробной расшифровкой записей:


$ glg -g

Находим хеш нужного коммита 17cb385 и восстанавливаем его:


# Создаём новую ветку с нашим коммитом и переключаемся на неё
$ gcb elixir-recover 17cb385

# Удаляем старую ветку 
$ gbd elixir

# Переименовываем восстановленную ветку обратно
$ gb -m elixir

Случайно вместо создания нового коммита внёс изменения в предыдущий


Здесь нам снова на помощь приходит рефлог. Находим хеш оригинального коммита 17cb385, если мы производим отмену коммита сразу же, то вместо поиска хеша можем воспользоваться быстрой ссылкой на него HEAD@{1}. Следом делаем мягкий сброс, индекс при этом не сбрасывается:


# Мягкий сброс на оригинальный коммит
$ grh --soft HEAD@{1} # git reset -soft

# Коммитим правильно
$ gcmsg "Commit description"

Ветка слишком сильно устарела


Бывает начинаешь работать над фичей, но её релиз откладывается на неопределённый срок. Делаешь коммит и переключаешься на другие задачи. Вместе с командой вносишь кучу изменений в мастер и спустя время возвращаешься к ветке с фичей. Пробуешь сделать ребейз, но он предлагает разобрать конфликты в десятке коммитов. Можно попробовать решить их все либо сделать проще.


Давайте рассмотрим на примере ветки с фичей под названием elixir:


# Переключаемся на master
$ gcm # git checkout master

# Создаём новую актуальную ветку для оригинальной фичи
$ gcb elixir-new # git checkout --branch elixir-new

# Переносим единственный коммит с фичей из устаревшей ветки в новую
$ gcp elixir@{0} # git cherry-pick elixir@{0}

Вот так, вместо попытки обновления ветки, мы берём и без проблем переносим один единственный коммит.


Удаление важных данных из репозитория


Для удаления важных данных из репозитория, у меня сохранён такой сниппет:


$ git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch <path-to-your-file>' --prune-empty --tag-name-filter cat -- --all && git push origin --force --all

Выполнение этой команды поломает ваш stash. Перед её исполнением рекомендуется достать все спрятанные изменения. Подробнее об этом приёме по ссылке.


Обращение к предыдущей ветке


При выполнении некоторых команд, которые ожидают на вход название ветки, мы можем передать дефис - в качестве ссылки на ветку, с которой мы пришли. Особенно хорошо использовать этот трюк для чекаута:


$ gco - # git checkout -
$ gm - # git merge -
$ grb - # git rebase -

Удаление всех файлов, отмеченных в .gitignore


Ещё одна нередкая неудача – слишком поздно добавить в .gitignore какие-то нежелательные файлы или директории. Для того, чтобы вычистить их из репозитория (и удалить с диска) уже есть готовые ключи для команды git clean:


$ gclean -X # git clean -Xfd

Будьте осторожны!


Как правильно перебдеть читайте дальше.


Зачем многим командам нужен ключ --dry-run?


Ключ --dry-run нужен как раз в качестве осторожности при задачах удаления и обновления. Например, в предыдущем разделе описан способ удаления всего, что указано в файле .gitignore. Лучше проявиться осторожность и воспользоваться ключом --dry-run, отсмотреть список всех файлов к удалению, и только затем выполнить команду без --dry-run.


Заключение


В статье показывается точка для оптимизации трудовой деятельности программиста. Запомнить 10-20 мнемонических сокращений не составляет труда, забыть оригинальные команды практически невозможно. Алиасы стандартизированы, так что при переходе всей команды на Zsh + Oh My Zsh, вы сможете работать с теми же скоростью и комфортом, даже при парном программировании.


Куда двигаться дальше?


Предлагаю следующие варианты:


  1. Наконец-то разберитесь, как Гит устроен внутри. Очень помогает понимать, что ты делаешь и почему то, что ты хочешь сделать не получается.
  2. Не ленитесь лишний раз заглянуть в документацию к командам: git --help или ghh.
  3. Посмотрите полный список алиасов по ссылке. Пытаться запомнить их все – безумие, но использовать список в качестве сборника набора интересных команд и ключей к ним – хорошая идея.

Некоторые алиасы сделаны нетривиально, но оказываются очень полезными на практике. Многие из представленных алиасов являются не просто сокращениями, а небольшими функциями, которые ещё больше оптимизируют работу. Пользоваться Гитом стало приятнее, качество коммитов повысилось.


Надеюсь, материал оказался полезным, и вы смогли узнать для себя что-то новое. А может быть уже начали активно внедрять новый подход. Удачи!

Share post

Similar posts

Comments 44

    +4
    Среди разработчиков стандартом альтернативы Bash является Zsh

    Что?


    среди пользователей Zsh стандартом является использование Oh My Zsh

    Очень спорный "стандарт", использовать кастомизируемый инструмент, но при этом завязываться на чужой набор кастомизаций.


    Да и статья, по большому счёту о том, как использовать git-плагин Oh My Zsh.
    (edited) Это Tutorial, не сразу увидел метку

      0
      Очень спорный «стандарт», использовать кастомизируемый инструмент, но при этом завязываться на чужой набор кастомизаций.


      В этом и заключается стандарт – кастомизации у всех одни и те же, а не самописные костыли.

      Я был удивлён, когда понял, что немногие используют эти сокращения, хоть и работают через Zsh. Поэтому в форме обучающей статьи решил показать на примерах как выглядит такой подход, и рассказать чем он удобен.
        +7

        Потому что сокращения zsh довольно сомнительные. Встроенный git alias в данном случае удобнее на мой взгляд нежели улучшальные плагины.


        gc

        и в голове возникает картина как сборщик мусора начинает что-то чистить...

        0
        Я вот сижу на fish, для меня эта статья по сути бесполезна. С историей fish и fzf это вообщем-то и не нужно, частые комманды можно найти поиском по истории буквально по паре букв.
          0

          Я думаю что автор хотел этим сказать что zsh является дефолтной оболочкой у большинства разработчиков, а не именно "стандарт". Если это так — то соглашусь, у меня тоже много знакомых разработчиков (именно разработчиков), которые используют zsh, в т.ч. и я. Но есть и те, кто используют bash, fish…
          Сложно назвать использование какой то оболочки стандартом… Это как сказать что использование ubuntu это стандарт для разработчиков.

          –14
          «Не знаю, на каком языке программирования вы пишете, но уверен, что используете Гит при разработке». Знали бы как вы заблуждаетесь!
          Гит хорош когда у Вас в разработке «базар» — когда один и тоже кусок кода могут править несколько человек, но промышленная или внутренняя разработка она не такая. В ней все четко разделено. Когда у вас есть сроки, требования и требования к качеству кода вам некогда заниматься слиянием/разлиянием веток, разбором конфликтов –вы просто блокируете код/интерфейсы и пишете. Изменилось поведение или изменились интерфейсы – новая значительная версия.
            +6
            Я прекрасно понимаю, что не все пользуются Гитом. Но целевая аудитория статьи – именно пользователи Гита, поэтому уточнения только поломали бы вступление.

            Однако прочитав ваш комментарий, стало интересно узнать о таком подходе промышленной и внутренней разработки. Что значит «вы просто блокируете код/интерфейсы и пишете»? И почему «новая значительная версия» не может быть добавлена при использовании СКВ? И вот тезис про «некогда» заниматься работой с СКВ странный.
              +3
              Скорее всего там какойто свой унаследованный с дедовских времен подход. Я когда был джуном и работал один, тоже не понимал зачем это все нужно.
              +2

              Ну в "кровавом продакшене" в конечном счете тоже зачастую используется git, просто им не обмазываются с ног до головы, используя только то, что нужно. Как правило там все оагрничивается дай бог десятком команд.

                +1
                Я надеюсь, что вы просто шутите.
                  +1
                  Ввиду того «сообщество» не переносит критики, писать могу не чаще чем раз в сутки так что ответ обобщенный.
                  Просто обычный банк. За 25 лет разработки не просто не возникла потребность в каких то внешних СКВ. «Репозиторий» просто файловая шара (сейчас чуть более 500 Мб исходников в 12 тыс. файлах и 300 каталогах ), с правами на файловую систему через глобальную службу аутентификации, когда была NetWare сейчас LDAP. Работа полностью автономна не требуется не грамма интернета. В репозитории разработчикам доступно обычно 2 максимум 3 версии (версии есть полное дерево в файловой системе). Первая продакшен версия, вторая может быть которая используется для пользовательского тестирования, последняя (3-ая) для разработки. Т.к. у нас изначально есть техническое задние мы можем и открывать файлы на изменение только тому кому надо. Регрессионное тестирование делается на девелперсокй версии и опять же в режиме реадонли для тестеров. Версионность поддерживается файловой системой (это отдельный том файлового хранилища). В виду использования базовых вещей — файлового доступа, работает в любых условиях хоть vim, хот ed или какой то кодогенератор. Конечно поверху наворочено куча скриптов для контроля, что нет парных доступов или не дали лишние доступы. Но мы точно знаем прежде чем что либо исправлять или добавлять мы знаем что будем делать, как писать, у нас всегда есть техзадание. Были конечно проблемы когда надо было вставить срочно ставить хотфикс на лету и он рушил девелоперскую версию, но извините у нас среда 25х8 и рабочий бизнес важнее чем текущая разработка/доработка.
                  И соберу еще минусов от «новомодных», у нас даже нет ни scrum ни agile. И таких новомодных просим держать свое мнение при себе и чаще всего искать другое место работы. У нас простой водопад или водопад с параллельными процессами. Нам для разработки нужно соблюсти 2 момента: сроки разработки, и соответствие ТЗ.
                  Попытки ввести agile и оно же с ними разбились об элементарные вопросы «Вы серьёзно будете создавать и сортировать свой бэклог, а не делать то что уже написано в ТЗ?», «Или вы серьезно считаете что информационная система без инструкции и документации это допустимо?», «Вы хотите нанять еще специалиста который будет разбираться со слиянием кода из веток?».
                  Так что вот так и у нас не контора по разработке ПО, а организация занимающаяся предоставлением финансовых услуг.
                    +2
                    Это у вас просто когда-то понавыдумывали своих велосипедов, а теперь вы боитесь тронуть то что и так работает. В принципе имеет право на жизнь, но со временем рынок вас сожрет — старые программисты уйдут на пенсию, а новые к вам не пойдут, потому что у вас даже гита нет.
                      +2
                      Итого, плюсы и минусы вашей реализации по сравнению с введением Git-а:
                      + Попрактиковались в написании своих костылей за счет заказчика
                      + Ощущаете за собой право осуждать современное ПО в котором не разбираетесь (но, скорее всего, только внутри команды)

                      — Нет возможности правки одного файла одновременно несколькими разработчиками
                      — Приходится вручную контролировать доступа к файлам
                      — Нет нормальной истории изменений, что затрудняет поиск причины правок
                      — Вероятнее всего откат правок конкретных изменений одного разработчика невозможен
                      — Введение в проект новых разработчиков затруднено. Люди, работавшие с нормальными VCS крутят пальцем у виска.

                      Зачем вам отдельный специалист для слияния кода из веток тоже остается под вопросом, разобраться с Git-ом даже для джуна вопрос пары дней. А для разработчиков с 25-ти летним опытом тем более.
                        –2
                        + Попрактиковались в написании своих костылей за счет заказчика
                        Не угадали. Заказчику пофигу есть у нас гит или нет, это совершенно не важно. Ему важно работает или нет ПО в установленные сроки с установленным функционалом. И мой заказчик сидит этажом выше.

                        + Ощущаете за собой право осуждать современное ПО в котором не разбираетесь (но, скорее всего, только внутри команды)
                        Угадали. У нас разработка не ради разработки, а ради конечного продукта. Если у какого то разработчика есть время лазить по сырцам и предлагать изменить код в местах которые ему не делегированы для разработки — это проблема его руководителя что не может эффективно использовать трудовой ресурс. А современное ПО это что?

                        — Нет возможности правки одного файла одновременно несколькими разработчиками
                        Серьезно? У нас относительно спроектированная и декомпозированная структура ПО. Я не говорю что каждая константа или функция в отдельном файле, но каждый класс или хранимая процедура в отдельном. Первый признак проблем в архитектуре и в частности архитектуре сырцов потребность одновременно исправить одну функцию или одну строку кода двум разработчиками.

                        — Приходится вручную контролировать доступа к файлам
                        А вот это просто требование к системе. Как в гите можно запретить изменять конкретный файл? Как можно в гите не дать посмотреть конкретный файл пользователю? Как я писал у нас разработка не типа «базара».

                        — Нет нормальной истории изменений, что затрудняет поиск причины правок
                        Это реально смешно Вы знаете сколько раз в день разработчик или его среда разработки фиксирует через save? И как он меняет файл между этими сейвами? А я знаю и поверьте в файловой системе все ходы записаны и восстановить версию файла нет проблем. Вы сталкивались с тем что у вас все работало между 11 и12 часами и вы это поняли только в 16:00 и вопрос как откатится в гите реально решен? Вы пушите в гит после каждого изменения файла или только перед сборкой или только когда сочтете нужным?

                        — Вероятнее всего откат правок конкретных изменений одного разработчика невозможен
                        См. предыдущий комментарий и ваш вопрос не то что не вопрос, а сама суть системы.

                        — Введение в проект новых разработчиков затруднено. Люди, работавшие с нормальными VCS крутят пальцем у виска.
                        И опять не угадали! Ввиду того что используется самое простое и элементарное для хранения сырцов –файловая система. То уровень входа не то что нулевой, а как тест на профпригодность. Вы не можете сохранять проект в одни и те же файлы? – Если нет то вы нам просто не подходите как разработчик.

                        =Зачем вам отдельный специалист для слияния кода из веток тоже остается под вопросом, разобраться с Git-ом даже для джуна вопрос пары дней. А для разработчиков с 25-ти летним опытом тем более.
                        К сожалению разбирались и разобрались. Не подходи гит как система управления сырцам и их версиями. Для «базара» может быть да, но администрировать базар у нас нет задачи.

                        =Это у вас просто когда-то понавыдумывали своих велосипедов, а теперь вы боитесь тронуть то что и так работает. В принципе имеет право на жизнь, но со временем рынок вас сожрет — старые программисты уйдут на пенсию, а новые к вам не пойдут, потому что у вас даже гита нет.
                        Спишемся через 25 лет ;)

                        У меня нет не то что задачи, а даже желания наставить кого то на истинный путь и уж тем более научить кого то. Просто глядя на «современную разработку» диву даёшься как такое можно сделать, зачем вы все усложняете!
                          +1
                          Заказчику пофигу есть у нас гит или нет, это совершенно не важно. Ему важно работает или нет ПО в установленные сроки с установленным функционалом

                          Несомненно. Но что бы сказал ваш заказчик, если бы узнал что десятки (сотни?) часов, потраченные на разработку самописной системы контроля версий можно было бы заменить готовой технологией, которая при этом во многом превосходит вашу?

                          Угадали. У нас разработка не ради разработки, а ради конечного продукта

                          Эта парадигма запрещает вам использовать любые современные инструменты, судя по всему?

                          Как можно в гите не дать посмотреть конкретный файл пользователю?

                          Это вы называете «спроектированной и декомпозированной структурой ПО»?

                          Вы сталкивались с тем что у вас все работало между 11 и12 часами и вы это поняли только в 16:00 и вопрос как откатится в гите реально решен? Вы пушите в гит после каждого изменения файла или только перед сборкой или только когда сочтете нужным?

                          Если нужно посмотреть локально я пользуюсь файловой историей. Я про возможность через пол года посмотреть по какой причине был изменена та или иная часть кода.

                          Просто глядя на «современную разработку» диву даёшься как такое можно сделать, зачем вы все усложняете

                          Вместо готовых инструментов вы используете какие-то костыли, но усложняют все, кроме вас? :)
                            0
                            А я знаю и поверьте в файловой системе все ходы записаны и восстановить версию файла нет проблем.

                            И что ж у вас это за файловая система такая? Интересный подход, на самом деле, любопытно стало.

                            Вы пушите в гит после каждого изменения файла или только перед сборкой или только когда сочтете нужным?

                            Это вопрос дисциплины. Я пушу в гит часто и атомарно. Найти бисектом, что и когда сломалось, вообще не проблема.
                          0
                          Случается ли такое, что одному разработчику нужно временно прекратить разрабатывать одну фичу и начать разрабатывать другую фичу?
                          Случается ли такое, что одному разработчику нужно параллельно разрабатывать более чем одну фичу? Хотя это, конечно, сводится к предыдущему пункту в пределе частого переключения между бранчами.
                          Случается ли такое, что одному разработчику нужно при разработке своей фичи включить изменения, сделанные другим разработчиком при реализации другой фичи?

                          Как вы делаете bisect?
                          Как вы делаете blame?
                      +15
                      заваливать консоль глобальными алиасами — верный путь к отстрелу ноги
                      у гита есть встроенный алиасер и писать git aa вместо gaa не намного длинней
                        –1
                        Не нужно её заваливать, просто подключите 2-5 плагинов самых основных инструментов.
                          +2
                          А в чем преимущество zsh-алиасов перед родными git? «git st» набирается так же быстро, как и «gsb», автодополнением понимается без проблем, и не захламляет глобальное автодополнение.

                          Кроме того, мне кажется, что многие алиасы избыточны и не нужны. gcmsg, gca — Зачем? Можно один раз сделать алиас «git ci» и писать привычные «git ci -m message» или «git ci -a -m message».

                          К тому же, когда в zsh вы набираете «git ci --», шелл подскажет вам список опций с описанием, что должно быть проще, чем вспоминать то ли gcn!, то ли gnc!
                            +1
                            Не сказали самое главное: можно добавлять свои алиасы в git (вызывать git NAME)
                            git config --global alias.NAME '!... && ...'
                            ЗЫ: Восклицательный знак нужен для добавления в алиас сторонних утилит.
                          +2
                          Использую SourceTree. Продолжаю работать на пенсии
                            0
                            невероятно полезный алиас
                            git add all


                            т.е. это в разы удобнее чем
                            git add *

                            ? Особого смысла не вижу

                            полезнее был бы даже алиас
                            git diff

                            на
                            git diff --color


                            Да и вообще сам синтаксис git достаточно простой, чтобы не страдать никакими алиасами, ну, мне так кажется.
                              0
                              git add, несмотря на название, ещё и может добавлять удаления файлов в индекс. Команда «git add *» не увидит удаленные файлы в корневой директории. Плюс она попытается добавить файлы, которые находятся в .gitignore и будет выдавать предупреждения. Команда «git add -A» решает эти проблемы.
                              0

                              tenhi_shadow


                              Что-то я не понял примера с git add звёздочка . Написать gaa – вот это удобно.


                              Разве цвет не по умолчанию прописан в конфиге Гита? Нет никакой необходимости в этом ключе git diff --color.


                              З.Ы. Промахнулся веткой для ответа.

                                0
                                ну, я про это. Может не сильно корректно написано просто:

                                Добавляем все изменения в индекс алиасом «git add all»:


                                по умолчанию не прописан --color, в RHEL по крайней мере

                                все эти gaa и прочее это, как уже выше заметили, верный способ выстрелить себе в ногу, да и не такая уж и значительная экономия времени, надо сказать.
                                  +1

                                  git commit -a и git commit -am (с алиасами в статье оно же, видимо, gca и gcam) — вот это правда удобно, и позволяет допускать меньше ошибок, что ненужные файлы попадут в коммит

                                  +4
                                  Чего уж тогда не до одной буквы сократили то? «a» — git add all
                                    0
                                    Алиасы безусловно полезны. Есть одно «но»: нужно убедить всех пользоваться одними и теми же алиасами в обязательном порядке, иначе при попытке помочь соседу руки будут через раз набирать автоматом алиас, а после того как он не сработает, выматерившись набирать полную команду.
                                      +4
                                      выматерившись набирать полную команду.

                                      … идти гуглить потому что полная команда за ненадобностью из головы стерлась.
                                        +1
                                        Вознесите хвалу ${GOD_NAME}'у, если не сработает. Вот если сработает, но сделает не то, что вы хотели…
                                        +4
                                        А в течение рабочего дня набираю в среднем ещё 80 команд, обращаясь к этой системе контроля версий
                                        Но зачем продолжать есть кактус, а не интегрировать систему контроля версий с инструментом разработки?
                                        Это окупится при интенсивной работе уже за неделю. Все рутинные действия будут сильно оптимизированы (коммит, пулл, пуш, ресет, смена веток, дифф, лог и т.д.) и станут более наглядными, а в консоль придется лезть только в редких случаях для какого-нибудь филтер-бренча.
                                          +2
                                          Через IDE ощущения не те.
                                            0

                                            Ну, какие-то ощущения хороши для секса (в смысле получения удовольствия, а вы что подумали?), а какие-то для работы (быстро, эффективно, наглядно, без "нелепых телодвижений"). Мне нравится иногда потрогать Гит в консоли, но наглядность работы с индексом и клавиатурные сокращения вместо даже очень коротких команд, которые я имею через честно купленный Смартгит, по мне много лучше подбора магических сокращений, обеспечивающих "самое правильное состояние индекса перед коммитом". Ну и всегда можно посмотреть, что же это была за команда, чтобы при случае применить в консоли или скрипте.
                                            Вот честно, единственное, что не смог сделать в нём — мердж с поддеревом без общих коммитов. Но и тут и консоль без яндекса не завелась, хотя учился это делать по официальным докам.

                                            +1

                                            У меня противоположное мнение. Очень тяжело через Idea работать с Git. И никакой наглядности я там не ощущаю.


                                            Я к тому, что вы субъективно любите менюшки, а кто-то консоль, поэтому что из этого кактус вопрос бессмысленный.

                                            0
                                            Я так и не понял, а какие преимущества дает использование именно zsh по сравнению с bash в контексте работы с git?

                                            Можно привести какую то сводную таблицу. Например, в bash нельзя сделать A. Сделать B можно, но придется выполнить 10 команд, вместо одной в zsh. Или как то так.

                                            Ибо мне после прочтения статьи совсем не понятно, какие же такие преимущества дает zsh (Oh My Zsh) в контексте работы с git в консоли. Или под хаками и продвинутой работой понималось использование алиасов?
                                              +1
                                              Если статья про zsh, то почему в заголовке написано git?
                                                +1

                                                Всё это боловство. Самое полезное сокращение, что есть для гитаэто git-fire :)

                                                  +5
                                                  Как то такое ощущение, когда работа с инструментом превращается в самоцель.
                                                  У меня по работе голова больше забита тем, что я собственно делаю, прикладными задачами.
                                                  А работа с контролем версий это так, один из фоновых инструментов, отнюдь не главный в работе.
                                                  Опять же, как тут упоминали, можно интегрировать контроль версий в IDE и как бы не особо уделять ей внимания.
                                                  Ну, это конечно, я смотрю со своей субъективной стороны, так иногда кажется, что ребятам не хватает работы для работы и они начинают страдать «улучшательством спичек» (по аналогии с «экономией на спичках», сам только что придумал :)).
                                                    0

                                                    Тут вопрос в оптимизации собственных действий. Кто-то обратит внимание, что 10 раз за день выполняет одну и ту же пару-тройку действий и автоматизирует этот процесс (скрипт, алиас, плагин и т.д.), а кто-то и дальше будет повторять одно и тоже. Вопрос внутреннего спокойствия, если хотите. В конце-концов IDE тоже появились из желания сократить или улучшить выполняемые операции.

                                                      0
                                                      Как всегда, наверное, вопрос в балансе.
                                                      Если оптимизируют регулярно выполняемые действия (10 раз в день), то это отлично.
                                                      Опять же, если время потраченное на оптимизацию отобьется в итоге годика за три, то это бессмысленно.
                                                        0

                                                        Ну не только четкими кретериями мир полон. Субъективная оценка тоже роляет. Можно ли ругать разработчика, что он потратил время на переход с одной IDE на другую? Ведь нет четкого критерия, по которому можно оценить, что он стал эффективнее. Однако, возможно ему стало комфортнее жить и он от этого стал лучше работать. Тоже самое и с алиасами в bash/zsh и прочей требухой.

                                                          0
                                                          Особенно хорошо экспериментировать за счет работодателя :)
                                                          Особенно когда нет четкого или приблизительного критерия.
                                                          Собственно мой первый комментарий затрагивал это тему:
                                                          … так иногда кажется, что ребятам не хватает работы для работы...

                                                          Когда разработчик сам дома экспериментирует, осуществляет переходы на другую IDE и прочее, я только приветствую, двумя руками за.
                                                    0
                                                    Не рекомендовал бы изучать гит со статью с алиасами вместо реальных команд. Алиасы это вкусовщина и оптимизация имхо, даже не знаю стоит ли об этом писать в таком ключе.

                                                    Only users with full accounts can post comments. Log in, please.