Как создать организацию github

6.4 GitHub — Управление организацией

Управление организацией

В дополнение к персональным аккаунтам, на GitHub есть организации. Для организаций, как и для персональных аккаунтов, существует окружение, где находятся все проекты, но в остальном много отличий. Такие аккаунты представляют собой группу людей, совместно владеющих проектами, и существует много инструментов для разделения их на подгруппы. Обычно, такие аккаунты используются группами, которые работают с публичными проектами (такими как «perl» или «rails»), или компаниями (такими как «google» или «twitter»).

Основы организаций

Создать новую организацию очень легко; просто нажмите на иконку «+» в правом верхнем углу страницы GitHub и выберите пункт «New organization» из меню.

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

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

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

Как для персонального аккаунта, так и для организации вы можете загрузить отдельную картинку. Аналогично и для главной страницы, где приводится список доступных репозиториев организации.

Теперь, давайте рассмотрим отличительные черты аккаунтов организаций.

Команды

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

Например, у вашей компании есть три репозитория: frontend , backend и deployscripts . Вы бы хотели, чтобы ваши разработчики HTML/CSS/JavaScript имели доступ к frontend и возможно к backend , а ваши администраторы имели доступ к backend и deployscripts . С помощью команд это легко реализовать не настраивая доступ к каждому репозиторию для каждого участника.

Страница Организации представляет собой простую панель управления репозиториями, пользователями и командами в пределах данной организации.

Для управления командами нужно перейти на закладку ‘Teams’ справа вверху на странице Страница организации. Это приведёт вас на страницу где можно добавлять пользователей в команду, добавлять команде репозитории или управлять настройками и правами доступа. Каждая команда может иметь только следующие уровни доступа к репозиториям: «только чтение», «чтение/запись» или «администратор». Уровень доступа может быть изменен нажатием кнопки «Settings» на странице Страница команды.

Когда вы пригласите кого-нибудь в команду, то будет отправлено письмо с приглашением.

Упоминания команд ( @mentions ), такие как @acmecorp/frontend , работают точно так же как и упоминания отдельных пользователей, за исключением того, что уведомляются все члены команды. Это полезно когда вы хотите привлечь внимание кого-нибудь из команды, но точно не знаете кого спросить.

Пользователь может принадлежать любому числу команд, поэтому не ограничивайте себя командами, разделёнными по уровню доступа. Специализированные команды, такие как ux , css или refactoring полезны для вопросов одной тематики, тогда как команды legal и colorblind — для вопросов другой тематики.

Журнал аудита

Организации так же предоставляют владельцам информацию о всех происходящих событиях внутри них. Перейдя на закладку ‘Audit Log’ вы можете увидеть произошедшие события на уровне организации, кто участвовал в них и в какой точке мира они произошли.

Вы так же можете отфильтровать события по типам, определенным людям или местам.

Источник

Как организовать сотрудничество на GitHub

Если вы еще не в курсе, GitHub это очень эффективный способ организации совместной работы над проектами.

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

Как можно присоединиться к разработке проекта? Думаю, вам известно, как использовать Git , чтобы вносить изменения в файлы и переносить их на сервер. Но есть преимущества принятия участия в разработке больших проектов с открытым кодом, и GitHub однозначно лучшее для этого место.

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

Начните с малого

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

Не бойтесь начать с малого : вместо того, чтобы пытаться исправить большие ошибки ( баги ) или переписать целый модуль, попробуйте найти недостатки в документации или ошибки кроссплатформенности, или даже простые синтаксические и грамматические ошибки ( пример на GitHub от пользователя mzgol).

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

Если вы получили сообщение, в котором имеется посильная для вас задача, то можете взять ее в работу, а после окончания, послать автору так называемый pull request , или запрос на включение сделанных изменений (о том, как это сделать, мы поговорим чуть ниже).

Изучите экосистему проекта

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

Например, GitHub стандартизовал файл CONTRIBUTING.md (ознакомьтесь для примера с этим документом ). Подобные инструкции поддерживаются людьми, которые обслуживают базы кодов.

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

Теперь, когда вы являетесь частью экосистемы проекта, как же вам все-таки внести изменения?

Использование Pull-Request для внесения изменений

Рабочая среда для внесения изменений в код, сначала может показаться сложной .

Первое, что следует уяснить, это важность следования стандартам и соглашениям, принятым в проекте, над которым вы работаете (что уже обсуждалось выше). Стандартная рабочая среда на GitHub достаточно проста и позволяет:

• Ответвлять выбранный репозиторий в ваш аккаунт;
• Копировать репозиторий на локальную машину;
• Выбирать ветку ( topic branch ) и вносить в неё изменения;
• Переносить изменения из других веток в свою;
• Использовать различные инструменты GitHub, чтобы создавать pull request’ы через обсуждения;
• Применять полученные изменения;
• Pull request сливается с проектом (как правило с основной веткой – master branch ), а topic branch удаляется из репозитария.

Внутри рабочей среды, вы можете увидеть множество отличий между разными проектами. Например, различия в соглашениях о названии тем. Некоторые проекты могут использовать соглашения типа bug_345 , где 345 это идентификатор (ID #) GitHub issue .

Некоторые проекты используют короткие сообщения с правками, другие же – более длинные. Далее приведена пошаговая инструкция, которая поможет разобраться с интерфейсом и функционалом.

Шаг 1: Ответвление (Forking)

Ответвление репозитария на GitHub.com

Шаг 2: Клонирование

Клонировать репозитарий можно, используя URL-адрес, показанный на сайдбаре справа:

Шаг 3: Добавление Upstream Remote

Внесите изменения в клонированную директорию и тогда вы сможете добавить upstream remote , то есть указать удаленный репозиторий, с которым будет происходить слияние локальных правок:

Теперь вы сможете вносить изменения локально и синхронизировать их с удаленным репозиторием:

Шаг 4: Выбор ветки (Topic Branch)

Перед внесением изменений, выберите ветку:

Шаг 5: Создание правок

Теперь, вы можете внести изменения и создать коммит, который будет отслеживать только эти изменения:

Шаг 6: Внесение правок

Далее, необходимо внести изменения, сделанные в ветке вашего проекта:

Шаг 7: Создание Pull Request’а

Наконец, вы можете создать pull request . Для этого, перейдите в вашу ветку репозитария. Там вы увидите надпись « Недавно измененные вами ветки » ( your recently pushed branches ), и если это так, можно выбрать « Сравнить и сделать Pull Request » ( Compare and Pull Request ).

В противном случае, вы можете выбрать вашу ветку из выпадающего списка и нажать « Pull Request » или « Compare » в верхней правой части секции репозитария.

Создание pull request посредством выпадающего списка веток

Любой из этих способов переместит вас на страницу, где вы можете создать pull request и комментарий к нему. Эта страница также включает в себя визуальное представление сделанных изменений. Это упрощает администратору проекта отслеживание изменений и принятие решения о внесении вашего коммита.

Если у кого-то имеются вопросы, они могут задать их в комментариях, а также попросить вас очистить и послать ваш pull request заново, или удалить его.

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

Как написал работник Github Зак Холман ( Zach Holman ) в документе « How GitHub Uses GitHub to Build GitHub », pull request это обсуждение. Именно в таком ключе они и должны восприниматься; вместо ожидания мгновенного принятия вашей правки, следует ждать её обсуждения.

GitHub Issues + Pull Requests = Дзен управления проектом

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

У Issues много отличных встроенных возможностей, но одна из наиболее важных, это интеграция с pull request’ами . Пользователь может сослаться на issue в своем коммите, просто добавив туда его цифровой ID.

Этот коммит автоматически пометит issue №3 как закрытый, когда соответствующий pull request будет принят. Данный способ автоматизации делает GitHub прекрасным инструментом для управления процессом разработки.

Поиск других способов взаимодействия

Зачастую, большие open-source проекты имеют преимущество при совместной работе над ними нескольких людей.

Не заблуждайтесь думая, что единственным способом внести вклад в проект является использование pull request’ов .

Например, такой проект, как Ruby on Rails , был известен своим сообществом; оно отвечало на вопросы на форумах и IRC-чатах, чтобы помочь повысить осведомленность об этом фреймворке, а также помочь направить его развитие путем обсуждения идей и найденных ошибок.

Такие способы взаимодействия обычно представлены форумами и чатами. Но не только: это могут быть почтовые рассылки, аудио- и видеоконференции, которые могут помочь определить направление развития проекта и создать живое, продуктивное сообщество вокруг проекта. Без такого сообщества, pull request’ы не эффективны.

Все зависит от отношения

Запомните, что проекты с открытым кодом возглавляются людьми, для которых преумножение и распространение знаний является самым важным. Участие в таких проектах будет более эффективным, если вы будете иметь правильное отношение, смысл которого заключен в следующем вопросе: « Чем я могу помочь? », который отличается от отношения « Помогу, чем смогу ».

Люди в мире открытого исходного кода, хотят работать с теми, кто движим желанием помочь другим.

Заключение

Если вы заинтересовались разработкой open-source проектов, то это прекрасно! Если вы решились принять участие в одном из них, то не забудьте о правильном отношении и принципе « начни с малого ». Это приблизит вас к моменту, когда вы увидите свое имя в только что присоединенном к проекту pull request’е .

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

Потенциал GitHub и мир open-source продолжают свой рост каждый день; начните сотрудничать с другими разработчиками и станьте частью этого мира!

Источник

Совместная разработка в команде на GitHub

GitHub стал краеугольным камнем для всего программного обеспечения с открытым исходным кодом. Разработчики любят его, сотрудничают с ним и постоянно создают новые великолепные проекты с помощью него. Помимо хостинга вашего кода, главная привлекательность GitHub заключается в использовании его в качестве инструмента совместной работы. В этом уроке давайте рассмотрим некоторые из наиболее полезных функций GitHub, особенно полезных для работы в командах, что делает его еще более эффективным, продуктивным и, самое главное, забавным!

Github разработка в команде

Одна вещь, которую я считаю очень полезной, — это интеграция Github Wiki в основной проект исходного кода.

В этом руководстве предполагается, что вы уже знакомы с Git, распределенной системой управления версиями с открытым исходным кодом, созданной Линусом Торвальдсом в 2005 году. Если вам нужна ревизия или поиск в Git, посетите наш предыдущий курс скринкастов или даже несколько статей на эту тему. Кроме того, у вас уже должна быть учетная запись Github, а также некоторые базовые функции, такие как создание репозитория и внесение изменений в Github. Если нет, обратитесь к предыдущим учебникам.

В мире разработки при создании своего проекта работа в команде будет неизбежной. В этом руководстве по совместной разработке на Github мы изучим некоторые из наиболее распространенных инструментов, которые нам обычно нужны при работе с командами разработчиков программного обеспечения. Обсуждаемые инструменты:

1. Добавление членов команды — организация и соавторы
2. Pull Requests — Отправка и слияние
3. Отслеживание ошибок — issues Github
4. Аналитика — Графики и сети
5. Управление проектами — Trello & Pivotal Tracker
6. Непрерывная интеграция — Travis CI
7. Ревью кода — комментарии к строкам и URL-запросы
8. Документация — Wiki & Hubot

Предпочитаете скринкаст?

Если вы предпочитаете скринкаст, то прыгайте чуть ниже, чтобы просмотреть его, а этот учебник используйте в качестве сопутствующих заметок:

Инструмент 1 : Добавление членов команды

Как правило, существует два способа настройки Github для совместной работы:

1. Организации. Владелец организации может создавать множество команд с разными уровнями доступа для различных репозиториев
2. Сотрудники. Владелец репозитория может добавлять коллабораторов с доступом Read + Write для одного репозитория

Organizations

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

Чтобы получить доступ к странице команд для вашей Организации, вы можете просто перейти на http://github.com/organizations/[organization-name]/teams , чтобы просмотреть их или даже посетить https://github.com/organizations/[organization-name]/teams/new Для создания новых команд с тремя уровнями доступа, такими как:

1. Pull Only: выборка и слияние с другим репозиторием или локальной копией. Доступ только для чтения.
2. Push and Pull: (1) наряду с обновлением удаленного репозитория. Читайте + Запись.
3. Push, Pull & Administrative: (1), (2) наряду с правами на информацию о выставлении счетов, созданием команд, а также удаление аккаунтов организации. Чтение + запись + доступ администратора

Соавторы

Коллабораторы (соавторы) используются для предоставления возможности «читать + писать» в один репозиторий, принадлежащий личной учетной записи. Чтобы добавить Collaborators (другие личные учетные записи Github), перейдите на страницу https://github.com/[username]/[repo-name]/settings/collaboration :

После этого каждый соавтор увидит изменение статуса доступа на странице репозитория. После того, как у нас есть доступ на запись к репозиторию, мы можем сделать git clone , поработать над изменениями, сделать git pull для извлечения и слияния любых изменений в удаленном репозитории и, в конечном счете, git push , для обновления удаленного репозитория с собственными изменениями:

Инструмент 2: Pull Requests

Pull Requests — отличный способ внести свой вклад в репозиторий, сделав его форк. В конце дня, если мы хотим, мы можем отправить pull request владельцу репозитория, чтобы объединить наши изменения кода. Сам pull request может включать обсуждение качества кода, функций или даже общей стратегии.

Давайте теперь рассмотрим основные шаги для pull request.

Инициирование pull request

В Github есть две модели для pull request:

1. Модель Fork & Pull — используется в общедоступном репозитории, на который у вас нет push-доступа
2. Share Repository Model — используется в частном репозитории, на который у нас есть push-доступ. В этом случае форк не требуется.

Здесь мы видим рабочий процесс между двумя пользователями ( repo-owner и forked-repo-owner ) для модели Fork and Pull:

Определите репозиторий Github, в который вы хотите внести свой вклад, и нажмите кнопку «Fork», чтобы создать клон репозитория в вашей собственной учетной записи Github:

Слияние пул реквеста

Если вы являетесь владельцем оригинального репозитория, существует два способа слияния входящего пул реквеста:

Слияние непосредственно на Github: если мы делаем слияние непосредственно на Github, то убедитесь, что нет конфликтов, и реквест готов к объединению в ведущую ветку. Владелец оригинального хранилища может просто щелкнуть зеленую кнопку «Слить запрос», чтобы сделать это:

Существуют различные модели создания веток, используемые для управления версиями в командах разработки программного обеспечения. Вот две популярные модели рабочего процесса git: (1) рабочий процесс Github, который имеет простую ветвящуюся модель и использует запросы на pull, и (2) Gitflow, который имеет более обширное разветвление. Модель, которая в конечном итоге будет выбрана, определенно будет меняться в зависимости от команды, проекта и ситуации.

Инструмент 3: Отслеживание ошибок

Pull Requests — отличный способ внести свой вклад в репозиторий сделав его форк.

В Github центр для отслеживания ошибок — это issues. Несмотря на то, что они в основном предназначены для отслеживания ошибок, также полезно использовать «Issues» следующими способами:

• Ошибки: вещи, которые явно сломаны и нуждаются в исправлениях
• Особенности: Удивительные крутые новые идеи для реализации
• Список дел: контрольный список задач для завершения

Давайте рассмотрим некоторые особенности проблем:

1. Labels: цветные категории для каждого issue. Они полезны для фильтрации.
2. Milestones: они относятся к категориям, которые могут быть связаны с каждым issue, и полезны для определения того, какие проблемы необходимо обрабатывать для следующего релиза. Кроме того, поскольку этапы связаны с проблемами, то автоматически обновляется индикатор выполнения при закрытии каждой связанной проблемы.
3. Search: Автокомплит поиска для issues и milestones

Инструмент 4: Аналитика

Понятно, что мы можем тесно связать наш список задач и обновления с нашими кодами.

Есть два инструмента, которые дают представление о репозитории — Graphs and Network. Графики Github отображает соавторов и их коммиты, в то время как Github Network обеспечивает визуализацию для каждого участника. Эти аналитики и графики становятся очень мощными, особенно при работе в командах.

Графики

Графики предоставляют подробную аналитику, такую как:

• Contributors: кто был соавтором? И сколько строк кода они добавляли или удаляли?
• Commit Activity: В какие недели произошли фиксации в прошлом году?
• Code Frequency: сколько строк кода было зафиксировано на протяжении всего жизненного цикла проекта?
• Punchcard: В какое время дня обычно совершаются коммиты?

Network

Github Network — это мощный инструмент, который позволяет вам видеть, как коммитит каждый участник и как они связаны друг с другом. Когда мы смотрим на визуализатор целиком, мы видим каждую фиксацию в каждой ветви каждого репозитория, принадлежащего сети. Очень круто!

Инструмент 5: Управление проектами

В то время как issues Github имеют возможности управления проектами с помощью Issues и Milestones, некоторые команды могут предпочесть другой инструмент из-за других функций или существующего рабочего процесса. В этом разделе мы увидим, как мы можем связать Github с двумя другими популярными инструментами управления проектами — Trello и Pivotal Tracker. С помощью сервисов Github мы можем автоматизировать задачу обновления с помощью коммитов, проблем и многих других действий. Эта автоматизация помогает не только экономить время, но и повышает точность обновлений для любой команды разработчиков программного обеспечения.

Github и Trello

Trello обеспечивает простой, визуальный способ управления задачами. Используя Agile Software Development, карточки Trello могут эмулировать простую виртуальную Kanban Board. В качестве примера мы автоматически создадим карточку Trello всякий раз, когда будет появляться новый пул реквест с помощью Github Service Hooks. Давайте пройдем через все шаги!

Откройте свой аккаунт в Trello, если у вас его еще нет, и создайте новую доску Trello.

Github и Pivotal Tracker

Pivotal Tracker — еще один легкий гибкий инструмент управления проектами, в котором планирование на основе истории позволяет команде легко взаимодействовать, мгновенно реагируя на различные изменения и прогресс проекта. Основываясь на текущем прогрессе команды, он также может создавать диаграммы для анализа скорости команды, итераций разработки, релизов и прочего. В этом кратком примере мы автоматически доставим историю, связав ее с коммитом на Github!

Создайте новый проект в Pivotal Tracker с новой Story которая должна быть сделана.

С примерами Trello и Pivotal Tracker ясно, что мы можем тесно связать наш список задач и обновления с нашими коммитами. Это огромная экономия времени при работе в команде, и это повышает точность при связывании задач с точными фиксациями. Хорошей новостью является то, что если вы уже используете другие инструменты управления проектами, такие как Asana, Basecamp и другие, вы также можете создать Service Hooks аналогичным образом. Если для вашего текущего инструмента управления проектами нет существующих сервисных хуков, вы даже можете их создать сами!

Инструмент 6: Непрерывная интеграция

Непрерывная интеграция (CI) является важной частью всех проектов разработки программного обеспечения, с которыми работают команды разработчиков. CI гарантирует, что, когда разработчик выкатывает свой код, автоматическая сборка (включая тесты) быстро обнаруживает ошибки интеграции. Это определенно уменьшает ошибки интеграции и делает быструю итерацию намного более эффективной. В этом примере мы увидим, как можно использовать Travis CI вместе с Github для CI для обнаружения ошибок, а также для рекомендаций слияния, когда проходят все тесты.

Настройка Travis CI

Мы будем использовать простой проект «hello world» для node.js вместе с grunt.js в качестве инструмента сборки для настройки Travis CI проекта. Вот файлы, находящиеся в проекте:

1. Файл hello.js — это проект nodejs. Здесь мы намеренно не будем оставлять точку с запятой, чтобы грант не смог собрать билд:
2. package.json определяет зависимости:
3. Инструмент сборки gruntjs имеет для простоты только одну задачу (линтинг) :
4. .travis.yml — это файл конфигурации Travis, который заставит Travis запускать наши тесты:
5. Затем войдите в Travis со своей учетной записью Github и включите привязку репозитория под вкладкой репозитория.

Travis CI и пул реквесты

Раньше, без какого-либо CI в процессе пул реквеста, этапы выполнялись примерно так: 1) создание запроса (2) слияние (3), тестируем все ли работает. Когда Travis CI подключится к пул реквесам, мы сможем инвертировать шаги 2 и 3, что еще больше ускорит принятие решений о том, следует ли сливать изменения, так как Travis даст нам статус билда для каждого пул реквеста. Давайте посмотрим, как это сделать.

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

Travis CI с Github чрезвычайно полезен для команд из-за автоматических сборок и немедленного уведомления. Это, безусловно, делает цикл исправления ошибок намного короче. Если вы используете Jenkins, еще один популярный инструмент CI, то вы тоже можете настроить сервисные хуки Github.

Инструмент 7: Обзор кода

С каждой фиксацией изменений Github позволяет использовать чистый интерфейс для общих комментариев или даже конкретных комментариев к отдельной строчке кода. Возможность делать комментарии или задавать вопросы по каждой отдельной строке кода очень полезна при проведении обзоров строка за строкой. Чтобы просмотреть встроенные комментарии, установите флажок в верхней части каждой фиксации.

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

Compare branches / tags / SHA1: используйте шаблон URL https://github.com/[username]/[repo-name]/compare/[starting-SHA1]. [ending-SHA1] . Вы можете сделать то же самое с веткой или тегами.

Инструмент 8 : документация

В этом разделе мы рассмотрим два метода создания документации:

1. Формальная документация: Github Wiki для создания документации для исходного кода
2. Неофициальная документация: Github Hubot документирует обсуждения между членами команды и автоматизирует поиск информации, взаимодействуя с бот-чатом!
3. Упоминания, ярлыки и эмози

Github Wiki

В каждом репозитории может быть создана Github Wiki, и это может оказаться очень удобно иметь в одном репозитории как исходный код, так и документацию для него. Чтобы создать Wiki, просто перейдите на вкладку Wiki в главном заголовке, и вы готовы к созданию страниц с информацией. Сама Wiki имеет собственное управление версиями, и данные могут быть клонированы на наш локальный компьютер для обновлений или даже автономного доступа.

Одна вещь, которую я нахожу очень полезной, — это интеграция Github Wiki в основной проект исходного кода, так что мне не нужно поддерживать два отдельных проекта git. Для этого я добавляю Wiki git repo как субмодуль из ветки master. Если вы используете Travis CI или любой другой CI, убедитесь, что инструмент сборки игнорирует подмодуль wiki. Для файла Travis CI .travis.yml добавьте следующее:

Затем добавьте wiki-подмодуль git в основной репозиторий кода:

Теперь Wiki будет выглядеть как подмодуль в основном проекте с исходным кодом.

Github Hubot

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

Hubot — это просто бот-чат, который может получать информацию или предоставлять уведомление при подключении к Github коммитам, issues или активности. В команде, которая стремится значительно сократить количество встреч или даже полностью устранить их, Hubot с интерфейсом чата среди членов команды помогает документировать каждую отдельную дискуссию. Это, безусловно, способствует гибкому графику работы, так как никто не должен присутствовать одновременно для обсуждения. Предупреждение: Hubot ужасно вызывает привыкание!

Итак давайте начнем с настройки Hubot, размещенным на Heroku, и ботом с интерфейсом чата Campfire! Для обоих и Heroku и Campfire есть бесплатные версии, с которым можно начать.

1. Мы воспользуемся версией Hubot от Github’s Campfire. Если вы хотите, вы можете выбрать адаптеры для других чатов, таких как Skype, IRC, Gtalk и т.д.
2. Откройте новую учетную запись Campfire только для Hubot, и эта учетная запись создаст новую комнату для чата, в которую все остальные будут приглашены позже.
3. Разверните Hubot на Heroku с помощью этой инструкции, приведенной на Hubot Wiki. Не волнуйтесь, если URL-адрес приложения heroku дает сообщение Can not GET / , поскольку по умолчанию еще нечего делать.
4. С учетной записью Hubot Campfire пригласите себя. Теперь войдите в свою учетную запись Campfire и выполните команду Hubot help . Эта команда предоставит вам все доступные команды для hubot.

Ознакомьтесь с другими скриптами Hubot, связанными с Github, или если вы хотите написать один, есть крутой учебник по этому поводу! Короче говоря, Hubot может значительно добавить веселья в документировании и уведомлении командных дискуссий о важных коммитах, проблемах и действиях, происходящих с нашими репозиториями на Github. Попробуйте его!

В качестве заключительной заметки о командной работе на Github, вот несколько советов по производительности:

1. Упоминания. В любой текстовой области мы можем указать другого пользователя github с @user , и пользователь получит уведомление о комментарии
2. Клавиши быстрого доступа — нажмите [shift] +? Для доступа к клавишам быстрого доступа Github на любой странице.
3. Emoji — Используйте список Emoji, Github textareas также поддерживает вставку этих значков. Попробуйте их и повеселитесь со своими товарищами по команде!

Использование Github не для разработки

Большинство думает использовать Github только для программных проектов. В конце концов, Github был создан специально для создания кода. Но есть некоторые классные репозитории Github, которые используются для проектов, не связанных с кодом, и они были одинаково великолепны для сотрудничества и обсуждения. Поскольку эти проекты также доступны с открытым исходным кодом, и каждый может внести свой вклад, быстро исправлять ошибки, легко сообщать об ошибках и эффективно сотрудничать с единомышленниками. Просто ради интереса, вот некоторые из них:

• Исправления для дома: отслеживание проблем в качестве инструмента мониторинга
• Книги:Маленькая книга по MongoDB, Основы Backbone
• Тексты песен: JSConfEU Тексты песен
• Найти друга:boyfriend_require
• Наставничество:Wiki
• Геномические данные: эпидемия Ash Dieback
• Блоги:CSS Wizardry

И интересно, что думает об этом команда Github?

«Мы кайфуем от использования GitHub»

Дополнительные ресурсы

• Социальная разработка на GitHub, исследовательская работа Университета Карнеги-Меллона
• Как Github использует Github для создания Github Зак Холман
• Секреты Git и Github Зак Холман
• Новые возможности в Github из блога Github
• Github Help: пул реквесты, форки репозитория
• Возможности Github для совместной работы
• Учебники Nettuts +: Git и Github
• Повелитель файлов: как Github приручил бесплатное программное обеспечение (и многое другое) Wired

Получайте больше удовольствия от совместной работы!

Таким образом, это был набор инструментов для совместной работы в Github. Большинство из них служат быстрыми аналитическими инструментами или даже автоматизацией, что помогает сэкономить время при работе с двумя или несколькими товарищами по команде. У вас есть больше советов Github для команд? Давайте поделимся ниже!

Источник