Git *

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 и предоставляет бесплатный хостинг для вашего кода.

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

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

Целевая аудитория, мотивация

Надеюсь, что пост окажется полезным для тех, кто на среднем уровне знаком с Git и на начальном — с Python. Кроме того, предполагается наличие базовых знаний об устройстве Unix-систем и регулярных выражениях.

В моей команде разработчиков назрела необходимость организационно повлиять на формат сообщений к коммитам. Практика показала, что для должного соблюдения новых правил странички в корпоративной базе знаний недостаточно, хотелось принудительно запрещать проталкивание (push) на сервер плохо оформленных коммитов. Недавно начав изучать Python, я знал, что этот язык хорошо подходит для написания системных сценариев благодаря своей развитой стандартной библиотеке. Вместе с тем опыт подсказывал, что наличие конкретной цели здорово помогает при изучении чего бы то ни было нового. Поэтому, отбросив страх перед неизвестностью, взялся решать задачу на малознакомом языке. Заранее оговорюсь, что в конце поста приведены ссылки, по которым можно найти подробную информацию по всем затронутым в тексте темам.

В апреле 2013 года на Github появилась опция рендеринга 3D-моделей, в частности, файлов STL. Можно вращать их в разные стороны, зуммировать колёсиком мышки и т.д. Теперь же добавлена очень удобная функция визуального просмотра изменений в 3D-моделях.

Для начала поздравляем с Днем Программиста всех жителей Хабры!
Мы долго думали: что бы такого полезного и интересного подарить людям, которые предпочитают слову дело? Думали-думали и придумали: теперь в вашем резюме за вас будет говорить GitHub!

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

• действия выполняются вручную, что требует сосредоточенности и аккуратности;
• жёсткие временные рамки.

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

Разработка

Я расскажу о цикле разработки через Github, который я использую. Он был проверен в течении года на командах разного размера: 3 — 14 человек.

Существует 2 основных ветки: master и dev.

master — стабильная ветка, готовая к выкатыванию на production сервер в любой момент.

dev — ветка, над которой в данный момент работает команда.

Итак, в начале разработки master и dev ветки идентичны.

Думаю, многи ждали этот момент. GitHub добавил еще один слой безопасности. Наконец-то добавлена двухфакторная аутентификация.

По долгу службы мне досталась в наследство некая система, имеющая ~15 лет истории и порядка нескольких десятков инсталляций в разных организациях. Сама по себе системы относительно небольшая (~25K строчек кода, ~1K коммитов), но проблема была в release management:

• было основное дерево в subversion (изначально в cvs, разумеется), где проводился «основной курс партии» — делались какие-то масштабные изменения, добавлялись новые возможности, исправлялись глобальные ошибки и т.п.
• конкретные инсталляции делались путем:
  
  • в лучшем случае — svn checkout, который потом обновлялся через svn update; почти во всех инсталляциях делались локальные доработки «на живую» (как минимум — правились конфигурационные файлы) и эти изменения никуда не коммитились; если при очередном svn update изменения в upstream создавали конфликт — конфликт ресолвился «на месте» тем программистом, который делал update, опять же, без какого-либо трекинга изменений
  • в худшем случае — svn export, который потом, понятно, не обновлялся совсем, оставаясь раз и навсегда (или по крайней мере пока начальство не одумается) на уровне развития даты экспорта; в особо запущенных случаях (из конца 1990-х — начала 2000-х) так делали еще и потому, что просто не было физической возможности сделать checkout — в организации не было доступа в интернет, архив просто приносили на дискетке и разворачивали единожды на месте

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

Доброго времени суток уважаемые хабражители. Буквально только что увидел потрясающий проект на GitHub от FredrikNoren.

Ungit:

• Чистый и интуитивно понятный интерфейс для Git (что есть невероятно круто для освоения Git)
• Работает на любой платформе с установленными Node.js и самим Git
• Веб-ориентированный. Возможность запускать его в облаке.
• GitHub

Необходим Node.js версии 0.10 или выше и npm версии 1.3.1 или выше

Установка

npm install -g ungit

Я думаю, что после просмотра видео, моего более тщательного описания не потребуется. Спасибо всем за внимание.

13 августа GitHub порадовал пользователей очередным приятным нововведением — в этот раз сделан шаг в сторону дальнейшей социализации.
Был выпущен новый способ просматривать, что находится в тренде на сервисе с удобством фильтрации по временному периоду, трендовым проектам, разработчикам и языкам программирования.

Проблемы git-flow

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

Однако и у git-flow есть проблемы. Я не раз слыхал мнения людей, выражавших неприязнь к тому, что ветви фич отходят от develop вместо master, или к манере обращения с хотфиксами, но эти проблемы сравнительно невелики.

Для меня одной из более крупных проблем git-flow стала его сложность — бóльшая, чем на самом деле требуется большинству разработчиков и рабочих групп. Его сложность ужé привела к появлению скрипта-помощника для поддержания рабочего процесса. Само по себе это круто, но проблема в том, что помощник работает не из GUI Git, а из командной строки, и получается, что те самые люди, которым необходимо действительно хорошо выучить сложный рабочий процесс, потому что им вручную придётся пройти все шаги его — для этих-то людей система и недостаточно удобна для того, чтобы использовать её из командной строки. Вот что становится крупною проблемою.

Все эти проблемы можно без труда преодолеть, следуя гораздо более простому рабочему процессу. Мы не пользуемся git-flow в Гитхабе. Наш рабочий процесс основан (и всегда был основан) на более простом подходе к Git.

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

Рабочий процесс Гитхаба

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

Это руководство подскажет вам, как буквально за 10 минут создать простой, удобный и надежный аналог Dropbox, который будет под вашим полным контролем и позволит обмениваться файлами с коллегами по локальной сети.

Разработчики Github реализовали новую функцию Releases для удобного распространения ПО конечным пользователям. Зайдя в раздел Releases, пользователь всегда может найти последнюю версию программы, changelog и полную историю версий. Ссылка на релизы помещена на главную страницу проекта.

На днях с командой столкнулись с тем, что Bitbucket стал мал для нас, а нацеленность на подобие корпоративной безопасности, в любом случае, рано или поздно потребует переезд с приватных репозиториев, находящихся вне компании, на собственную инфраструктуру. После сёрфинга по интернету было решено остановиться на готовом решении SCM — manager по ряду причин

• Простота установки
• Простота администрирования через веб-интерфейс
• Поддержка GIT и SVN (немаловажно, поскольку используются оба)

ОС для установки: Debian7
Стоит заметить, до этого с подобным никто у нас не сталкивался и статья — это результат нескольких часов метаний по интернету и мануалам.
SCM ставился на Tomcat, поскольку на нём же крутится Redmine
Сама установка и настройка под катом: