Git *

Всего через два месяца после версии 2.6 вышел Git 2.7 с новыми возможностями, исправлениями и улучшениями производительности. Что интересного он нам приготовил? Я расскажу о нескольких новинках, которые показались интересными команде Bitbucket.

Полноценный набор команд git worktree

Команда git worktree появилась в Git 2.5, она позволяет выгружать и одновременно работать со многими ветками репозитория в отдельных папках. Например, если нужно сделать срочную правку, но при этом не хочется трогать текущую рабочую копию, можно просто выгрузить нужную ветку в новую папку с помощью команды:

$ git worktree add -b hotfix/BB-1234 ../hotfix/BB-1234
Preparing ../hotfix/BB-1234 (identifier BB-1234)
HEAD is now at 886e0ba Merged in bedwards/BB-13430-api-merge-pr (pull request #7822)

При эксплуатации системы GitLab CE на своем предприятии (имеющему большую филиальную структуру), была обнаружена уязвимость, которая может привести к получению полного доступа к аккаунту любого пользователя системы администраторами филиалов предприятия.

Проблема выявлена в подсистеме LDAP-аутентификации пользователей. Дело в том, что основной сущностью, с использованием которой происходит авторизация в GitLab является E-Mail пользователя. Однако при входе пользователей в GitLab с использованием LDAP процесс аутентификации/авторизации происходит следующим образом:

• Пользователь вводит на странице Sign-In системы свои имя/пароль из службы каталогов LDAP (Active Directory).
• GitLab, используя введенные данные аккаунта производит аутентификацию пользователя в LDAP.
• В случае успешной аутентификации GitLab считывает из атрибута MAIL аутентифицированного аккаунта адрес электронной почты и авторизует по нему в GitLab без всяких дополнительных проверок

.
В результате, например, «нехороший» системный администратор «филиала A», может используя свои полномочия, к примеру в Active Directory, создать в своем OU «Филиал А» любого пользователя (например hackuser) и записать в его LDAP-атрибут MAIL адрес электронной почты пользователя любого другого филиала, на который даже не распространяются полномочия этого администратора. После этого «нехороший» администратор «Филиала А» может авторизоваться пользователем hackuser в системе GitLab, при этом в результате авторизации будет получен полный доступ к аккаунту пользователя, имеющего адрес электронной почты установленный «нехорошим» администратором для hackuser.

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

Система Git появилась, как средство управления исходными текстами в операционной системе Linux и завоевала множество поклонников в среде Open Source.

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

После того, как вы начали работу над проектом и написали какой-то работающий прототип, у вас появится желание сохранить результаты работы. Это так же может быть полезно в случае, если вы захотите продолжить работу на другом компьютере. Самое простое решение — это сохранить все на флешке. Этот вариант неплохо работает, но если есть подключение к интернету (а сейчас у кого его нет), то удобно воспользоваться системами Git/Github.

В этой статье будут описаны базовые сценарии использования систем Git/Github при работе над проектом в среде Linux с помощью командной строки. Все примеры проверялись на системе с Linux Ubuntu 14.04 и Git 1.9.1. Если вы пользуетесь другим дистрибутивом, то возможны отличия.

Относительно недавно мне посчастливилось присоединиться к команде разработки Bitbucket Server в Atlassian (до сентября он был известен как Stash). В какой-то момент мне стало любопытно, как этот продукт освещён на Хабре, и к моему удивлению, нашлось лишь несколько заметок о нём, подавляющее большинство которых на сегодняшний день уже устарело.

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

Позвольте начать с перевода статьи Тима Петтерсена «A better pull request» о том, как должен выглядеть pull request, чтобы наиболее эффективно решать возложенную на него задачу.

Wargaming сейчас разрабатывает тактическую карточную игру WoT: Generals. Веб-версия написана на JS, используются LibCanvas и AtomJS. Я принимал непосредственное участие в разработке и хочу рассказать про функционал, который мне кажется интересным и может быть полезным во всех веб-играх. А именно — о системе плагинов игры, которая вдохновлялась пакетными менеджерами в Linux и имеет следующие возможности:

— История изменений плагинов
— Автоматическое обновление плагина при обновлении версии игры
— Разработка плагинов на localhost
— Неограниченное количество веток, например, для нестабильных версий
— Зависимости (плагин А автоматически подключает плагин Б)
— Встроенная возможность делать паки (следствие предыдущего пункта)
— Легкое изменение любой части клиента игры
— Полный административный контроль авторов игры над всеми плагинами
— Поиск по базе плагинов
— При этом простая установка юзером и удобная работа для плагинописцев.

Вслед за замечательными анонсами с конференции Connect 2015 мы продолжаем знакомить вас со сценариями использования новых технологий и сервисов для организации непрерывной разработки и тестирования ваших приложений.

Недавно мы рассказывали о реализации непрерывных процессов разработки и тестирования с помощью Visual Studio Team Services (ранее Visual Studio Online). В статье подробно описывается как на базе репозиториев Git в Visual Studio Team Services организовать процесс разработки на базе Scrum и с помощью интеграции с Visual Studio обеспечить непрерывные процесс тестирования и разработки кода (Continuous Integration & Testing).


В этой статье мы рассмотрим следующий шаг в построении полного цикла DevOps – обеспечение непрерывного развертывания (Continuous Deployment) с помощью новых возможностей настраиваемых шаблонов сборки и публикации проектов в Visual Studio Team Services. Мы будем использовать проект на базе ASP.NET 5 и увидим как для таких проектов обеспечить полный цикл от редактирования кода до автоматической сборки и развертывания в облаке Azure (может быть любым местом).

Совсем недавно гитлаб героически выкатил версию 8.0 своего конкурента гитхабу. Из интересного — движок continuous integration теперь встроен в платформу, а значит доступен в качестве бесплатного сервиса для всех желающих на gitlab.com. Совместно с бесплатными приватными репозиториями это делает облачный сервис гитлаб не только удобным местом для хранения кода, но также тестирования и деплоя. О последнем я и расскажу под катом.

Преамбула

Какое-то время назад, решив навести порядок в нашем коде, выбрали в качестве системы контроля стиля кода Checkstyle. Думаю, проект знакомый, в представлении не нуждается. До этого в команде мы использовали общий репозиторий, где хранились настройки code styles, intentions для идеи.

Добавляя в проект checkstyle, мы в первую очередь преследовали цель — возможность превратить ошибки в оформлении стиля кода в ошибки сборки. Лёгким движением руки checkstyle был подключен в корневой pom проекта, разработчики были ознакомлены с нововведением, сборки на Teamcity научились проверять checkstyle перед коммитом.

Да вот незадача: в наших рядах появился вредитель. Как мы с ним боролись — под катом.

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

Ты просто-напросто ненавидишь Git? Ты абсолютно счастлив с Mercurial (или, фу, с Subversion), но раз в месяц тебе приходится отважно сталкиваться с Git, потому что каждый, даже его чертова собака, теперь использует GitHub? Тебя терзают смутные подозрения, что половина всех команд Git на самом деле удалят всю твою работу навсегда, но ты не знаешь какие именно и не хочешь проводить три недели, углубляясь в документацию?

Хорошие новости! Я написал тебе этот изумительный Интернет-пост. Я надеюсь, что смогу размазать достаточно Git-а по твоему лицу, чтобы понизить вероятность сделать что-то непоправимое, а так же уменьшить твой страх что-то сломать. Этого должно быть также достаточно, чтобы сделать документацию Git немного более понятной; она крайне тщательно и глубоко проработана и очень глупо, если ты все еще не прочитал половину.

Я постараюсь излагать коротко, но также, чтобы это было потенциально полезно тем людям, кто вообще никогда не сталкивался с контролем версий, поэтому повсюду будет разбросан 101 совет. Не бойся! Я не думаю, что пользователи Mercurial понятия не имеют, что такое патч.

Имеем следующую ситуацию:

В проекте присутствует файл super.config. В нем содержатся много разных настроек проекта. Например, конфигурация взаимодействия со сторонним сервисом и уровень логирования. Система контроля версий — git.

В чем проблема:

1. Этот файл должен находиться под версионным контролем, так как в нем содержатся «общие» настройки. Ну и сама структура файла ценна.
2. Каждый разработчик меняет уровень логирования под свои нужды и не хочет, чтобы эти изменения попадали в коммиты, и тем более в интеграционный репозиторий.
3. В этом файле периодически меняются общие настройки, и разработчик хочет их получать (pull) и публиковать (commit)

В этой серии статей мы рассмотрим процесс размещения инфраструктуры для разработки в облаке InfoboxCloud. Для удобного развертывания стека приложений будем использовать Docker.

В первой статье развернем Gitlab, включающий в себя:

• веб-интерфейс для системы управления исходными текстами git, максимально похожий на GitHub
• удобный просмотр активностей пользователей
• браузер файлов
• Wiki
• возможности проведения Code Review
• баг-трекер
• возможность создания сниппетов кода
• возможность вставки web hooks
• билд-сервер

и многое другое.



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

Если вы регулярно используете Git, то вам могут быть полезны практические советы из этой статьи. Если вы в этом пока новичок, то для начала вам лучше ознакомиться с Git Cheat Sheet. Скажем так, данная статья предназначена для тех, у кого есть опыт использования Git от трёх месяцев. Осторожно: траффик, большие картинки!

Содержание:

1. Параметры для удобного просмотра лога
2. Вывод актуальных изменений в файл
3. Просмотр изменений в определённых строках файла
4. Просмотр ещё не влитых в родительскую ветку изменений
5. Извлечение файла из другой ветки
6. Пара слов о ребейзе
7. Сохранение структуры ветки после локального мержа
8. Исправление последнего коммита вместо создания нового
9. Три состояния в Git и переключение между ними
10. Мягкая отмена коммитов
11. Просмотр диффов для всего проекта (а не по одному файлу за раз) с помощью сторонних инструментов
12. Игнорирование пробелов
13. Добавление определённых изменений из файла
14. Поиск и удаление старых веток
15. Откладывание изменений определённых файлов
16. Хорошие примечания к коммиту
17. Автодополнения команд Git
18. Создание алиасов для часто используемых команд
19. Быстрый поиск плохого коммита

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

Привет, Хаброжители!
У нас вышла новая книга С. Чакона и Б. Страуба



Эта книга представляет собой обновленное руководство по использованию Git в современных условиях. С тех пор как проект Git — распределенная система управления версиями — был создан Линусом Торвальдсом, прошло много лет, и система Git превратилась в доминирующую систему контроля версий, как для коммерческих целей, так и для проектов с открытым исходным кодом. Эффективный и хорошо реализованный контроль версий необходим для любого успешного веб-проекта. Постепенно эту систему приняли на вооружение практически все сообщества разработчиков ПО с открытым исходным кодом. Появление огромного числа графических интерфейсов для всех платформ и поддержка IDE позволили внедрить Git в операционные системы семейства Windows. Второе издание книги было обновлено для Git-версии 2.0 и уделяет большое внимание GitHub.

Много статей (в том числе и на Хабре) посвящено подключению к Git по SSH-ключам. Почти во всех из них используется один из двух способов: либо с помощью puttygen.exe, либо командами ssh-keygen или ssh-add.

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

Как я решил эту проблему — под катом.

На Хабре и в нашем блоге о корпоративном IaaS мы много пишем об облачных технологиях, и рассматриваем интересные инфраструктурные проекты различных компаний. Сегодня поговорим о повышении производительности git-сервера и взглянем на историю и опыт проекта Clever Cloud.

Доброго дня, Хабр!

Спешу рассказать вам, что совсем недавно вышла новая версия нашего баг-трекера — YouTrack 6.5!



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

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

Вышла первая официальная версия Git for Windows. В отличие от msysGit инсталятор теперь содержит только Git (ранее же там было все необходимое для сборки Git), также теперь есть инсталятор для 64-битной версии.