Git стал стандартом де-факто в мире разработки программного обеспечения. Это мощная система контроля версий, которая позволяет командам эффективно сотрудничать, отслеживать изменения и управлять кодовой базой. Новичку Git может показаться сложным из-за обилия команд и концепций. Однако правда в том, что для выполнения 90% повседневных задач достаточно уверенно владеть небольшим набором ключевых команд.
Хабр, привет! Меня зовут Барилко Виталий, я разработчик / директор / главный идеолог программы Управление IT-отделом 8 и работаю в компании Софтонит. Мы разрабатываем ПО для автоматизации ИТ-отделов. Сегодня хочу поговорить про conventional commits и про свой личный опыт работы с коммитами. На самом деле это бездонная тема, о которую сломано много копий. Кто-то пишет и делает коммиты так, кто-то эдак. В посте попробую поразмышлять о том, как делать не надо и о придуманных на этот счет правилах и договоренностях.
Начинающие (а иногда этим грешат и опытные) разработчики, не до конца понимают принципы создания и работы над коммитами в git. Тут имеется ввиду не механика и команды типа “git commit …”, а общие и глобальные вещи. Например:
1. А когда делать коммиты?
2. Что в них писать?
3. Есть ли какие-то общие правила для их создания?
4. Как не надо коммитить?
Если ты начинающий разработчик, то эта статья точно тебе пригодится. А если у тебя огромный опыт и ты думаешь, что тебя уже ничем не удивить, то… Не будем торопиться… Давай проверим?
Какие настройки git config сейчас следует устанавливать по умолчанию? Ниже рассмотрены избранные настройки, менять которые не стесняются даже разработчики самого Git.
Несколько недель назад я написал о настройке Git help.autocorrect и поведал странную историю о том, как её значение стали задавать в децисекундах.
Эта статья заставила меня поразмыслить и о других настройках git config, вероятно, не известных широкому кругу пользователей. Возможно, для этих настроек стоит задать по умолчанию иные значения, чем действуют сейчас.
В этом посте я разберу некоторые (пожалуй, малопонятные) настройки Git, которые сам активировал во всех моих проектах. Я подробно расскажу о них, поясню, как они действуют, и почему их, пожалуй, стоит выставить по умолчанию.
Также оказалось, что большинство из изложенных здесь знаний я почерпнул из общения с людьми, чей повседневный труд заключается в поддержке ядерной базы кода Git.
Привет! Меня зовут Кирилл, я инженер по разработке инфраструктуры в компании YADRO. Представьте: вы разработчик программного обеспечения в крупной компании и вам потребовалось создать новую виртуальную машину. Как это сделать? Пожалуй, многие ответят, что можно запросить ее через отдельную задачу на ответственную команду DevOps-инженеров, потом подождать, пока за нее возьмутся и вручную создадут ВМ с помощью OpenStack.
Звучит просто, но это только часть пути. От глаз разработчика скрыты шаги по добавлению ВМ в inventory, определению нужных конфигурационных параметров, прогону ansible-ролей и сопутствующей настройке. Иногда и на этом процесс не заканчивается, ведь люди привыкли пользоваться доменными именами, а не ip-адресами. Вручную этот процесс занимает много времени и не лишен влияния человеческого фактора, поэтому возникает необходимости в автоматизации.
Для работы с OpenStack удобно использовать Terraform. Хотя компания Hashicorp прекратила свою деятельность на территории России, нам все еще доступен open source-форк под говорящим названием OpenTofu. К сожалению, достаточно подробной инструкции по работе с ВМ через OpenTofu на просторах интернета найти не удалось, поэтому я и решил создать ее сам, сделав акцент на широте возможностей инструмента.
Как же иногда хочется закинуть коммиты «Remove debug log», «fix» или «fix fix fix». Такие коммиты как грязные носки под кроватью: их не видно, пока не придёт ревьюер с пристальным взглядом или, что еще хуже, потенциальный работодатель, решивший посмотреть на ваш профиль github.
К счастью, Git предлагает два супер-инструмента для того, чтобы история коммитов выглядела так, будто ты всегда знаешь, что делаешь: git commit --fixup и git rebase --autosquash. И сегодня мы разберем на практике как это применять.
Представьте ситуацию: вы нашли критический баг в проекте, исправили его в feature-ветке, но до полного слияния ещё далеко. Или вам срочно нужно перенести одно конкретное изменение из текущей ветки в другую. В таких случаях git cherry-pick становится вашим секретным оружием.
Всем привет! Эта статья продолжение первой, опубликованной раннее Домашний NAS сервер, где была разработана электроника и проведено первоначальное тестирование.
Но, без корпуса использовать данный NAS сервер крайне не удобно и есть риск повредить и сломать его, а также нет должного охлаждения, что тоже негативно сказывается на работе сервера.
В данной статье будут описаны разработка и сборка корпуса, надеюсь будет интересно!
Эта шпаргалка поможет вам быстро и просто составлять сообщения для коммитов, которые соответствуют стандарту Conventional Commits. Она не для обучения или дискуссий о том, нужны ли такие схемы, а служит удобным инструментом🪄, чтобы подсмотреть и сразу написать коммит.
Если интересно, листайте ниже и пользуйтесь!👀
Привет, Хабр! Меня зовут Ольга Лукьянова, я работаю в Yandex Infrastructure, в команде, которая делает системы, сервисы и инструменты для разработчиков. Недавно Яндекс анонсировал новый продукт SourceCraft, который уже собирает вокруг себя сообщество. Последний год я руковожу группой навигации по коду этого проекта.
Мои коллеги на конференциях уже рассказывали про планы развития SourceCraft — платформы от Яндекса для создания исходного кода, управления версиями, тестирования, сборки, развёртывания и сопровождения программных продуктов. А также показывали первый доступный компонент — интеллектуальный помощник для работы с кодом Yandex Code Assistant.
Я открою чуть больше деталей про возможности навигации в нашей платформе, которые появятся в публичном доступе в следующем году и помогут разработчикам не переключаться в IDE, а решать наиболее типовые задачи в одном интерфейсе. В статье — рассказ о том, как мы искали способы добавить функциональность навигации по коду при ревью пул-реквестов и каких результатов уже достигли.
Привет Хабр! Меня зовут Александр Карпов, я работаю в команде защиты приложений ИБ VK. Сегодня я хочу рассказать про наш процесс поиска секретов в каждом коммите в GitLab. У нас, как и у большинства компаний, был классический процесс борьбы с секретами – различные инструменты сканировали кодовую базу, и при обнаружении паролей, токенов и т.д. нам приходилось их ротировать. Главная проблема такого подхода в том, что проверить, действительно ли секрет был инвалидирован, не всегда возможно. По этой причине мы решили, что оптимально будет вычищать кодовую базу от любых секретов.
Это не кликбейт. Мы и правда сделали это! В Microsoft мы работаем с очень большим монорепозиторием, который между собой называем 1JS. Недавно мы достигли 1000 активных пользователей в месяц, около 2500 пакетов и ~20 млн строк кода! Последнее клонирование репозитория вернуло невероятные 178 ГБ.
По множестве причин, это попросту слишком большой размер, некоторые ребята из европы попросту не могут успешно клонировать репозиторий из-за его размера.
Вопрос в том, как это вообще произошло?!
Кому нужная новая VCS, когда уже есть Git, Mercurial, SVN, Perforce, Darcs и прочие? Автор проекта Jujutsu считает, что ещё есть куда рости. Знакомтесь — Martin von Zweigbergk из Google работает над проектом Jujutsu, или для краткости jj.
Чем он лучше чем ваша система контроля версия?
Вот вам карты «возможного» местоположения разработчиков Telegram и React для затравки.
Telegram Desktop. Всего 205 человек. Из них 3 основные. Из них два (работают с 2014 и 2019) в районе Самара-Кавказ (Армения, Грузия, Азербайджан) и один (работает с 2018) вероятно в Турции.
ReactJS. Всего 1854 человек. Основной состав: 14 работает, 26 уволилось. Примерно 50/50 сидят на восточном и западном побережье США.
Недавно я пытался объяснить коллеге, какие у меня критерии при формировании пул реквеста — когда стоит объединять что‑либо в один пул реквест, а когда нет. И я заметил за собой фразу «ну, кроме…» несколько раз и решил записать, как я использую git — чтобы разобраться в особенностях моего подхода, как я мог бы улучшить его и, возможно, поделиться чем‑то полезным.
Поскольку это интернет, давайте сразу обговорим: то, как я использую git основывается на последних 12 годах работы в компаниях с относительно небольшими (до 50 человек) командами. В каждой из них мы использовали только git и GitHub; изменения выполнялись в отдельных ветках, предлагались в виде пул реквестов и сливались в основную ветку. В последние несколько лет, после введения GitHub squash‑merging, мы использовали его.
Я никогда не использовал какую‑либо другую систему контроля версий. Я не могу и не буду сравнивать git с Mercurial, jj, Sapling, и т. д.
Итак, вот как я использую git.
Недавно мы опубликовали в блоге перевод статьи о том, как GitHub заменил SourceForge в роли доминирующей платформы для хостинга кода. Но, как справедливо отметил автор оригинала, его мнение основано на открытых источниках и интервью с коллегами. А потом своим ви́дением поделился один из сооснователей GitHub, Скотт Чакон, который «действительно был там». Под катом — перевод его ответной статьи о реальных причинах победы GitHub.
Линус Торвальдс как-то написал в своей книге, что создавал Linux для развлечения, но в итоге это привело к революции. Git, его второе творение, также оказалось «случайной революцией» — и сегодня это стандартный инструмент для людей в ИТ. Однако процесс его создания был уже не таким «весёлым» — по крайней мере, для самого Линуса.
