Git *

Предлагаю использовать Tor для доступа к сайтам, к которым отсутствует прямой доступ.

Навеяно публикацией «Github опять заблокирован».

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

Почему-то сразу пришла в голову мысль об I2P.

И это действительно оказалось несложно.

Операция слияния (merge), выполняемая стандартными средствами git, хорошо работает для текстовых файлов, содержащих исходные тексты программ. Но слияние текстовых файлов, содержащих жестко структурированные данные, в частности JSON — это большая головная боль.

Для решения этой проблемы можно подключить к git'у отдельный инструмент слияния для JSON-файлов, который не работает построчно, а учитывает структуру JSON-объектов.

Предлагаю использовать для этого скрипт на javascript, который анализирует сливаемые JSON-файлы и делает слияние на основании структуры и вложенности объектов JSON.

Привет всем!

В предыдущем посте было рассказано о трудностях, которые испытывают разработчики при написании SQL-кода (причём актуальны эти проблемы не только для MS SQL Server). Здесь же рассказ о том, как использовать Git для версионного контроля кода SQL Server с помощью SQLFuse. Принцип тот же, что и с обычными файлами, но есть некоторые особенности.

Вне всяких сомнений, Pro Git — это одна из лучших книг про систему контроля версий git. Совсем недавно появилось второе издание этой замечательной книжки. Большие изменения произошли в издательском процессе: исходный код книги теперь хранится в AsciiDoc, а не в Markdown, а различные форматы (PDF, ePub и Mobi) автоматически генерируются с помощью O'Reilly Atlas platform. Разработка книги активно ведётся на гитхабе, актуальная online-версия находится в открытом доступе на официальном сайте, а любители печатной продукции могут заказать себе экземпляр на Amazon. Второе издание получилось почти в два раза больше первого: на сегодняшний день PDF-версия содержит 570 страниц. Помимо улучшения старого материала, книжка также пополнилась новыми главами и разделами:

Некоторое время назад при старте нового проекта было решено попробовать использовать Git вместо Subversion. Через некоторое время коллектив разделился на тех, кто любит Git (программисты), и тех, кто его ненавидит (дизайнеры и художники). Эксперимент по замене Subversion на Git провалился и на горизонте замаячила перспектива возвращения Subversion.

Почесав репу и содрогнувшись от связанных с Subversion воспоминаний мужики решили: «А что, мы же программисты!» и запилили свой Subversion с Git-ом и печеньками. Так родился проект git-as-svn.

Теперь мы можем использовать и Git, и Subversion с одним и тем же репозиторием. Причем доступ через Subversion напрямую использует данные Git-репозитория, в отличие, скажем, от SubGit, где для Subversion используется отдельный репозиторий.

* бесплатные, но на различных условиях.
Привет, Хабр. Пару часов назад мне пришло на почту письмо от гитхаба. Краткий пересказ: нет ничего более ценного чем практический опыт, но для огромного количества студентов многие профессиональные инструменты недоступны из-за высокой цены. И мы (гитхаб) с нашими партнерами решили создать Student Developer Pack — дать бесплатный доступ к отличным инструментам разработчика и собрать всё это в одном месте.
Если у вас имеется аккаунт на Гитхабе, и вы зарегистрированы в студенческой программе(GitHub Education, если нет — то регистрируетесь и получаете пак), то можно получить довольно большой список инструментов:

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

В универе файлов стало еще больше, количество компьютеров дома возросло до 3 штук, я начал делать бэкапы. Пока просто, делая копии текущих папок на компьютере, не особо заморачиваясь с их структурой. Под конец обучения я задумался, стоит ли хранить огромное количество своих документов на внешних серверах. Подумав немного, решил, что лучше так не делать и решил слезть с иглы Evernote. Предварительно я продумал структуру хранения файлов на компьютере, чтобы даже без поиска легко найти нужную информацию. Каждой теме, которая меня интересовала, я создавал папку в /home/username папке. Это я называл категориями. Внутри каждой категории были подпапки-проекты, обязательной была папка misc практически в каждой папке, чтобы в файловом менеджере не видеть кучи беспорядочно наваленных неструктурированных файлов. Например, у меня были папки Bioinformatics/Aligner, Development/Projects/GameOfLife. Были четкие правила наименования файлов и папок (без нижних подчеркиваний, camelCase, папки с большой буквы, файлы с маленькой). Всё вроде было хорошо, но я ленился и не всегда красиво выкладывал файлики в нужные папки, что в конечном итоге привело к захламлению моей структуры. Я решил попробовать что-то другое…

Я провел весь вчерашний день, напряженно работая, чтобы закрыть долгую и порядком надоевшую задачу. Было достаточно поздно, когда я закомитил изменения и отправил на пуш. Гит привычно ругнулся что не может, потому что есть свежие правки. Окей, pull, push. Теперь вроде нормально, можно идти спать.

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

На следующий день я еще раз сделал деплой на тестовый сервер, но он упорно показывал старую версию. Решил свериться с логом Гита… мой коммит… ЕГО ПРОСТО НЕ БЫЛО! Его не было нигде, ни в локальной копии, ни в удаленной. Его не было даже в исходниках на диске. Файлы, оставленные открытыми в редакторе, были пусты. Единственный фактом, связывающим меня в тот момент с реальностью, был скомпилированный js-файл проекта, оставшийся после сборки исходников. Он работал именно так, как я оставил его вчера.

Доброго времени суток. У меня есть маленький подручный сервер, который используется как git сервер для показа клиенту проекта и т.д. Сервер работает на операционной системе Slackware v.13.1.0, семейства linux. Почему не Debian или Ubuntu — так исторически сложилось. Для просмотра git репозиториев я использовал cgit. Недавно возникла необходимость начать использовать GitLab. Если интересно — добро пожаловать под кат.

Какие системы контроля версий Вы используете (для собственных проектов и для работы)?

Сейчас вы с трудом найдете профессионального разработчика, который не пользуется системой контроля версий (VCS) такой, как Git.
Но есть и не мало тех среди нас, кто не использует VCS по причине предвзятого мнения о системах контроля версий.
Ниже несколько мифов и отговорок, которые препятствуют внедрению в рабочий процесс разработчика Git (или любой другой VCS).

Состоялся долгожданный релиз, содержащий достаточно много обновлений, нововведений и багфиксов.

Одним из самых главных изменений является поведение команды git push. Теперь по умолчанию (если не указана ветка) push будет осуществлен только в текущую ветку. Git 1.* по умолчанию делал push во все ветки, которые были изменены локально. Конечно же можно вернуться к прежнему поведению, для этого служит опция push.default.

Поведение Git 1.*:

git config --global push.default matching

Новое поведение по умолчанию в Git 2.0:

git config --global push.default simple

Другие изменения:

В нашей небольшой компании (6 backend + 4 frontend разработчика) для code review (далее CR) мы использовали Gerrit. Gerrit используется, например, для разработки Android. Это инструмент, дающий очень много свободы в настройке процесса CR, но мы от него отказались. Почему? Он прекрасен для суровых backend парней, который легко делают interactive rebase, merge, resolve conflict, amend commit и т.д. Люди из frontend команды по ночам плачут в подушку от тягот рабочего процесса в Gerrit.

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

Мы пришли к Bitbucket. Под катом ответы на вопросы почему Bitbucket и почему не GitHub.

Глава 1

Все началось с того, что мне подарили PipBoy. Очень удобная вещь: захотелось пиццы — набрал команду callPizza() и вот уже курьер везёт тебе горячий круг! «Как здорово!» — думал я.
Недавно я устроился на работу в должности программиста. Коллеги мне сразу стали расхваливать систему контроля версий Git. Ну что ж. Раз говорят, что хороший — нужно читать про него. Прочитав первую книгу, в голове был полный сумбур. Я решительно ничего не понимал. «Что за бабуйня такая? Для чего вообще это нужно?» — показалось мне.
После тяжёлого трудового дня я направился домой. Был тёплый августовский вечер, во дворе играли детишки. У каждого из них на руке был свой PipBoy. Насколько же проникли технологии в нашу жизнь. Ведь совсем недавно ничего этого не было, а первые образцы стоили сотни тысяч долларов. А вот теперь почти у каждого на руке! Погрузившись в свои мысли, я вовсе не заметил, как из-за угла кто-то выехал на мотоцикле. Мчавшись на огромной скорости, он совершенно не замечал людей на дороге. А тем более во дворе.

Канадский программист Юрий Рашковский решил объединить две популярные технологии — систему контроля версий 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