Git *

Если вы часто используете maven, то наверняка сталкивались с ситуацией когда какого-нибудь нужного артефакта не оказывается в maven central. Конечно всегда можно установить недостающий джарник в ваш локальный репозиторий ~/.m2, но это отрицательно сказывается на переносимости билда, ведь на машине коллеги, у которого данный jar не установлен, билд уже не соберется.

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

Но существет еще один вариант. Вы можите использовать один из своих репозиториев на Google Code или GitHub в качестве хранилища maven артефактов. Рассмотрим как это можно сделать

Некий Питер Коттл (Peter Cottle) сделал интерактивную обучалку по основам ветвления в Git. Есть несколько простых обучающих уровней, где нужно сделать пару коммитов, а затем merge или rebase, есть и сложные уровни, над которыми придется подумать. Можно также сохранять уровни и делиться ими с друзьями.

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

По роду своей деятельности я нередко становлюсь свидетелем «священных войн» между коллегами-программистами на тему, какую же систему контроля версий выбрать для того или иного проекта. Роль системы контроля версий особо остро ощущается в случаях разработки и поддержки проектов с длинной историей. Вариантов инструментов много, но я хочу сконцентрироваться на двух, на мой взгляд, наиболее перспективных: Mercurial и Git. Далее попробуем рассмотреть возможности обеих систем с позиции их внутреннего устройства.

Китай активно блокирует доступ к всяким страшным оппозиционным сайтам (Тянаньмей, 六四事件, 1989, баним Хабр в Китае). Для этого во всю используется DPI — глубокий анализ пакетов. Который позволяет не просто закрывать доступ к IP/доменному имени, а вырезать «лишнее», либо закрывать конкретные страницы. Если какой-то сайт (типа google) начинает использовать SSL, то SSL по этому направлению просто закрывают, оставляя пользователей с http-only.

Однако… Есть в мире сайты, которые Китай не рискует банить. Один из них — github. Если бан gmail или facebook оставит кого-то без любимой почты или возможности увидеть статусы друзей, то бан github'а оставит сотни и тысячи айтишных компаний без доступа к репозиториям open-source приложений и библиотек. А их на гитхабе уже over 5000000. Это означает простой в работе, или даже прекращение деятельности компании (мы-то знаем, что это не проблема, но китайцы свой файрвол воспринимают вполне серьёзно, и русский сценарий «мы всё запретим, а там дальше кому надо сам разберётся» не рассматривают).

При этом github использует SSL всегда. http доступа просто нет. Таким образом, прямой DPI не возможен, а некоторые товарищи, пронюхав про это, начали активно использовать github для обмена информацией о том, как обходить файрвол, адресами прокси-серверов и т.д.

Не желая мириться с подобным, Китай перенаправил трафик github на свои сервера. Разумеется, по HTTPS. И, разумеется, не имея сертификата гитхаба. Таким образом, пользователи китая начали получать предупреждения об ошибке сертификата, а китайская кровавая гэбня получила возможность читать и модифицировать чужие коммиты. Если, конечно, коммитящий или читающий, согласится с тем, что HTTPS с фальшивым сертификатом это нормально. Впрочем, вариантов (легальных) у него нет, т.к. другого варианта доступа к гитхабу не предусмотрено.

Это всё вместе называется man-in-the-middle. И это суровая китайская реальность.

Сегодня произошел большой шаг вперед в развитии Team Foundation Services — облачного сервиса Microsoft для разработчиков. Последние несколько месяцев команда TFS вела работу над новыми возможностями которые делают эти сервисы еще проще, удобнее и эффективнее. Одним из самых громких нововведений является интеграция популярной системы контроля версий Git с сервисами TFS. Работа на этом не прекращается и в обозримом будущем будет добавлено еще много интересных функций.

В среду, 23 января, Github запустил новый, значительно переработанный и улучшенный поиск кода, репозиториев и разработчиков. Теперь инфраструктуру обеспечивает кластер серверов ElasticSearch, который индексирует весь добавляемый код на лету, заметно переработан интерфейс, и, самое главное, есть много функциональных улучшений.

Caché-Git — это модуль контроля версий для Caché Studio, который обеспечивает вызов диалоговых окон TortoiseGit непосредственно из Studio и полуавтоматическую синхронизацию рутин между Caché и локальным репозиторием.

В каждой области выбираются пакеты, проекты, классы, рутины, dfi-файлы, csp-страницы, csp-приложения которые будут остлеживаться Caché-Git.

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

Caché-Git работает только на компьютерах, на которых установлен и сервер и клиент Caché. Caché-Git не будет работать при соединении с удалённым сервером.

Где взять

Репозиторий с Caché-Git находится по адресу github.com/intersystems-ru/cache-tort-git. Там же есть wiki, в которой описаны шаги по установке и использованию

Китайским программистам стало чуть труднее работать. С сегодняшнего дня в Китае блокируется github.com — крупнейший в интернете сайт с исходными кодами, социальная сеть и повседневный инструмент многих разработчиков.

Тест из-за Великого китайского файрвола показывает, что домен недоступен из Пекина, Шэньчжэня и других мест. Как и в других аналогичных случаях, блокировка осуществляется методом DNS-спуфинга c фильтрацией по URL. При запросе IP-адреса домена github.com китайские DNS-серверы возвращают неправильное значение 59.24.3.173 вместо правильного 207.97.227.239.



При запросе через OpenDNS или Google DNS, а также при использовании VPN сайт открывается.

Конец 2012 года прошел в суматохе, и каким-то образом я упустил из внимания две важные новости: в декабре вышел GitLab 4.0, а на середину ноября пришелся релиз GitLab Continuous Integration Server.

GitLab — это замечательное FOSS решение для хостинга git-репозиториев внутри закрытой инфраструктуры. Функционал во многом аналогичен GitHub, в частности доступны базовые возможности администрирования и разделения полномочий между пользователями, issue трекер, вики, code review и мердж реквесты (аналог пулл-реквестов на GitHub). И внеочередной плюс теперь, как по мне — это интеграция с GitLab CIS.

GitLab CIS — если GitLab послужит Вам заменой GitHub, то GitLab CIS призван стать заменой Travis CI. Набор фич соответствующий: запуск по git push, отдельные билды под бранч, интеграция с любыми git-репозиториями и бейджик со статусом текущего билда.

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

Что примечательно, работу ведут и курируют скромные украинские парни Дмитрий Запорожец и Валерий Сизов.

Ребята из команды github продолжают делать OpenSource простым и приятным занятием. С одним из последних обновлений они выкатили Contributions — дэшборд для профиля пользователя, в котором собрана вся информация о его активности.

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

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

Под катом можно найти любопытную подборку самых «зеленых» (в хорошем смысле) контрибьюторов на данный момент.

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

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

Дарова, хабр! (ничего оригинальнее не придумал)

Сомневаюсь что эта заметка тянет на полноценный пост, но я все же оставлю ее здесь. О чем же пойдет речь?

Все мы слышали о Git. Все мы знаем что он — хорош. Но лишь немногие пытаются что-то с ним делать, как-то его протвикерить. Сразу говорю, тут не будет ничего паранормального, только немного работы с файлом .gitconfig. Да-да, именно с тем файлом, который так трепетно пылится у вас в домашней директории.

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

Доброго времени суток!

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

В процессе перехода с SVN на Git мы столкнулись с необходимостью переписывания наших внутренних инструментов, связанных с развёртыванием кода, которые ориентировались на существование линейной истории правок (и разработку в trunk). На Хабре уже публиковались возможные решения этой проблемы через Git-SVN, но мы пошли другим путём. Нам нужна поддержка таких возможностей Git, как branching и merge, поэтому мы решили разобраться в основах, как же работает Git и каким способом должна осуществляться интеграция с ним.

 

Команда Github продолжает радовать своими обновлениями, и на этот раз они приглашают нас попробовать полностью обновленный github:gist.

Для тех, кто не был знаком с этим сервисом ранее — Gist предназначен для обмена кусочками кода (и не только кода) между людьми. В основе Gist лежит система контроля версий git, что делает возможным коллективную работу над материалом, поддержку форков и версионности.

Gist успел стать незаменимым инструментом в арсенале Open Source сообщества. Например, таким простым образом распространяется перформанс-патч для руби, упомянутый недавно на хабре.

Проблема

Жена очень тщательно относится к выбору одежды. Цвет нарядов должен сочетаться с цветотипом внешности, чтобы подчеркнуть природные достоинства и скрыть недостатки. Правильно подобранный цвет освежает лицо, делает его ярким и выразительным. Поэтому пришла идея сделать сайт, на котором можно без особых усилий определить — какой цвет тебе «к лицу».

pickyourcolor.github.com

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

Теория

Итак, освежим теоретические знания о том, что же такое rebase. Для начала вкратце — у вас есть две ветки — master и feature, обе локальные, feature была создана от master в состоянии A и содержит в себе коммиты C, D и E. В ветку master после отделения от нее ветки feature был сделан 1 коммит B.

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

Добрый день!

В статье я расскажу, как мы работаем с svn через git и почему не выбрали чистый git.

SVN

Subversion — это централизованная система контроля версий. Это главный ее минус и главный ее плюс :)

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

Главный минус — это merge… Те, кто часто делает мерж средствами svn, понимает о чем я.
Это медленно (даже меееееееедлееенно), требует постоянного соединения с репозиторием, а еще эти svn-properties, которые мешают читать diff.