Как стать автором
Обновить
23.52

Git *

Система управления версиями файлов

Сначала показывать
Порог рейтинга
Уровень сложности

Вышел релиз GitLab 16.6 с новой фичей GitLab Duo Chat (бета)

Уровень сложности Средний
Время на прочтение 15 мин
Количество просмотров 2.6K
Читать дальше →
Всего голосов 3: ↑3 и ↓0 +3
Комментарии 3

Новости

Размер пул-реквеста имеет значение

Уровень сложности Средний
Время на прочтение 6 мин
Количество просмотров 5.1K

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

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

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

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

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

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

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

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

Читать далее
Всего голосов 18: ↑17 и ↓1 +16
Комментарии 9

Три среды на бэкенде

Время на прочтение 5 мин
Количество просмотров 6.6K

Я уже не раз порывался написать что‑то общее про бранчинг; про некогда распиаренный GitFlow, который запиаривают обратно; про trunk‑based development (умеренно распиаривают), про то, как это увязать с разработкой бэкенда. И вот я затираю очередной забуксовавший черновик своей заметки чтобы всё упростить и не гоняться за чрезмерным обобщением опыта. Давайте я просто поделюсь рецептом, а вы его оцените.

Читать далее
Всего голосов 4: ↑2 и ↓2 0
Комментарии 17

Красота не только в коде — как оформлять репозиторий

Уровень сложности Простой
Время на прочтение 7 мин
Количество просмотров 19K

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

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

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

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

Узнать, как оформлять репозитории
Всего голосов 27: ↑20 и ↓7 +13
Комментарии 42

Истории

Как в git заменить master на другую ветку без использования push --force (перенос стейта одной ветки на другую)

Уровень сложности Сложный
Время на прочтение 4 мин
Количество просмотров 9.6K

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

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

Читать далее
Всего голосов 25: ↑21 и ↓4 +17
Комментарии 28

Вышел релиз GitLab 16.5 с отчётами о соответствии требованиям и правилами задания целевой ветки мерж-реквестов

Уровень сложности Средний
Время на прочтение 12 мин
Количество просмотров 3.5K
Читать дальше →
Всего голосов 6: ↑6 и ↓0 +6
Комментарии 0

Вас сдаст Гитхаб: деанонимизация пользователей SSH-серверов

Уровень сложности Простой
Время на прочтение 5 мин
Количество просмотров 40K

Недавно в своих ежедневных чтениях я наткнулся на явление, о котором думал уже много лет: феномен утечки информации людей, использующих SSH. Этот тип утечки информации не является новым явлением. Я давно предупреждал об этой опасности своих друзей, использующих SSH, но мой голос услышали лишь несколько человек. Поэтому я решил дать пояснения по этому поводу, потому что я считаю, что необходимо понимать этот риск в ИТ-сообществе, особенно в нынешней ситуации. Я буду исходить из предположения, что у вас, дорогой читатель, есть опыт работы с SSH.

Читать далее
Всего голосов 87: ↑83 и ↓4 +79
Комментарии 153

Настраиваем Git server hook в GitLab On-Premise для защиты кода от вмешательства злоумышленников

Время на прочтение 5 мин
Количество просмотров 2.4K

Как убедиться в том, что коммиты в продуктовых репозиториях «настоящие»? То есть отправлены тем человеком, имя которого указано в коммите. Мы с коллегами из команды DevOps задались целью построить процесс, который будет давать нам полностью прозрачную картинку, и у нас это получилось. Эта статья довольно практическая, и решение, о котором я, Рамазан Ибрагимов, вместе с моим коллегой Александром Паздниковым пишу в этом материале, — лишь часть большой схемы по обеспечению безопасности. В качестве хранилища кода будем опираться на инстанс GitLab On-Premise внутри компании — вендора ПО.

Читать далее
Всего голосов 14: ↑14 и ↓0 +14
Комментарии 13

ИИ-помощники для работы с кодом

Уровень сложности Простой
Время на прочтение 4 мин
Количество просмотров 9.3K

Инструменты на базе ИИ с открытым исходным кодом, которые призваны помочь вам в разработке проектов.

Читать далее
Всего голосов 11: ↑9 и ↓2 +7
Комментарии 2

Gitea & Act Runner: First touch

Уровень сложности Простой
Время на прочтение 4 мин
Количество просмотров 4.2K

С версией 1.19 в Gitea появился собственный Github-подобный CI/CD. Насколько же трудно будет прикрутить к уже работающему Gitea серверу CI/CD. Давайте проверим!

Читать далее
Всего голосов 24: ↑24 и ↓0 +24
Комментарии 7

Как потратить дни, чтобы сэкономить секунды: продвинутые коммиты в GitLab

Уровень сложности Средний
Время на прочтение 6 мин
Количество просмотров 8.4K

Коммит изменения в GitLab — фоновый и рутинный процесс, на который никто не закладывает рабочего времени. Но в нем есть действия, которые съедают 18 секунд при каждом коммите. 10 коммитов — уже 3 минуты за день и 15 — за неделю. Да, немного, но на это тратится внимание. К тому же, за эти 15 минут можно сделать что-то полезное или просто выпить кофе и дать мозгу отдохнуть.

Мы в Selectel нашли способ, как упростить коммиты в GitLab и добавить им информативности — описания прямиком из Jira. Любите автоматизировать рутинные задачки? Тогда добро пожаловать под кат.
Читать дальше →
Всего голосов 36: ↑34 и ↓2 +32
Комментарии 17

15 ресурсов по Git. Что почитать/посмотреть?

Уровень сложности Простой
Время на прочтение 2 мин
Количество просмотров 18K

Всем привет! В этот раз собрали подборку вспомогательных материалов для изучения Git. Удобство и гибкость сделали Git стандартом для большинства современных IT-компаний. Поэтому умение работать с ним критично для любого программиста.

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

Читать далее
Всего голосов 12: ↑8 и ↓4 +4
Комментарии 6

Вышел релиз GitLab 16.4 с настраиваемыми ролями и списком зависимостей для групп

Уровень сложности Средний
Время на прочтение 14 мин
Количество просмотров 4.7K
Читать дальше →
Всего голосов 12: ↑12 и ↓0 +12
Комментарии 1

Ближайшие события

GitFlow процесс

Уровень сложности Простой
Время на прочтение 6 мин
Количество просмотров 12K

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

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

Читать далее
Всего голосов 25: ↑14 и ↓11 +3
Комментарии 36

Фундаментальные подходы при работе с Git

Время на прочтение 5 мин
Количество просмотров 18K

Git - одна из наиболее популярных систем контроля версий, используемых разработчиками по всему миру. Однако, существует множество различных подходов к организации рабочего процесса с использованием Git. В этой статье мы рассмотрим некоторые из наиболее популярных методов, такие как Git Flow, Trunk-Based Development (TBD), на их основе бизируются остальные:

Читать далее
Всего голосов 11: ↑6 и ↓5 +1
Комментарии 24

Как я статистику git парсил

Уровень сложности Простой
Время на прочтение 9 мин
Количество просмотров 24K

Работаю я в бюрократизированной конторе с плохими процессами. Текучка тут достаточно большая. Люди приходят и уходят. Менеджмент на уровне дна. В какой-то момент в команду докинули нового разработчика (с неясными целями и задачами). Ну вроде парень умный, вроде что-то делает, вроде не просто так.

Спустя четыре месяца (испытательный закончился) у многих закрались подозрения, что на самом деле парень ничего не делает. Но как доказать это со стороны объективно? Решили посмотреть историю коммитов. Оказалось, он почти не коммитил (последний месяц вообще перестал), а на совещаниях ссал в уши ездил по ушам. Парень продолжил работать на прошлой работе и был преподом на курсах. Такой вот overemployed, с двумя зарплатами по ставке синьора.

Ему предложили перевестись в другой отдел. Менеджеру все сошло с рук. Часть разрабов сидела с лицами «‎а что так можно было?»‎. А я понял, что нельзя так просто взять и посмотреть статистику коммитов.

Велосипед через 3, 2, 1...
Всего голосов 98: ↑92 и ↓6 +86
Комментарии 50

«Хороший коммит» и «ваш коммит»: как написать идеальный комментарий в Git

Время на прочтение 8 мин
Количество просмотров 15K

Привет, Хабр!

Мы в beeline cloud не только создаем современные цифровые продукты, но и обучаем разработке в облаке студентов нашего курса Base Cloud DevOps. Однако выстроить эффективный процесс невозможно без знания основных инструментов. Один из них — система контроля версий Git. Перевели для вас статью, которая поможет извлечь из работы с этой утилитой еще больше пользы.

Когда-то я и не задумывался о существовании каких-то правил для составления комментариев к коммитам, но потом любознательность взяла верх. Мне казалось, что простых сообщений наподобие «добавлена функция 2», «исправлена ошибка на панели навигации» или просто «foo» вполне достаточно. Однако моя уверенность в том, что комментарии к коммитам, как правило, никто не читает, оказалась ошибкой. Хорошо составленные commit messages очень важны, они помогают нам самим в будущем извлечь максимальную пользу из своих стараний и продуманности.

Читать далее
Всего голосов 14: ↑14 и ↓0 +14
Комментарии 34

Приручаем GitLab: прикольные фишки и инциденты, которые упростят вашу жизнь

Уровень сложности Средний
Время на прочтение 11 мин
Количество просмотров 31K

В текущих реалиях все IT-продукты разрабатываются с использованием какого-либо ПО, способного управлять репозиториями программного кода для Git. В нашем случае, хотелось бы рассказать про один из самых популярных продуктов — Gitlab. «Gitlab — наше всё» должно быть слоганом каждой компании, которая его использует, иначе могут произойти события, которые приведут к печальным последствиям. На Habr можно найти множество различной информации, связанной с кейсами, туториалами или просто интересными историями. Но сколько бы ни было написано, найти место где было бы собрано всё и сразу — не получилось. Придется исправлять. 

Начнём?
Всего голосов 30: ↑27 и ↓3 +24
Комментарии 3

Интеграция Telegram ботов в Django приложениях

Уровень сложности Простой
Время на прочтение 4 мин
Количество просмотров 7.5K

Как же объединить Django и Telegram бота в одном проекте?

Этой статьей я хотел дополнить тот маленький клочок информации доступный в интернете по теме создания ботов который мне явно бы пригодился в прошлом. Сегодня речь пойдет о соединения вашего серверного приложения с Telegram ботом на примере языка Python, его фреймворка для разработки серверных приложений - Django и библиотеки для создания Telegram ботов - pyTelegramBotApi.

Читать далее
Всего голосов 7: ↑6 и ↓1 +5
Комментарии 18

Подборка VS Code-плагинов для Frontend-разработчиков и не только

Уровень сложности Простой
Время на прочтение 2 мин
Количество просмотров 8.4K

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

Читать далее
Всего голосов 11: ↑6 и ↓5 +1
Комментарии 2

Вклад авторов