Рубрика «Git» - 38

Разработка

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

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

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

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

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

Читать полностью »

image

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

Компания GitHub запустила новый сайт — choosealicense.com — он поможет упростить выбор лицензии для проектов с открытым исходным кодом. Теперь, при создании нового репозитория на GitHub вы можете выбрать тип лицензии. В прошлом GitHub обвинили в том, что они не напоминают пользователям, что их публичный репозиторий переходит в общественное достояние, но оставляют его защищенным авторским правом и без лицензии.
Читать полностью »

Вливание legacy истории в дерево: нахождение оптимальной точки ответвленияПо долгу службы мне досталась в наследство некая система, имеющая ~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

Читать полностью »

Мы представляем шестое из серии интервью с техническими руководителями проекта OpenStack в блоге Mirantis. Наша цель — обучить более широкое сообщество технических специалистов и помочь людям понять, как они могут внести вклад в проект OpenStack и извлечь из него выгоду. Естественно, ниже изложена точка зрения интервьюируемого, а не компании Mirantis.

Ниже мы представляем интервью Анны Джентл (Anne Gentle), координатора по разработке документации сообщества OpenStack.Читать полностью »

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

Краткое предисловие переводчика.

Захватывающе интересная статья одного из разработчиков «GitHub Inc.» о принятом в компании рабочем процессе потребовала употребить пару специальных терминов при переводе.

То понятие, для которого на английском языке достаточно одного слóва «workflow», на русский приходится переводить словосочетанием — «рабочий процесс». Ничего лучше не знаю ни сам я, ни при помощи гуглоперевода — так что и мне, и читателям придётся с этим мириться, хотя бы и поневоле.

Другое понятие, «deploy», на русский часто переводят словом «развёртывание», но в моём переводе я решил вспомнить оборот из советского делопроизводства — «внедрение инноваций на производстве» — и стану говорить именно о «внедрении» новых фич. Дело в том, что описанный ниже рабочий процесс не имеет «выпусков» (releases), что делает несколько неудобными и речи о каком-либо «развёртывании» их.

К сожалению, некоторые переводчики бывают склонны грубо убивать сочную метафору «иньекции» (или даже «впрыскивания», если угодно), содержающуюся в термине «code injection», так что и его также переводят словосочетанием «внедрение кода». Эта путаница огорчает меня, но ничего не могу поделать. Просто имейте в виду, что здесь «внедрением кода» я стану назвать внедрение его именно в производство (на продакшен), а не в чей-нибудь чужой код.

Я стремился употреблять словосочетание «в Гитхабе» в значении «в компании GitHub Inc.», а «на Гитхабе» — в значении «на сайте GitHub.com». Правда, иногда разделять их сложновато.

Проблемы git-flow

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

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

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

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

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

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

Читать полностью »

Мобильная версия GitHub

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

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js