Git *

Канадский программист Юрий Рашковский решил объединить две популярные технологии — систему контроля версий Git и распределённую БД Биткоин. Его проект Gitchain, который недавно успешно собрал на Кикстартере запланированные 10 000 долларов, по задумке автора позволит сделать систему контроля версий Git по-настоящему распределённой. С ростом популярности крупных публичных репозиториев, таких как Гитхаб, система Git, которая изначально задумывалась как распределённая, фактически используется централизованно и полностью зависит от сторонних серверов.

Для синхронизации файлов проекта, ведения истории мы используем системы контроля версий, например, Git. Однако, когда у меня встал вопрос о контроле версий структуры базы MySQL — удовлетворяющего решения найти не удалось.
Замечу, во многих фреймворках и ORM существуют необходимые механизмы «из коробки» — миграции, версионность и т.д. А вот для нативной работы с MySQL — приходится все делать ручками. И пришла идея попытаться создать автоматическую систему для отслеживания изменений.

Привет, Хабр!

Тем, кто работает с Git, хорошо знаком способ отредактировать последний коммит командой git commit --amend. Это удобно для мелких правок (изменить комментарий к коммиту, поправить строчку в коде и т.п.), потому что частенько хорошие мысли по поводу коммита приходят в голову уже после того, как этот коммит сделан.

Но с данным способом правки коммитов следует быть осторожным в случае, когда вы работаете с удалённым репозиторием и ещё более осторожным, когда вы работаете над исходным кодом в составе команды. Область безопасного использования опции --amend заканчивается там, где начинается область использования команды git push.

Привет, Хабр! В очередной раз на глаза попался очень интересный репозиторий. Эта шпаргалка по самым тайным и функциональным возможностям Git и GitHub появилась благодаря выступлениям Зака Холмана одну из статей которого я уже переводил Git and GitHub Secrets на Aloha Ruby Conference 2012 и More Git and GitHub Secrets на WDCNZ 2013. Стоит сказать о том, что проект набрал свыше 1000 старов менее чем за 12 часов. Приведу несколько примеров:

Hub — Git Wrapper

Hub — это оболочка над Git, которая сокращает потраченное время на лишнее нажатии клавиш при работе с Git.

$ hub clone tiimgreen/toc
> git clone https://github.com/tiimgreen/toc.git

На hub можно сделать алиас git и все будет выглядеть еще удобнее:

# Remote
$ git remote add rtomayko
> git remote add rtomayko git://github.com/rtomayko/CURRENT_REPO.git

#Fetch
$ git fetch mislav
> git remote add mislav git://github.com/mislav/REPO.git

#Fork
$ git fork
[ repo forked on GitHub ]
> git remote add -f YOUR_USER git@github.com:YOUR_USER/CURRENT_REPO.git

Итак, представим, что у нас девственно чистая система, в которой нет ни Putty, ни msysgit. Приступим к настройке нашего рабочего окружения.

Установка Putty

Качаем, устанавливаем, генерим и настраиваем ключ c Pagent (инструкция, ?).

Добавляем ключ на git-сервер

Открываем страницу с SSH ключами и добавляем из буфера наш ключ

Создаём и сохраняем в Putty профиль «git@github.com» и проверяем, что удаётся зайти по ключу – должна открыться и сразу закрыться консоль.

Устанавливаем и настраиваем msysgit

На хабре есть пост habrahabr.ru/post/195054 «Как бесплатно получить Micro аккаунт на GitHub студенту в России» от 24 сентября 2013 года и больше никаких упоминаний об этой интересной программе от Github'а.
А тем временем, 10 февраля 2014 года Github запустил отдельный сайт education.github.com и сообщили в своем блоге, что они уже много лет предлагают образовательные скидки и более чем 1200 учебных классов и 7000 студентов воспользовались этим предложением на данный момент.
Теперь же они эту программу запустили официально, сделали отдельный сайт и предложили следующее:

• Бесплатную Micro подписку для студентов и преподавателей
• Бесплатные Github-организации для использования в классах
• 25% скидка во всех остальных случаях для использования в учебных целях

Некоторое время назад мы анонсировали поддержку Git в Visual Studio и TFS. Для того, чтобы научиться правильно готовить все это, я сам прошел весь путь и хочу рассказать вам о нем. Ниже — о том, как использовать Git в VS.

Каждый, кто посвятил себя работе с компьютерами, хоть раз, но сталкивался с распространёнными высказываниями вроде: «Помоги мне сделать %work%, ты ведь всё равно без дела за компом сидишь». Особенно часто в эту ситуацию попадаёшь, когда работаешь непосредственно в окружении коллег проделывающих ручную работу. Для этих людей ты зачастую представляешься воплощением безделия и главным пользователем youtube.
Сейчас я покажу вам один из приёмов, как превратиться в глазах сотрудников из лодыря в волшебника.

GitHub сегодня анонсировал запуск GitHub Developer Program, предназначенной для лучшего информирования разработчиков о происходящих изменения и коллективной работы над улучшением сервиса.



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

mcdiff

В составе Midnight Commander, помимо всем известного редактора mcedit, есть не менее замечательная утилита для сравнения файлов «бок о бок» (side-by-side) — mcdiff. В ней можно сравнивать и при необходимости производить полное или частичное слияние в обе стороны.



Историю появления утилиты mcdif когда-то уже рассказывал тут но ближе к делу…

Введение

В связи с тем, что не многие, как оказалось, знают про 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 изменение коммитов».