Git *

Введение

В связи с тем, что не многие, как оказалось, знают про Stash немного о нём. На сайте производителя даётся такое описание:

Интерфейс Stash позволяет с легкостью выполнять задачи по администрированию и управлению. Stash хранит ваши растущие Git репозитории в безопасности в пределах зоны действия файервола. Добавляйте пользователей и группы пользователей, устанавливайте детализированный правила прямо из UI (пользовательского интерфейса). Создавайте и управляйте репозиториями в рамках Stash. Быть в курсе всех командных дел и вывести их в единый список – дело всего пары минут.

Грубо говорят Stash от Atlassian — это ваш локальный ГитХАБ. Особая прелесть этого инструмента заключается в том, что он очень тесно интегрирован с той же JIRA от Atlassian, что обеспечивает гораздо более удобную ревизию кода по выполняемой задаче и единый интерфейс для этого.

Установка

Установка указанного продукта достаточно проста. Но я всё таки нашёл для себя грабли.
Отчасти это было связано с тем, что ставил я на CentOS. С этим дистрибутивом я до недавнего времени опыта почти не имел.

Фактически данная статья это вольный перевод Getting Started руководства с сайта Atlassian в разделе установки в Linux.

Пригодится начинающим.

Выходные окончились, и к нам возвращается прежний настрой на внедрение новых функций Гитхаба. Исходя из желания зрелищно начать 2014 год, сегодня мы с удовольствием запускаем аналитику посещаемости!

Теперь вы сможете видеть подробные проанализированные сведения о посещениях тех репозиториев, которыми владеете или в которых можете напрямую помещать код (push). Просто зайдите на страницу графиков конкретного репозитория — и увидите новую ссылку, ведущую на страницу «Traffic».



Зайдя на страницу посещений, вы увидите множество полезных сведений о своих репозиториях, в том числе о том, откуда приходят читатели, что они просматривают.


Глядеть на эти цифры о собственных наших репозиториях было забавно, иногда удивительно, всегда интересно. Надеемся, что и вам это понравится не меньше, чем нам!

За несколько дней до наступления 2014 года Гитхаб успел перешагнуть отметку в 10 миллионов репозиториев. Причём больше половины из них — 5,5 миллиона — было создано в этом году. Гитхаб, несмотря на уже огромные размеры, продолжает расти экспоненциально. Если на создание первого миллиона репозиториев ушло три года и восемь с половиной месяцев, то последний миллион нарегистрировали за сорок восемь дней.

Никогда не был фанатом gitk и пользовался им редко, предпочитая консоль и настроенные алиасы. Благодаря хабраюзеру grossws, я открыл для себя tig. Это то, чего мне не хватало. После месяца использования его в работе хочу поделиться находкой с вами.

Tig это консольный GUI(TUI) для Git, основанный на Ncurses.
Основные преимущества:

• потрясающая скорость, 20,000 коммитов готовы к просмотру за четверть секунды
• консольный
• управление в vim стиле

Cкриншоты основных режимов и сравнение с gitk.

Здравствуй Хабр!

Совсем недавно в нашей компании проходил очередной Хакатон. И в его рамках мне захотелось убить время поинтересней сделать полезную вещь, как для себя так и для других разработчиков. Выбор пал на этакий валидатор sql кода, который бы проверял его на разные правила что не под силу компилятору и те что могут пропустить ребята которые делают Code Review. Таких правил можно придумать массу, начиная от простого “Добавлять GO в конце запроса” и заканчивая более сложными “Использовать View вместо Table”. И самое главное, этот валидатор никоим образом не должен добавлять время разработчику на его использование, т.е. попросту говоря, он должен валидировать себе где-то автоматически, вне зависимости от действий разработчика.

Так уж исторически сложилось, что весь sql-код перед тем как выйти в продакшн (т.е. исполнится на основной БД) сохраняется у нас в GIT репозитории, куда попадает напрямую от разработчиков (естественно после Code Review). Так вот, возникла идея добавить git-hook в этом репозитории который бы валидировал sql-код и если он не валидный то коммит бы возвращался разработчику на доработку. Немного тяжело представить, легче нарисовать:

К моему удивлению на целом хабрахабре нет ни одного поста где бы было понятно написано про 3 вида git reset. Например, во второй по релевантности статье по запросу «git reset» автор пишет что «данное действие может быть двух видов: мягкого(soft reset) и жесткого(hard reset)». Режим --mixed, используемый по умолчанию, почему-то не удостоился упоминания.

Ничего удивительного, что часто видишь непонимание работы этой команды. Под катом коротко и ясно расскажу о всех трёх режимах git reset, после прочтения топика неясностей остаться не должно.

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

В очередной раз утратив ценный конфиг из-за перепутанных шелловых > и >>, я, наконец, понял,
что пора делать бекапы.



Можно делать копии конфигов куда-то в укромное место на диске, можно сделать rsync на удалённый сервер
или понаписать хитрых велосипедообразных скриптов.
Но самое удобное решение находится уже прямо под руками: создать git репозиторий в корне.

Иногда встречаю в файле .gitignore то, чего там быть никак не должно. Например, папка .idea, в которой лежат конфиги известных IDE от JetBrains. Это часть вашего рабочего окружения и она никаким боком не относится к проекту и репозиторию. Если над проектом работает несколько человек и каждый из них добавит конфиги своего окружения в .gitignore, то он превратится в нечитаемую помойку.

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

Это пост для тех, кто начинает работу с Git. Все, что здесь написано по частям можно найти в многочисленных простынях о Git на Хабре. Но я подумал, что неплохо было бы иметь отдельный предельно понятный топик, который бы гуглился по запросу «git изменение коммитов».

Badoo — это проект с гигантским git-репозиторием, в котором есть тысячи веток и тегов. Мы используем сильно модифицированный GitPHP (http://gitphp.org) версии 0.2.4, над которой сделали множество надстроек (включая интеграцию с нашим workflow в JIRA, организацию процесса ревью и т.д.). В целом нас этот продукт устраивал, пока мы не стали замечать, что наш основной репозиторий открывается более 20 секунд. И сегодня мы расскажем о том, как мы исследовали производительность GitPHP и каких результатов добились, решая эту проблему.

Расстановка таймеров

При разработке badoo.com в девелоперском окружении мы используем весьма простую debug-панель для расстановки таймеров и отладки SQL-запросов. Поэтому первым делом мы переделали ее в GitPHP и стали измерять время выполнения участков кода, не учитывая вложенные таймеры. Вот так выглядит наша debug-панель:



В первой колонке находится имя вызываемого метода (или действия), во второй — дополнительная информация: аргументы для запуска, начало вывода команды и trace. В последнем столбце находится потраченное на вызов время (в секундах).

Предисловие или от куда взялась «бредовая» идея ставить Git на Windows

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

А теперь внимание! Только мы одни во всей фирме работаем на Линуксе, а все остальные сидят исключительно на Windows и сервера у нас тоже под управлением серверных редакций ОС от Билла Гейтса. И если перенос базы Redmine не вызывает особых вопросов, то задача поднять на сервере Windows сервер для Git меня сразу поставила в тупик. Но несколько часов потраченных на поиски дали мне простое работающее решение.

coviolations.io — сервис для визуализации результатов тестов и анализаторов кода сегодня перешёл в стадию beta.

Основные нововведения:

• поддержка приватных репозиториев и репозиториев компаний;
• поддержка xUnit, coverage, jslint;
• выставление статуса коммитам на github;
• добавление аннотаций к коду на github с результатами pep8 и jslint;
• добавление краткой сводки к pull request (только с travis-ci);
• новый модный интерфейс на AngularJS;
• параметры nofail, nocomment и stderr в .covio.yml.

От команды Гитхаба всё чаще слышны высказывания о том, что совместная разработка ПО — далеко не единственный сценарий применения их сайта. Сооснователь и CEO Гитхаба Том Престон-Вернер заявил недавно: «Мы хотим, сделать Гитхаб настолько гибким и простым, чтобы им могли пользоваться юристы, чиновники, кто угодно… Сейчас мы постоянно обсуждаем со множеством людей то, как они используют Гитхаб, и как ещё его можно использовать».

Уже есть несколько примеров использования Гитхаба не для разработки софта, а для написания книг, законов, публикации наборов данных. А 15 октября на Гитхабе открылся раздел government.github.com, специально предназначенный для проектов, связанных с электронным правительством, открытыми данными, гражданскими инициативами и законотворчеством. Список государственных учреждений, общественных организаций, правительств и муниципалитетов, использующих Гитхаб, уже насчитывает десятки наименований.

Yac 2013 посетил Jason Rudolph из GitHub. Я считаю его доклад про API был одним из самых интересных на конференции. Яндекс обещал выложить в сеть записи, так что советую на досуге посмотреть его всем, кто не видел.

Но речь пойдет не о докладе. На картинке график релизов GitHub на продакшн.



Когда я услышал цифру, я не поверил своим ушам. У GitHub'а сотни обновлений в неделю. В команде около сорока разработчиков и ни одного QA.

К счастью Джейсон после доклада еще какое-то время находился рядом со сценой и я смог расспросить его с пристрастием о том как они это делают.

Не работает главная, а также невозможно достучаться до репозиториев, статус сервиса сообщает о DDoS атаке.

Update 1: Починили 9:43 UTCWe are recovering from a major service outage as we work to mitigate another DDoS attack.
пуши уходят нормально, можно продолжать работать.

Update 2: Заново упал 10:20 UTCThe site is unavailable as we continue mitigating a large DDoS attack.

По горячим следам чекаута Pull Request'ов, теперь вы можете открывать файлы в GitHub for Mac и GitHub for Windows прямо из Pull Request'ов и веток!

Теперь в Pull Request'ах появилась кнопка «Открыть» («Open»):



И в интерфейсе просмотра файлов из веток:

Утром 1 октября 2013 года календарь проделанной работы над открытым исходным кодом, расположенный на моей гитхабовской странице, выглядел вот как:



Это не было простой случайностью. Я нарочно решил (руководствуясь GTD-соображениями) достаточно долгое время стараться каждый день чего-нибудь делать на Гитхабе, а затем (если дело пойдёт) поделиться на Хабрахабре наиболее ценными впечатлениями от именно такой манеры работы (назовём её, скажем, calendar-driven development), когда впечатления накопятся.

И поделяюсь.

Вступительное слово

Считается, что «киллер фичей» СКВ Git является легковесное ветвление. Я ощутил это преимущество в полной мере, ведь я перешел на Git с SVN, где ветвление было достаточно дорогим процессом: для создания ветки нужно было скопировать весь рабочий каталог. В Git все проще: создание ветки подразумевает лишь создание нового указателя на определенный коммит в папке .git/refs/heads, который является файлом с 40 байтами текста, хешем коммита.

Основными командами пользовательского уровня для ветвления в Git являются git-branch, git-checkout, git-rebase, git-log и, конечно же, git-merge. Для себя я считаю git-merge зоной наибольшей ответственности, точкой огромной магической энергии и больших возможностей. Но это достаточно сложная команда, и даже достаточно длительный опыт работы с Git порой бывает недостаточным для освоение всех ее тонкостей и умения применить ее наиболее эффективно в какой-либо нестандартной ситуации.

Попробуем же разобраться в тонкостях git-merge и приручить эту великую магию.

Здесь я хочу рассмотреть только случай благополучного слияния, под которым я понимаю слияние без конфликтов. Обработка и разрешение конфликтов — отдельная интересная тема, достойная отдельной статьи. Я очень рекомендую так же ознакомиться со статьей Внутреннее устройство Git: хранение данных и merge, содержащей много важной информации, на которую я опираюсь.

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

Но если у вас бесплатный аккаунт — то вы можете создавать только открытые репозитории, закрытые же доступны только для платных тарифов, либо для студентов.

О том как получить возможность создавать приватные репозитории мы и поговорим.