Доброго времени суток уважаемые читатели. Буквально только что увидел потрясающий проект на GitHub от FredrikNoren.
Необходим Node.js версии 0.10 или выше и npm версии 1.3.1 или выше
npm install -g ungitМы представляем шестое из серии интервью с техническими руководителями проекта OpenStack в блоге Mirantis. Наша цель — обучить более широкое сообщество технических специалистов и помочь людям понять, как они могут внести вклад в проект OpenStack и извлечь из него выгоду. Естественно, ниже изложена точка зрения интервьюируемого, а не компании Mirantis.
Ниже мы представляем интервью Анны Джентл (Anne Gentle), координатора по разработке документации сообщества OpenStack.Читать полностью »
13 августа GitHub порадовал пользователей очередным приятным нововведением — в этот раз сделан шаг в сторону дальнейшей социализации.
Был выпущен новый способ просматривать, что находится в тренде на сервисе с удобством фильтрации по временному периоду, трендовым проектам, разработчикам и языкам программирования.
Читать полностью »
То понятие, для которого на английском языке достаточно одного слóва «workflow», на русский приходится переводить словосочетанием — «рабочий процесс». Ничего лучше не знаю ни сам я, ни при помощи гуглоперевода — так что и мне, и читателям придётся с этим мириться, хотя бы и поневоле.
Другое понятие, «deploy», на русский часто переводят словом «развёртывание», но в моём переводе я решил вспомнить оборот из советского делопроизводства — «внедрение инноваций на производстве» — и стану говорить именно о «внедрении» новых фич. Дело в том, что описанный ниже рабочий процесс не имеет «выпусков» (releases), что делает несколько неудобными и речи о каком-либо «развёртывании» их.
К сожалению, некоторые переводчики бывают склонны грубо убивать сочную метафору «иньекции» (или даже «впрыскивания», если угодно), содержающуюся в термине «code injection», так что и его также переводят словосочетанием «внедрение кода». Эта путаница огорчает меня, но ничего не могу поделать. Просто имейте в виду, что здесь «внедрением кода» я стану назвать внедрение его именно в производство (на продакшен), а не в чей-нибудь чужой код.
Я стремился употреблять словосочетание «в Гитхабе» в значении «в компании GitHub Inc.», а «на Гитхабе» — в значении «на сайте GitHub.com». Правда, иногда разделять их сложновато.
Повсюду путешествую, преподавая Git людям — и почти на каждом уроке и семинаре, недавно мною проведённом, меня спрашивали, что я думаю о git-flow. Я всегда отвечал, что думаю, что этот подход великолепен — он взял систему (Git), для которой могут существовать мириады возможных рабочих процессов, и задокументировал один проверенный и гибкий процесс, который для многих разработчиков годится при довольно простом употреблении. Подход этот также становится чем-то вроде стандарта, так что разработчики могут переходить от проекта к проекту и из компании в компанию, оставаясь знакомыми с этим стандартизированным рабочим процессом.
Однако и у git-flow есть проблемы. Я не раз слыхал мнения людей, выражавших неприязнь к тому, что ветви фич отходят от develop вместо master, или к манере обращения с хотфиксами, но эти проблемы сравнительно невелики.
Для меня одной из более крупных проблем git-flow стала его сложность — бóльшая, чем на самом деле требуется большинству разработчиков и рабочих групп. Его сложность ужé привела к появлению скрипта-помощника для поддержания рабочего процесса. Само по себе это круто, но проблема в том, что помощник работает не из GUI Git, а из командной строки, и получается, что те самые люди, которым необходимо действительно хорошо выучить сложный рабочий процесс, потому что им вручную придётся пройти все шаги его — для этих-то людей система и недостаточно удобна для того, чтобы использовать её из командной строки. Вот что становится крупною проблемою.
Все эти проблемы можно без труда преодолеть, следуя гораздо более простому рабочему процессу. Мы не пользуемся git-flow в Гитхабе. Наш рабочий процесс основан (и всегда был основан) на более простом подходе к Git.
Простота его имеет несколько достоинств. Во-первых, людям проще понять его, так что они быстрее начинают использовать его, реже (или вовсе никогда не) допускают ошибки, требующие отката. Кроме того, не требуется скрипт-обёртка, помогающий следовать процессу, так что употребление GUI (и т. п.) не создаёт проблем.
GitHub наконец-то представил мобильную версию сайта. «GitHub — отличный инструмент для разработки и публикации программного обеспечения, но большая часть процесса разработки по-прежнему требует наличия ноутбука или настольного компьютера. С другой стороны, наши телефоны не очень пригодны для написания кода, зато идеально подходят для просмотра и чтения. На этом мы и сконцентрировались при создании мобильной версии сайта», — пишут разработчики.
Читать полностью »
Это руководство подскажет вам, как буквально за 10 минут создать простой, удобный и надежный аналог Dropbox, который будет под вашим полным контролем и позволит обмениваться файлами с коллегами по локальной сети.
Читать полностью »
В этой статье я расскажу как мы построили процесс разработки сайта не поднимая локальных копий веб-сервера в небольшой команде разработчиков с использованием Xdebug на тестовом сервере и автоматического развертывания репозитория на боевой сервер.
Наверняка, многие из вас слышали или знают по собственному опыту, что системы контроля версий плохо дружат с бинарными файлами, большими файлами и в особенности — с большими бинарными файлами. Здесь и далее речь идет о современных популярных распределенных системах контроля версий вроде Mercurial и GIT.
Зачастую, это не имеет значения. Уж не знаю, причина это или следствие, но системы контроля версий используются в основном для хранения относительно небольших текстовых файлов. Иногда несколько картинок или библиотек.
Если же проект использует большое количество картинок в высоком разрешении, звуковых файлов, исходных файлов графических, 3D, видео или любых других редакторов, то это проблема. Все эти файлы как правило большие и бинарные, а это означает, что все преимущества и удобства систем контроля версий и хостингов репозиториев со всеми сопутстсвующими сервисами становятся недоступны.
Далее мы на примере рассмотрим интеграцию систем контроля версий и Amazon S3 (облачного хранилища файлов), чтобы использовать преимущества обоих решений и компенсировать недостатки.
Решение написано на C#, использует API Amazon Web Services и показан пример настройки для Mercurial репозитория. Код открыт, ссылка будет в конце статьи. Все написано более или менее модульно, так что добавление поддержки чего-то кроме Amazon S3 не должно составить труда. Могу предположить, что для GIT настроить будет так же легко.
Читать полностью »
Bitbucket + Eclipse. Инструкция по настройке от А до Я.
После перехода с Windows на Linux и установки Eclipse 4.3 Kepler у меня появилась необходимость добавления своего приложения для Android в систему контроля версий. Разрабатываю я его пока один и контроль версий нужен, чтобы видеть историю изменений и иметь возможность откатиться на более раннюю версию, плюс это хорошее и удобное резервное копирование проекта.
Решение данной задачи я собирал в нескольких местах, после чего родилась идея написать подробное руководство.
Делать свой первый проект открытым я пока не планировал, поэтому вместо популярного GitHub выбрал Bitbucket. Он позволяет делать любое кол-во открытых и закрытых репозиториев совершенно бесплатно.
Отмечу, что в инструкции очень много скриншотов!
Читать полностью »
Разработчики Github реализовали новую функцию Releases для удобного распространения ПО конечным пользователям. Зайдя в раздел Releases, пользователь всегда может найти последнюю версию программы, changelog и полную историю версий. Ссылка на релизы помещена на главную страницу проекта.
