Git *

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

Сегодня мы анонсируем два важных нововведения на GitHub, которые сделают его более доступным для разработчиков: неограниченные бесплатные приватные репозитории и более удобный продукт для компаний. Подробности под катом!

Эта новость опубликована на The Next Web, с пометкой:

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

А ещё есть вот такой замечательный тред в Twitter:

Ясно, что человек писал это дрожащими руками — точно так же, как я сейчас пишу дрожащими руками этот перевод.

Фейк ли это? Нет. Есть и официальное подтверждение в твиттере GitHub, так что — назад дороги нет.

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

В общем, запасаемся попкорном, скрещиваем пальцы на ногах и ждём годноты!

При наличии работоспособного NAS с докером, установка Gitlab не представляет особых сложностей.

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

Часто у разработчиков возникает выбор между Merge (слияние) и Rebase (перемещение). В Гугле вы увидите разное мнение, многие советуют не использовать Rebase, так как это может вызвать серьезные проблемы. В статье я объясню, что такое слияние и перемещение, почему вы должны (или не должны) использовать их и как это сделать.



Git Merge и Git Rebase преследуют одну и ту же цель. Они предназначены для интеграции изменений из одной ветки в другую. Хотя конечная цель одинаковая, принципы работы разные.

Некоторые считают, что вы всегда должны использовать Rebase, другие предпочитают Merge. В этом есть свои плюсы и минусы.

Git Merge

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

Панель управления безопасностью в рамках группы

Разработчики уже давно используют GitLab как инструмент для обеспечения безопасности своего кода. Теперь GitLab дает больше прав и возможностей специалистам, отвечающим за безопасность, так что они могут использовать его для повышения безопасности приложений и обеспечения совместимости. С релизом 11.5, новая панель безопасности группы собирает воедино всю информацию, которая может потребоваться специалистам по безопасности, в удобном виде, разработанном специально для них. Эта панель содержит новые возможности отображения: общий обзор информации о безопасности разных проектов, а также углубленная информация о каждом из них. В 11.5 мы начинаем с отчетов SAST, в дальнейших релизах будем добавлять новые отчеты на эту панель. Наша цель — создать удобный инструмент, единую панель безопасности, которую специалисты по безопасности смогут использовать вместо переключения между множеством инструментов.

1 ноября 2017 года я стал руководителем рабочей группы разработки в отделе программных разработок Timeweb. А 12 ноября 2018 руководитель отдела спросил, когда же будет готова статья для Хабрахабр, потому что отдел маркетинга спрашивает, добровольцы кончились, а контент-план требует чего-то ещё)

Поэтому хочу дать ретроспективу, как менялись процессы разработки, тестирования и поставки наших продуктов в течение последнего года. Про унаследованные процессы и инструменты, docker, gitlab и то, как идёт у нас разработка.

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

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

С новым релизом GitLab 11.3 мы рады представить вам поддержку репозиториев Maven, владельцев кода (Code Owners), защищенные окружения и прогнозы для эпиков. Все это поможет автоматизировать управление окружениями и кодом, что позволит разработчикам на Java быть еще эффективнее.

Ошибка в коммите… Как её исправить? Беспорядок в истории коммитов… Как привести всё в пристойный вид? Автор статьи, перевод которой мы публикуем сегодня, говорит, что она написана специально для тех, кто задавался такими вопросами. По его словам, изучив методики работы с Git, представленные здесь, можно значительно продвинуться по пути освоения Git.

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

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

Основными целями перехода были следующие:

• Повышение прозрачности процесса разработки.
• Внедрение обязательной процедуры код ревью до выноса обновлений на тестовые среды.
• Внедрение непрерывной интеграции для сборки обновлений после код ревью и установки их на тестовые среды.

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

В статье рассказывается, как сделать статические версии веб-страниц для их выдачи сервером и как поместить их в репозиторий для контроля версий и резервного копирования. При этом статические и медиафайлы могут храниться отдельно и архивироваться другими средствами (статика обычно помещается в репозиторий для программного кода сайта). Метод работает также для страниц с Unicode-именами (например, для кириллических доменов). В конце приведён работающий Makefile.

Автор пользуется стеком django/uwsgi/nginx, виртуальным выделенным сервером под управлением GNU/Linux, но содержание статьи почти не зависит от конкретных технологий.

Всем привет. Решил написать шпаргалку себе на будущее в большей степени, но может она пригодиться еще кому-нибудь.

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

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

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

Итак...

Поздравляю всех с днем программиста! Желаю больше ярких "коммитов", принятых "пулл-реквестов", меньше незапланированных "мержей" и чтобы ваши ветви жизни оставались актуальными как можно дольше. В качестве идейного подарка предлагаю реализацию генеалогического древа средствами системы контроля версий Git. Ну что же… звучит как план!

Для тех, кто сразу все понял, выкладываю исходники генератора: GenealogyTreeInGit и сами генеалогические древа — мое и президентов США.

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

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

Как говорится: «никогда такого не было, и вот опять». Напомню, 9 лет назад точно такая же история была с российским сегментом интернета пораженным синдромом открытой .svn. Далее представлены результаты кропотливой работы чешского исследователя, инструментарий и методы.

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


Автор материала, перевод которого мы публикуем сегодня, собирается обсудить распространённые ошибки, которые совершают программисты при работе с Git, и поговорить о том, как с этими ошибками бороться.

Мы с воодушевлением представляем вам новые возможности версии 11.2, которые помогут вам быстрее стартовать и выпускать новые версии. В этот раз мы запускаем улучшения для Web IDE, поддержку импорта манифестов Андроид-проектов и настраиваемые шаблоны проектов.