Введение ¶

Часто используемые мною команды и пояснения к ним. Надеюсь будет кому-то так же полезно как и мне.

Основное ¶

В Git есть встроенный графический интерфейс ¶

Gitk - простой встроенный графический интерфейс. Мне очень нравится из-за своей точности и наглядности. Я стараюсь не пользоваться какими-либо Git UI и всё делаю командами, а эта и так работает только в режиме просмотра.

1. Дерево коммитов с тегами и ветками
2. Хеш выбранного коммита из дерева
3. Список изменённых файлов в этом коммите
4. Переключатель режима diff
5. Сам diff из коммита с его описанием в начале

На Manjaro кроме самого Git, нужно поставить ещё и tk, тогда заработает. Как на других дистрибутивах - не знаю.

1

pacman -Sy git tk

Как обновлять настройки окружений основываясь на diff-е нового окружения ¶

Тут вот какой момент. У меня в инфраструктурном репозитории есть, к примеру, values для Helmfile окружений Development и Production.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

.
├── development
│   ├── main.yaml
│   └── values
│       ├── cert-manager.yaml.gotmpl
│       ├── external-secrets.yaml.gotmpl
│       ├── fluentbit.yaml.gotmpl
│       ├── kube-prometheus-stack.yaml.gotmpl
│       ├── loki.yaml.gotmpl
│       └── promtail.yaml.gotmpl
└── production
    ├── main.yaml
    └── values
        ├── cert-manager.yaml.gotmpl
        ├── external-secrets.yaml.gotmpl
        ├── fluentbit.yaml.gotmpl
        ├── kube-prometheus-stack.yaml.gotmpl
        ├── loki.yaml.gotmpl
        └── promtail.yaml.gotmpl

5 directories, 14 files

И вот разрабатывал я разрабатывал новые приложения, менял настройки в development и теперь мне нужно всё то же самое перенести в production. Чтобы не вспоминать все мелочи где что нужно поменять делаю следующее.

1. Переходим на ветку с актуальным development

1

git checkout development

2. Смотрим когда последний раз менялся production

1

git log -n 1 --oneline -- ./production

Здесь ./production это путь к папке, изменения по файлам которой нас интересует. Можно конкретный файл указать или несколько источников. В данном случае мы получим хеш самого последнего коммита, в котором что-либо менялось в production.

3. Смотрим изменения с этого момента и по сей день

Теперь нам нужно отследить все изменения с момента последней версии production по текущий момент, который является актуальным development.

1

git diff 493d3aa..HEAD -- ./development

Хеш 493d3aa это тот самый, который я получил в прошлом пункте для production.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

diff --git a/development/values/cert-manager.yaml.gotmpl b/development/values/cert-manager.yaml.gotmpl
index 493d3aa..cb34bd2 100644
--- a/development/values/cert-manager.yaml.gotmpl
+++ b/development/values/cert-manager.yaml.gotmpl
@@ -34,7 +34,8 @@ asdf:
     alpha: cert-manager-a
   contextKey:
     beta: something-else
-    key: json
+  someSetting:
+    subkey: cert-manager-example
   urls:
     api: {{ quote .Values.apiURL }}
     web: {{ quote .Values.webURL }}

Таким образом, мы теперь можем в ручном режиме перенести все интересующие нас изменения в production и ничего не потерять.

Как искать пароли и чувствительные данные используя поиск по коммитам ¶

У Git есть встроенный поиск по файлам в коммитах. Можно использовать регулярные выражения для поиска секретный данных. Это применимо в отдельных ручных операциях, но намного правильнее будет настроить и постоянно иметь Gitleaks или Trivy.

1
2

git rev-list --all | \
xargs git grep -irnE '"type":\s*"service_account"'

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

Rebase стратегии ¶

Когда нужно выполнить rebase кучей конфликтов и ты точно знаешь, что тебе просто нужно оставить всё как есть в текущей\целевой ветке, то можно сделать так.

1. Убеждаемся, что наша локальная ветка (которую мы будем rebase-ить) запушена и такая же как в облаке

Для чего это нужно? Для самоконтроля. К примеру, у меня задача сделать rebase development ветки на main да так, чтобы она не поменялась, просто перенести. Если на момент начала переноса я проверил, что diff-a origin/development у меня нет, то после переноса, я смогу сравнить git diff origin/development..development и там так же должно быть пусто.

1
2

git pull
git push

2. Выполняем одну из операций ниже

1
2

git rebase -i --strategy=ort -Xtheirs main --empty=keep
git rebase -i --strategy=ort -Xours main --empty=keep

Git разрешит все конфликты в пользу одной из веток, в зависимости от ours или theirs.

Как сбросить локальную ветку до состояния облачной, если кто-то пушил с форсом ¶

Тут всё довольно просто. К примеру, мы работаем на development.

1. Переходим на ветку

1

git checkout development

2. Делаем git fetch

1

git fetch --all

3. Делаем reset

1

git reset --hard origin/development

Всё, наша ветка точно такая как облаке.