Git *

Не только разработчикам-новичкам, но и ярым профессионалам приходится прибегать к отмене каких-либо изменений. И тогда, первое, что приходит на ум, — это команда git revert, как самый безопасный способ. И тут есть подводные камни, про которые я хочу рассказать.

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

• Реализовать арифметические операции (сложение, вычитание, деление и т.д.)
• Реализовать числовые операции (максимальное значение, минимальное значение, модуль числа и т.д.)

Проверять будет проще да и тестировать. Но он уже начал ее реализовывать, коммиты уже созданы, и что же делать? Не переписывать же!

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

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

В результате локальная ветка законченной задачи выглядит примерно так:

Во время пандемии я, честно говоря, не собиралась изучать Linux, не думала, что умение работать в этой ОС сделает меня продуктивнее. Но, как оказалось, Linux-навыки, и правда, помогают мне быстрее справляться с делами. Всё началось с того, что мне посоветовали «взглянуть на Linux». Я тогда подумала, что делать мне, всё равно, нечего, да ещё и сентябрьский выпуск #IBelieveinDoing оказался как раз о Linux.

Я почувствовала, что всё у меня получится, и отправилась в путешествие по миру Linux. В том выпуске #IBelieveinDoing были уроки не только по Linux, но и по Git. Между этими системами можно провести некоторые параллели. Linux — это опенсорсная ОС, которой пользуются программисты, а Git — это система управления версиями, которую применяют для отслеживания изменений в исходном коде при разработке программ. Надо отметить, что изучение Linux и Git оказалось весьма увлекательным занятием. Но Git — довольно сложная система, поэтому и освоить её основы было тяжелее, чем основы Linux.



В этом материале я хочу поделиться с вами тем, что узнала, осваивая Linux и Git.

Одно из первых наставлений, которое молодой падаван получает вместе с доступом к git-репозиториям, звучит так: «никогда не ешь жёлтый снег делай git push -f». Поскольку это одна из сотен максим, которые нужно усвоить начинающему инженеру-разработчику ПО, никто не тратит время на уточнение, почему именно так нельзя делать. Это как младенцы и огонь: «спички детям не игрушки» и баста. Но мы растём и развиваемся как люди и как профессионалы, и однажды вопрос «а почему, собственно?» встаёт в полный рост. Эта статья написана по мотивам внутреннего митапа на тему: «Когда можно и нужно переписывать историю коммитов», который я проводил, когда работал в компании FunCorp.

В статье ранее (на португальском) я рассказал, как создать полнофункциональный бэкенд GraphQL, используя только образ Docker и файл конфигурации. Все это можно найти на сайте Azure. А сейчас давайте поговорим о том, как автоматизировать развертывания, созданные для нашего хостинга, и обновления нашей серверной части!

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

Вместо этого мне бы хотелось, чтобы с каждым push в главной ветке генерировалась новая версия файла и обновление отправлялось на сайт Azure. Однако я не хочу использовать для этого другие инструменты. Мне бы хотелось, чтобы весь стек был максимально простым, так как мы пользуемся только GitHub и Azure. Нет ничего проще, чем продолжать пользоваться GitHub для автоматизации, верно?

Вот почему мы будем использовать GitHub Actions

Файлы проиндексированы, написано сообщение коммита, данные отправлены на сервер… И вдруг хочется повернуть время вспять. В коммит попал файл, которого там быть не должно. Когда такое случается, приходит время обращаться к поисковику.

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

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

Удаление файлов с конфиденциальной информацией из Git-репозитория (изображение большого размера)

В State Of DevOps 2018 от DORA мы видим, что Нigh Performing компании используют Trunk Based Development. Разберемся, почему именно ее, какие ее преимущества и недостатки имеет эта модель.

DevSecOps помогает командам обнаруживать и устранять неисправности и уязвимости на ранних стадиях разработки ПО. В GitLab 13.3 создавать безопасное программное обеспечение стало проще благодаря тестированию фаззингом, интегрированному в ваш рабочий процесс разработки. Фаззинг-тестирование, направленное на полное покрытие кода, вместе с запуском DAST (динамического тестирования безопасности приложений) по требованию помогут обнаруживать реальные уязвимости программного обеспечения быстрее и эффективнее. Кроме того, с новой матрицей сборки для CI/CD станет проще выпускать релизы более часто. Наконец, панель состояния подов повысит эффективность работы специалистов по эксплуатации за счёт сокращения переключений контекста: все данные о состоянии подов Kubernetes теперь находятся в одной панели. Мы надеемся, что вам понравятся основные фичи релиза, а также ещё 69 новых фич, включённых в этот релиз.

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

В большинстве случаев требуется типовая задача: "сгенерировать YAML и положить его в Kubernetes". Собственно, с чем Argo CD замечательно и справляется.

Argo CD позволяет подключить Git-репозиторий и синкать его состояние в Kubernetes. По умолчанию есть поддержка нескольких видов приложений: Kustomize, Helm чарты, Ksonnet, голый Jsonnet или просто директории с YAML/JSON манифестами.

Большинству пользователей этого набора будет достаточно, но не всем. Для того чтобы удовлетворить потребности всех и каждого в Argo CD имеется возможность использовать custom tooling.

В первую очередь интересует возможность добавления поддержки qbec и git-crypt, которые с полна были рассмотренны в предыдущей статье.

Disclaimer: Эта история произошла несколько лет назад. Но кажется, что она и до сих пор не утратила актуальности.

… Мы разрабатывали Gardenscapes. В нём всё ещё оставались следы старого Gardenscapes под Windows. Он даже был не Match-3, а Hidden Object. И никто даже и представить не мог высот, которых достигнет игра.

И вот в один прекрасный день…

Смотрите сами: вот проект, вот история коммитов.

Список контрибьюторов с главной страницы репозитория:

Ссылки на аватарках ведут на странички профилей реальных людей.

Всё на месте. Кроме плашечки "Verified" как здесь:

---

Знатоки Git и GPG, не торопитесь проматывать ленту: эта статья не про необходимость подписывать свои коммиты. Она про неявные допущения, которые мы делаем, пользуясь "интуитивно-понятными" монстрами GitHub и GitLab и доверяя им контроль доступа к нашим репозиториям.

Каждой предоставляемой услугой Selectel можно управлять в личном кабинете — панели управления. Многими нашими продуктами также возможно управлять через запросы к API. Инструкции по работе с продуктами и документация API доступны в едином справочном центре.

Основная идея справочного центра — предоставить нашим клиентам возможность в любое удобное для них время самостоятельно найти ответы на большинство интересующих их вопросов об услугах Selectel.

Далее расскажем о том, как мы изменили подход к подготовке документации и обновили внешний вид базы знаний.

GitLab 13.2 помогает командам управлять планированием проектов с итерациями майлстоунов, улучшать совместную работу для более быстрого реагирования с диффами для вики-страниц и общую производительность и эффективность с нагрузочным тестированием производительности.

Доброго времени суток, читатель!

22 апреля в GitLab выпустили релиз 12.10 и сообщили о том, что теперь CI-процесс может авторизовываться в Hashicorp's Vault через JSON Web Token (JWT), и для авторизации нет необходимости хранить токен для доступа к нужным policy в переменных окружения (или где-либо ещё).

Данная фича показалась нам полезной, поэтому предлагаем перевод соотвествующего туториала из официальной документации GitLab:

*"ублюдок" — вольный перевод слова "git" — "an unpleasant or contemptible person", "неприятный или презренный человек".

В комментариях к статье 15 базовых советов по Git для эффективной работы каждый день развернулась дискуссия на тему эффективности использования тех или иных команд и опций. Надо признать, что git предоставляет столько различного функционала, что во-первых, за всем становится невозможно уследить, а во-вторых, его можно совершенно по-разному вписывать в рабочий процесс.

Давайте посмотрим, что можно использовать, чтобы улучшить себе жизнь. Статья предполагает, что читатель умеет пользоваться основными возможностями git и понимает что делает, когда, скажем, вводит в консоль git rebase --merge --autostash.

Привет, меня зовут Сергеев Сергей aka gurugray. Сейчас я «Mentor FrontEnd Community» в компании ManyChat. Вы могли видеть мои лекции по релизному циклу и регламенту работ с системами контроля версий в Школе Разработки Интерфейсов Яндекса (ШРИ).

Меня часто спрашивают какие life-hacks или best-practices я использую при работе с Git'ом и репозиториями проекта.

Эта заметка — попытка объяснить те базовые настройки и приёмы, которыми я пользуюсь каждый день. Рецепты не претендуют быть ноу-хау, но могут помочь с освоением ежедневной гигиены работы с репозиторием.

Релиз GitLab 13.1 уже доступен! Улучшения нового релиза включают расширенное управление уведомлениями и инструменты, которые помогут вам контролировать и улучшать качество кода, а также другие способы поддержания безопасности и соответствия вашего кода требованиям.

Привет, хабр! Продолжаю делиться полезными подборками. Я уже публиковал посты с Github репозиторими (Часть 1 и Часть 2), а также подборку из 10 книг для разработчиков. Решил, не останавливаться:) Кому интересно — добро пожаловать под кат.

Git hooks – инструмент, помогающий держать в порядке ваш репозиторий. Можно настроить автоматические правила оформления ваших коммитов.

Все вы наверное знаете про pre-commit — проверку вашего кода перед коммитом. Но ведь не все можно проверить перед коммитом. Некоторые ограничения хочется использоваться глобально на всем Gitlab.

Кто запутался в pre-commit и pre-receive хуках, в этом посте описываются различия между ними в абзаце "What are git hooks?".

Если у вас Gitlab Enterprise Edition, вы можете настроить хуки, которые описаны в посте через WEB интерфейс.

Но что делать, если у вас Gitlab Community (Core) Edition?

В этой статье будут описаны 5 pre-receive хуков, которые выполняются на сервере Gitlab Community (Core) Edition:

• block_confidentials.sh — Блокирование отправки приватных ключей и AWS токенов
• block_file_extensions.sh — Блокирование отправки архивов (Regex настраивается)
• check-large-files.sh — Блокирование отправки больших файлов (Размер настраивается)
• reject-not-allowlist-email.sh — Блокирование коммитов с email не из allow списка (Список email доменов настраивается)
• require-issue.sh — Блокирование коммитов без issue в названии (Список issue настраивается)

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



Изучение исходников в репозитории позволяет оценить уровень безопасности приложений. Но если никто не смотрит на код, проблемы будут только расти. К счастью, у GitHub есть свои специалисты по безопасности, которые недавно обнаружили трояна в нескольких репозиториях Git. Его почему-то не заметили сами владельцы этих репозиториев. Хотя мы не можем диктовать другим людям, как управлять своими собственными хранилищами, мы можем учиться на их ошибках. В этой статье мы рассмотрим полезные приёмы работы с репозиториями.