Git + IT

Пост может дополняться и изменяться🙂

Патч - это текстовый файл, который содержит код и (необязательно) метаданные коммита. Патчи используются в некоторых проектах, например, в Linux Kernel и самом Git. Или в командах, которые работают над форками одного и того же open source продукта, но имеют изолированные репозитории.

Создание патча

Создать патч с не закомиченными изменениями:
git diff > <name>.patch

Создать патч только с проиндексированными, но не закомиченными изменениями:
git diff --cached > 0001_fix.patch

Создать патч для последнего коммита:
git format-patch -1

Создать патчи для всех коммитов, сделанных после последних N коммитов:
git format-patch HEAD~<число>

Создание патча для изменений между двумя коммитами:
git diff <commit1> <commit2> > 0001_commit_diff.patch


Применение патча

Применить патч и не создавать коммиты:
git apply 0001-fix.patch

Применить патч и создать коммиты. Работает, если патчи были созданы с помощью git format-patch:
git am 0001-fix.patch

Применить все патчи сразу можно только с помощью git am. Патчи должны быть пронумерованы в порядке применения и должны храниться в одной директории:
git am *.patch


Конфликты при наложении патчей

В случае использования git apply конфликты разрешаются вручную, процесс также продолжается вручную.
В случае использования git am конфликты разрешаются вручную. После исправления конфликтов процесс можно продолжить:
git am --continue

или прервать:
git am --abort

Технические посты тут t.me/neverending_cpp

Я надеюсь, что да, но на всякий случай приведу несколько распространенных рекомендаций по оформлению коммитов. Если я что-то упустил, жду вас в комментариях.
🔹Длина заголовка коммита не должна превышать 50 символов
Это сделано исключительно для удобства чтения журнала проекта.
🔹Формат заголовка коммита зависит от соглашений в конкретной команде.
В разных проектах разные требования к формату заголовка. Например, есть требование в начале заголовка размещать номер тикета: "WTF-42: some question fix". Или же в начале заголовка указывать компонент, в который были внесены изменения "tests: unit: add some question test". Точка в конце заголовка не ставится.
🔹Заголовок коммита содержит краткое описание проделанных изменений.
Заголовок коммита должен отвечать на вопрос: какие изменения были сделали в проекте? Не более. Подробности и причины сделанных изменений нужно перенести в тело коммита.
🔹Между заголовком коммита и телом нужно оставлять пустую строку.
Очередная рекомендация, которая повышает читаемость журнала. В консоли эта рекомендация не сильно заметна, а вот GitLab и GitHub с помощью пустой строки умеют отображать заголовок коммита и скрывать его тело.
🔹Тело коммита не ограничено, а вот строка в теле коммита не должна превышать 72 символа.
Тело коммита не является обязательным, но его наличие позволяет без изучения кода лучше понять, что и почему было сделано. Т.е. если был исправлен баг, то нужно описать условия при которых он проявлялся и каким образом был исправлен. Если новая фича, нужно написать на основе каких требований она была добавлена. Можно приложить ссылки на спецификации, обсуждения, но нужно быть уверенным, что ссылки останутся актуальными через несколько лет. Важно: не нужно писать в теле коммита, как вы делали задачу.
🔹Уточните, нужно ли подписывать коммит.
Чаще всего это требование встречается при работе с open source продуктами. Коммит подписывается с помощью закрытого ключа, таким образом, вы подтверждаете вашу идентичность.

p.s.: а еще шаблон коммита можно прописать в git pre-commit hook

Технические посты тут t.me/neverending_cpp

Эх, воспоминание разблокировано.

Работал я тогда инженером в одном региональном банке. Часть софта была от внешних вендоров, и они же поставляли обновления. Выглядело это так: на неделе тебе присылают само обновление и мануал с его установкой. А так-как банк - контора важная, шатать его системы можно только тогда когда они никому нафиг не нужны. Самое удобное время это 2-4 часа ночи в воскресенье. Если что идет не так всегда есть инженер вендора которому можно позвонить.

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

Запускаю локальный бэкап, потом его проверку, линуксовая консоль плюется радостными строчками "усе окэй". И поехали....

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

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

И в одном из скриптов так же как в посте есть rm -rf тут был путь/*. Скрипт пошел...и мой сонный мозг понимает что удаляющиеся файлы находятся совсем не там где хотелось бы.

Пару мгновений на протупиться...прерывание скрипта. Сервак зачищен от корня процентов на 60... пользовательских директорий со всеми временными бэкапами как не бывало.

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

Дальше были звонки из серии "Наташа мы там все уронили" начальству. Я молодой и зеленый стоя в курилке думал "Нууу на время поиска работы денег должно хватить". Потом восстановление с нуля всего утраченного в ручном режиме. Как итог в ПОНЕДЕЛЬНИК в 14 00 я вышел из офиса, начальник отправил отсыпаться.

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

Привет, Пикабу! Сегодня я расскажу вам историю, от которой у любого программиста волосы встанут дыбом. Это история о том, как одна маленькая ошибка привела к гигантским последствиям.

1. Дело было в 2016 году. Главный герой - разработчик по имени Марвин (имя изменено), работавший в хостинг-провайдере Gitlab.

2. Gitlab - это платформа для хранения исходного кода проектов, которой пользуются миллионы разработчиков по всему миру.

3. У Gitlab случилась небольшая проблема с производительностью базы данных. Марвин решил её починить.

4. Он собирался удалить временную базу данных на одном из серверов. Команда была простая: rm -rf /var/lib/postgresql/9.6/pg_xlog/*

5. Но случилось страшное - Марвин случайно запустил эту команду НЕ на том сервере!

6. Результат? 300 ГБ данных пользовательских проектов были моментально и безвозвратно удалены.

7. Осознав ошибку, Марвин немедленно остановил процесс. Но было уже поздно - данные исчезли.

8. Команда Gitlab бросилась восстанавливать данные из резервных копий. И тут выяснилось, что система резервного копирования... не работала последние 6 месяцев!

9. 18 часов непрерывной работы, паники и стресса. Инженеры Gitlab пытались спасти то, что осталось.

10. В итоге им удалось восстановить большую часть данных, но около 5000 проектов были потеряны навсегда.

11. Gitlab проявила удивительную прозрачность в этой ситуации. Они вели прямую трансляцию процесса восстановления и открыто рассказали о случившемся.

12. Несмотря на ошибку, Марвина не уволили. Компания признала, что проблема была в системе, а не в конкретном человеке.

Мораль истории:

1. Всегда дважды (а лучше трижды) проверяйте, на каком сервере выполняете команды.

2. Регулярно проверяйте работу системы резервного копирования.

3. Ошибки случаются со всеми, даже с профессионалами.

4. Прозрачность и честность могут спасти репутацию даже в самой сложной ситуации.

P.S. После этого случая Gitlab значительно улучшила свои системы безопасности и резервного копирования. А Марвин, говорят, до сих пор трижды проверяет каждую команду перед выполнением.

А у вас были случаи, когда маленькая ошибка приводила к большим последствиям? Расскажите в комментариях!

UPD уточнение: #comment_324862867

Рабочий бэкап сделанный за 6 часов

Они не теряли 5000 проектов навсегда, чё за выдуманная хрень, они потеряли изменения, комменты и тд сделанные в 5000 проектах в течение этих 6 часов

On January 31st 2017, we experienced a major service outage for one of our products, the online service GitLab.com. The outage was caused by an accidental removal of data from our primary database server.

This incident caused the GitLab.com service to be unavailable for many hours. We also lost some production data that we were eventually unable to recover. Specifically, we lost modifications to database data such as projects, comments, user accounts, issues and snippets, that took place between 17:20 and 00:00 UTC on January 31. Our best estimate is that it affected roughly 5,000 projects, 5,000 comments and 700 new user accounts.

https://habr.com/ru/companies/slurm/articles/321074/
https://about.gitlab.com/blog/2017/02/10/postmortem-of-datab...
https://about.gitlab.com/blog/2017/02/01/gitlab-dot-com-data...