Git *

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

Open Source — это не просто способ создания программного обеспечения, а целая культура инноваций, сотрудничества и обмена знаниями. Каждый, кто хочет внести свой вклад в эту динамичную среду, может сделать это вне зависимости от своего опыта или уровня технических навыков.

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

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

Это не кликбейт. Мы и правда сделали это! В Microsoft мы работаем с очень большим монорепозиторием, который между собой называем 1JS. Недавно мы достигли 1000 активных пользователей в месяц, около 2500 пакетов и ~20 млн строк кода! Последнее клонирование репозитория вернуло невероятные 178 ГБ.

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

Вопрос в том, как это вообще произошло?!

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

Кому нужная новая VCS, когда уже есть Git, Mercurial, SVN, Perforce, Darcs и прочие? Автор проекта Jujutsu считает, что ещё есть куда рости. Знакомтесь — Martin von Zweigbergk из Google работает над проектом Jujutsu, или для краткости jj.

Чем он лучше чем ваша система контроля версия?

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

Итак, небольшое вступление. Когда мне впервые пришлось делать коммит на GitHub, я помню, что перерыла кучу источников, и везде все было как-то не так, как в итоге сделала я.

В этой статье я расскажу о том, как сделать первый коммит на GitHub, и как делать последующие. Только мой опыт и сочетание консоли и фич IntelliJ Idea + у меня mac os, поэтому здесь именно про него (важно для установки).

Погнали.

Привет, я Александр, разработчик из команды Битрикс24. В этой статье разбираюсь в особенностях распределенной системы управления версиями Mercurial. Хотя она появилась одновременно с Git и похожа на него внешне, успеха достичь не смогла. Почему так получилось, как она работает, для каких проектов подходит — обо всем ниже. 

Вот вам карты «возможного» местоположения разработчиков 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, его второе творение, также оказалось «случайной революцией» — и сегодня это стандартный инструмент для людей в ИТ. Однако процесс его создания был уже не таким «весёлым» — по крайней мере, для самого Линуса. 

Привет, Хабр! Если вы давно искали подборку полезных статей по Git и Gitflow — загляните в блог beeline cloud. Здесь я делюсь личным опытом, погружаюсь в задачи из практики и даю развернутые комментарии на конкретную тему. 

И да, меня по-прежнему зовут Николай Пискунов, я руководитель направления Big Data. Сегодня поговорим о том, что делать, если баг, несмотря на усилия тестировщиков, все же попал в прод.

Привет! Меня зовут Константин Белкин, я Teamlead SRE в РСХБ‑Интех. Сегодня расскажу вам, что такое CI/CD на платформе App.Farm, какие методологии мы используем в работе, как работает платформа, какие инструменты мы предоставляем разработчикам и каким образом мы организовали CI/CD в РСХБ для наших любимых разработчиков.

Если и есть инструмент, который на 100% обязаны освоить все слушатели ИТ‑курсов и начинающие разработчики еще в начале карьеры — то это Git. Книга «Изучаем Git: пошаговое руководство с наглядными примерами» (Learning Git. A Hands‑On and Visual Guide to the Basics of Git) от издательства O'Reilly Media, в переводе от Alist (БХВ Петербург) — это руководство «с нуля» по самой популярной системой контроля версий. Изложены основы Git: установка, графический интерфейс и командная строка, локальные репозитории и коммиты, ветки и слияния.

Всем привет! Если вы работаете с Kubernetes, то, скорее всего, используете kubectl, kustomize или Helm для развёртывания сервисов в кластере. Про последнюю утилиту я уже писал статью — можно посмотреть тут. Тогда я рассказал о своём опыте внедрения этого инструмента для собственных нагрузок и сравнил подходы kubectl apply и helm install.

Управление конфигурацией в Kubernetes может осуществляться с помощью различных инструментов. Помимо Helm, можно использовать просто YAML-манифесты или же kustomize. Для каждого из этих инструментов предусмотрена своя команда.

В данной статье мы рассмотрим подход GitOps для K8s-кластеров и применим такой инструмент, как Argo CD.

Всё уже придумано, просто настрой под себя и пользуйся.

Всем привет, я Дмитрий Валеев — DevOps инженер в команде разработки фреймворка для тестирования устройств на заводах Аквариус. И это моя первая маленькая статья на Хабр:)

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

В GitLab CI пайплайны выполняют основную роль в автоматизации процессов CI/CD. Они позволяют разбить весь процесс сборки, тестирования и деплоя на отдельные, логически связанные задачи — или "джобы". Эти джобы структурируются в стадии, каждая из которых представляет собой определенный этап работы — например, сборка, тестирование или развертывание. Такое разделение позволяет ускорить разработку и минимизировать ошибки при доставке кода на продакшн.

В этой статье рассмотрим, как настроить пайплайн с разделением на стадии в GitLab CI.

Мы постоянно используем высокоуровневые команды git, такие как git add и git commit. Однако также существует другая группа команд git, которые обрабатывают низкоуровневые операции.

В этой статье мы создадим git‑коммит, используя низкоуровневые операции, а не команду git commit.

Меня зовут Дмитрий Прохоров, я пентестер из команды CyberOK. Часто на проектах по пентесту, а также в программах Bug Bounty встречаются Gitlab-ы. И встречаются они не только специалистам по ИБ, но и злобным хакерам, которые не прочь завладеть секретами репозиториев и даже исполнить код на сервере!

Сегодня я бы хотел посвятить свой монолог тем, кто любит приоткрывать завесу тайн своего Gitlab через функционал Explore и показывать интересные кейсы из Bug Bounty и пентестов, где небольшая мисконфигурация приводит к тяжелым последствиям.

Бывает, что в командах тестирования грезят об автоматизации процессов, но почему-то боятся внедрять даже такие простые вещи как хуки: «Они очень усложняют процесс, и писать их тысячу часов». С этим я категорически не согласен, ведь реализовать хуки очень просто.

Меня зовут Денис Федоров, я тестировщик в команде 2ГИС ПРО, сервисе геоаналитики для бизнеса. Рассказываю, что такое гит-хуки, чем они могут быть полезны и как их можно реализовать у себя.