Git *

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

Двадцать лет назад

Привет! Я — Алексей Бондаренко, работаю в команде Платформа Банки.ру. Сегодня хочу рассказать о semantic-release и его практическом применении на примере упрощения разработки и внедрения библиотеки в проект. 

Недавно я провела в Mastodon опрос о том, насколько мои читатели уверены в том, что они хорошо понимают работу HEAD в Git. Результаты (на основании примерно 1700 голосов) меня немного удивили:

10% — 100%

36% — достаточно сильно уверен

39% — уверен в некоторой степени

15% — представления не имею

Меня удивило, что люди не уверены в своём понимании: я-то считала, что HEAD — это довольно простая тема.

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

Мы, разработчики ПО, пользуемся git каждый день, однако большинство из нас применяет только самые основные команды, например, add, commit, push и pull, как будто на дворе по-прежнему 2005 год.

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

Считается, что построение CI/CD - задача для DevOps. Глобально это действительно так, особенно если речь идет о первоначальной настройке. Но часто с докручиванием отдельных этапов процесса сталкиваются и разработчики. Умение поправить что-то незначительное своими силами позволяет не тратить время на поход к коллегам (и ожидание их реакции), т.е. в целом повышает комфорт работы и дает понимание, почему все происходит именно так.

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

Я работаю над созданием Graphite, источником вдохновения для которого стал внутренний инструментарий Facebook. Когда я решил создать стартап с друзьями, то никогда раньше не слышал о Mercurial, хотя всегда страстно любил инструменты разработчика. Мой предыдущий опыт разработки включал в себя личные проекты, домашнюю работу в колледже, разработку для iOS в Google и развитие инфраструктуры в Airbnb. На протяжении всей моей карьеры использование git было таким же естественным, как воздух. Он настолько популярен, что лично я считал его единственным подходящим инструментом для создания изменений в коде и управления ими.

Забавно, что специалист по Mercurial Грегори Gregory Szorc работал рядом со мной в Airbnb, хотя я знал его только как приятного коллегу, но не представлял, что он контрибьютор.

В 2021 году мои коллеги по команде Томас и Ник раскрыли мне глаза. Они пришли из Facebook и, к моему удивлению, едва знали Git. Зато они имели глубокое понимание паттернов Mercurial и рабочего процесса Facebook на основе «многослойных diff» (stacked diff). Со временем они убедили меня в полезности этого паттерна и мы развернули направление развития компании, чтобы реализовать многослойные diff для разработчиков GitHub.

Но пост посвящён не нашему стартапу. Он о важном вопросе, не дававшем мне покоя последние три года. Почему фейсбукеры не пользуются Git? Зачем они выбрали Mercurial и создали на его основе собственные рабочие процессы? Я знаю что Google не пользуется Git, но это логично, культура разработки Google возникла на пять лет раньше Git. Facebook же был основан примерно в то же время, что и создан Git, около 2004 года, и ко времени, когда Facebook начал серьёзно выбирать инструментарий для управления исходниками, Git был старше и популярнее Mercurial. Так почему же Facebook не использует Git?

Первый раз столкнулись с Git и не понимаете, что это такое?

Устали бездумно выполнять серию комманд чтобы закинуть свой проект на GitHub?

Хотите понять, чем отличается merge, rebase, push и pull?

Надоело видеть ошибку о non fast-forward merge и не понимать, что с этим делать?

Сейчас попробуем разобраться в этом всем.

Привет! Я всегда мечтала, чтобы в инструментах для работы с командной строкой заранее сообщалось, насколько популярны те или иные конфигурационные опции, предусмотренные в них, например:

o    «В принципе, никто этим не пользуется»

o    «Этой опцией пользуется 80% аудитории, стоит ознакомиться»

o    «У этой опции предусмотрено 6 возможных значений, но в реальной практике применяется всего 2 из них».

Так что я решила спросить пользователей Mastodon, какие у них любимые опции конфигурации git:

А какие опции git config вы больше всего любите выставлять? В настоящее время у меня в ~/.gitconfig установлены только git config push.autosetupremote true и git config init.defaultBranch main, вот интересуюсь, а что выставляют другие люди.

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

Далее перечислю их по порядку, при этом (очень примерно) попытаюсь начать с наиболее популярных.

Все описанные опции документированы на странице man git-config, а также на этой странице.

Автор оригинала Скотт Чакон — сооснователь GitHub и основатель нового клиента GitButler. Этот клиент ставит во главу угла рабочий процесс и удобство разработки, в том числе код-ревью, и не является просто очередной обёрткой над CLI git.

Вам хочется использовать ванильный Git, чтобы управлять репозиторием с объёмом 300 ГБ в 3,5 млн файлов, которые без проблем получают пуш каждые 20 секунд от 4000 разработчиков? Тогда читайте дальше!

Вот агенда блога — наша блогенда:

• Предварительное извлечение.
• Граф коммитов.
• Монитор файловой системы.
• Частичное клонирование.
• Разреженный checkout.
• Scalar.

Автор оригинала Скотт Чакон — сооснователь GitHub и основатель нового клиента GitButler. Этот клиент ставит во главу угла рабочий процесс и удобство разработки, в том числе код-ревью, и не является просто очередной обёрткой над CLI git.

Далее в нашей серии постов из трёх частей у нас новые фичи! Здесь я расскажу про пять относительно новых вещей в git, о которых вы могли не слышать, потому что ну почему вы?

Мы взглянем на:

• Штуки с git branch.
• Принудительный безопасный пуш.
• Подписывание коммитов ключом SSH.
• Подписывание пушей.
• Обслуживание Git.

Автор оригинала Скотт Чакон — сооснователь GitHub и основатель нового клиента GitButler. Этот клиент ставит во главу угла рабочий процесс и удобство разработки, в том числе код-ревью, и не является просто очередной обёрткой над CLI git.

Далее в нашей серии постов из трёх частей у нас новые фичи! Здесь я расскажу про пять относительно новых вещей в git, о которых вы могли не слышать, потому что ну почему вы?

Мы взглянем на:

• Штуки с git branch.
• Принудительный безопасный пуш.
• Подписывание коммитов ключом SSH.
• Подписывание пушей.
• Обслуживание Git.

Автор оригинала Скотт Чакон — сооснователь GitHub и основатель нового клиента GitButler. Этот клиент ставит во главу угла рабочий процесс и удобство разработки, в том числе код-ревью, и не является просто очередной обёрткой над CLI git.

В первом посте из этой короткой серии по Git я хотел начать с вещей, уже существующих какое-то время. При этом кажется, что многие люди о них не знают или не умеют ими пользоваться. В них нет ничего нового, но я нахожу их полезными и, возможно, не совсем освещёнными. Я просто хочу рассказать о:

• условной конфигурации;
• git blame и git log с диапазонами строк;
• git blame с отслеживанием;
• git diff по словам вместо строк;
• запоминании разрешения конфликтов.

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

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

Привет, Хабр! Мы системные инженеры X5 Tech — Алексей Кузнецов и Борис Мурашин. У нас за плечами больше 15 лет опыта, в том числе поддержка сервисов Rapida, CyberPlat, TeleTrade, сопровождение стека BigData и внедрение кластеров Hadoop. В этой статье мы расскажем, как выбирали систему управления конфигурациями, какими критериями руководствовались, что в итоге выбрали, с какими проблемами столкнулись и как их решали.

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

Небольшой обзор систем контроля версий, альтернативных git, и основанных на математической теории. Речь пойдёт о двух системах распределённого контроля версий: Darcs, написанной на Haskell, и Pijul, написанной на Rust. Обе они сейчас активно развиваются и предлагают свои сетевые репозитории. Оказалось, что про них на Хабре толком нет ничего, тогда как про git образовался целый хаб. Поскольку я люблю и использую Haskell, я остановил свой выбор на Darcs, и вот, спустя два месяца непрерывной работы над библиотекой геометрической алгебры для hackage, я готов поделиться впечатлениями от её использования.

Rust же создавали, чтобы держать программиста в ежовых рукавицах? Так почему бы не заставить git скооперироваться с Rust и не издеваться над программистом на пару?

На самом деле статья не сколько про Rust, сколько про git, поэтому если вы не особо знакомы с Rust, не смущайтесь сильно — повествование будет скорее про флоу разработки нежели чем про язык. Rust в статье выбран скорее за его удобный пакетный менеджер cargo, который сделает суть повествования лаконичнее и нагляднее.

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

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

«Какого же размера он должен быть? Бывает ли идеальный размер? Если бы теоретически можно было полностью его контролировать, то насколько большим его нужно делать?»

Вы гуглите, находите множество ресурсов, сайтов и статей наподобие этой, которые анализируют тему и делают примерно такой вывод:

«Слишком маленькое количество строк может не отображать полностью изменения, а чрезмерно большой PR может утомить проверяющих, что усложнит выявление проблем или написание осмысленного отзыва»

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

Однако моя статья будет немного о другом:

«Мы проанализируем PR примерно 30 тысяч разработчиков, чтобы проверить, как размер PR коррелирует с временем внедрения, полученными комментариями и отказами во внесении изменений, чтобы найти статистически наилучший размер и понять, что на него влияет.»

Пояснение: тем, кто экспериментирует с данными, особенно после прохождения курсов/обучения в сфере данных, приведённое выше может напомнить о фразе «Корреляция не означает причинно-следственной связи». Да, они будут абсолютно правы. Мы попытаемся рассмотреть под разными углами, как эта корреляция варьируется в зависимости от компании, разработчика и общего объёма коммитов кода, а также под другими углами, которые могут помочь нам понять, какие другие значения могут по каким-то причинам отвечать соответствующим паттернам. Однако это «всего лишь» числа и корреляции, они не объясняют своих причин, поэтому любые наши предположения о причинах, скорее, субъективны и не подтверждены научными исследованиями.

Сегодня мы затронем сторону, отличную от написания кода. Мы займемся оформлением и написанием документации, как правильно делать коммиты и как оформлять код.

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

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

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