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

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

Github и совместная работа программного обеспечения

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

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

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

Добавление членов команды — организация и соавторы
Pull Requests — отправка и слияние
Отслеживание ошибок — Github Issues
Аналитика — Графики и Сеть
Управление проектами — Trello & Pivotal Tracker
Непрерывная интеграция — Travis CI
Code Review — комментирование строк и URL-запросы
Документирование — Wiki & Hubot

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

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

Скачать видео

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

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

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

организации

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

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

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

соавторы

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

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

Инструмент 2: Запросы на извлечение

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

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

Инициирование запроса на извлечение

В Github есть две модели pull-запроса :

Модель Fork & Pull — используется в общедоступном репозитории, для которого у нас нет прав доступа
Модель общего репозитория — используется в частном репозитории, для которого у нас есть push-доступ. В этом случае вилка не требуется.

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

Укажите репозиторий Github, в который вы хотите внести свой вклад, и нажмите кнопку «Вилка», чтобы создать клон репозитория в своей учетной записи Github:
Это создаст точную копию хранилища в вашей учетной записи
Выберите URL-адрес SSH, чтобы он запрашивал вашу ключевую фразу SSH вместо имени пользователя и пароля каждый раз, когда вы git push или git pull . Далее мы клонируем этот репозиторий на наш локальный компьютер:

1

2

$ git clone [ssh-url] [folder-name]

$ cd [folder-name]
Обычно мы создаем новую ветку git для каждой новой функции. Это хорошая практика, потому что в будущем, если мы продолжим обновлять ветку после некоторых обсуждений, запрос на получение обновлений будет автоматически обновлен . Давайте создадим новую ветку, чтобы внести очень простое изменение в файл readme.md :

1

$ git checkout -b [new-feature]
После внесения соответствующих дополнений для создания новых функций, мы просто передадим новые изменения и извлечем их в ветку git master:

1

2

3

$ git add .

$ git commit -m «information added in readme»

$ git checkout master

На этом этапе мы отправим ветку в удаленный репозиторий. Для этого мы сначала проверим имя ветки с новой функцией, а также псевдонимы удаленного репозитория git. Затем мы отправим изменения, используя git push [git-remote-alias] [branch-name] :

$ git branch
* master
readme
$ git remote -v
origin [email protected]:[forked-repo-owner-username]/[repo-name].git (fetch)
origin [email protected]:[forked-repo-owner-username]/[repo-name].git (push)
$ git push origin readme

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

Слияние запроса на извлечение

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

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

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

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

Запросы на извлечение — это отличный способ внести свой вклад в хранилище, раздвоив его.

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

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

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

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

Назначение: Каждая проблема может быть назначена ответственному лицу, чтобы решить проблему. Это еще одна полезная функция, чтобы увидеть, над чем мы должны работать.

Автоматическое закрытие: фиксация сообщений с помощью Fixes/Fixed or Close/Closes/Closed #[issue-number] автоматически закроет проблему.

1

2

3

$ git add .

$ git commit -m «corrected url. fixes #2»

$ git push origin master
Упоминания: Любой также может оставить заметку, просто указав #[issue-number] в своих сообщениях. Поскольку номера проблем связаны между собой, это позволяет легко упоминать связанные проблемы во время обсуждения.

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

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

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

диаграммы

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

Участники: кто был участниками? А сколько строк кода они добавили или удалили?
Активность коммитов: в какие недели происходили коммиты в прошлом году?
Частота кода: Сколько строк кода было зафиксировано в течение всего жизненного цикла проекта?
Punchcard: в какое время дня обычно происходят коммиты?

сеть

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

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

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

Гитхуб и Трелло

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

Откройте счет в Trello, если у вас его еще нет, и создайте новую доску Trello.
Перейдите в репозиторий Github> Настройки> Сервисные хуки> Trello
Получите TOKEN разделе «Примечания по установке № 1» с гиперссылкой для аутентификации.
В разделе «Замечания по установке №2» используйте URL-адрес, указанный для создания структуры в формате json, которая дает нам list id для каждой карты Trello. BOARDID является частью URL-адреса, когда мы посещаем BOARDID по адресу https://trello.com/board/[BOARD-NAME]/[BOARDID] . TOKEN можно создать с помощью гиперссылки, приведенной в разделе «Замечания по установке № 1».
Вернувшись в сервисные хуки Github, поместите в list id и token . Установите флажок Active, Test Hook, и мы готовы автоматически получать обновления при каждом запросе Pull.
В следующий раз, когда появится запрос на вытягивание, на карточке «Запрос на вытягивание» Trello автоматически появится новый предмет!

Github и Pivotal Tracker

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

Создайте новый проект в Pivotal Tracker с новой историей, которую необходимо доставить.
Перейдите в Профиль> Токен API (справа внизу). Скопируйте указанный токен API.
Вернитесь в репозиторий Github> Настройки> Сервисные хуки> Pivotal Tracker. Вставьте токен, отметьте «Активный» и нажмите «Обновить настройки». Мы все настроены на автоматическую доставку историй Pivotal Tracker с помощью Github Commits!
Наконец, мы зафиксируем наши изменения и добавим идентификатор трекера в сообщение фиксации в формате git commit -m "message [delivers #tracker_id]"

1

2

3

$ git add .

$ git commit -m «Github and Pivotal Tracker hooks implemented [delivers #43903595]»

$ git push
Теперь, когда мы вернемся к Pivotal Tracker, мы увидим, что история была автоматически доставлена со ссылками на точный коммит Github, который показывает изменения файла!

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

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

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

Настройка Travis CI

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

Файл hello.js является проектом узла. Здесь мы намеренно пропустим точку с запятой, чтобы она не передавала инструмент построения grunt для линтинга:

var http = require(‘http’);
http.createServer(function (req, res) {
res.writeHead(200, {‘Content-Type’: ‘text/plain’});
  res.end(‘Hello World in Node!\n’) // without semicolon, this will not pass linting
}).listen(1337, ‘127.0.0.1’);
console.log(‘Server running at http://127.0.0.1:1337/’);

package.json обозначает зависимости:

{
  «name»: «hello-team»,
  «description»: «A demo for github and travis ci for team collaboration»,
  «author»: «name <[email protected]>»,
  «version»: «0.0.1»,
  «devDependencies»: {
    «grunt»: «~0.3.17»
  },
  «scripts»: {
    «test»: «grunt travis —verbose»
  }
}

У gruntjs сборки gruntjs есть только одна задача (linting) только для простоты:

module.exports = function(grunt) {
    grunt.initConfig({
     lint: {
      files: [‘hello.js’]
    }
  });
  grunt.registerTask(‘default’, ‘lint’);
  grunt.registerTask(‘travis’, ‘lint’);
};

.travis.yml — это файл конфигурации Travis, который заставит Travis выполнять наши тесты:

1

2

3

language: node_js

node_js:

— 0.8
Затем войдите в Travis со своей учетной записью Github и включите хук репозитория на вкладке репозитория.
Если предыдущий шаг не запускает сборку, то нам придется вручную настроить сервисную ловушку. Чтобы настроить его вручную, скопируйте токен на вкладке профиля.
Вернитесь в репозиторий Github, чтобы настроить сервисные хуки Github Travis с помощью токена.
В первый раз нам нужно вручную git push для запуска первой сборки Travis, и если все в порядке, просто посетите http://travis-ci.org/[username]/[repo-name] чтобы увидеть сборку статус как проходящий!

Трэвис CI с запросами на подачу

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

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

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

Инструмент 7: Проверка кода

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

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

Сравните ветки / теги / SHA1 : используйте шаблон URL https://github.com/[username]/[repo-name]/compare/[starting-SHA1]...[ending-SHA1] . Вы можете сделать то же самое с веткой или тегами.
Сравните без пробелов : добавьте ?w=1 к URL для сравнения
Diff : добавьте .diff к URL-адресам сравнения, чтобы получить информацию о git diff в виде простого текста. Это может быть полезно для сценариев.
Патч : добавьте .patch к URL-адресам сравнения, чтобы получить информацию о git diff отформатированную для отправки исправлений по электронной почте .
Связывание строк : когда мы #line номер строки в любом файле, Github добавляет #line в конце URL-адреса и делает цвет фона всей строки желтым. Это удобно для указания точной линии. Он также принимает диапазоны строк, добавляя #start-end . Вот примеры связывания линий и связывания диапазона строк .

Инструмент 8: Документирование

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

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

Github Wiki

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

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

git:
  submodules: false

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

$ git submodule add [email protected]:[username]/[repo-name].wiki.git
Cloning into ‘hello-team.wiki’…
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 6 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (6/6), done.
$ git add .
$ git commit -m «added wiki as submodule»
$ git push origin master

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

Github Hubot

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

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

Теперь начнем с настройки Hubot на Heroku и в качестве бота с интерфейсом чата Campfire ! Для Heroku и Campfire есть бесплатные версии для начала.

Мы будем использовать Github’s Campfire версию Hubot . Если вы хотите, вы можете проверить адаптеры для других чатов, таких как Skype, IRC, Gtalk и т. Д.
Откройте новую учетную запись Campfire только для Hubot, и эта учетная запись создаст новую чат-комнату, в которую все остальные будут приглашены позже.
Разверните Hubot в Heroku с помощью инструкций, приведенных в Hubot Wiki. Не беспокойтесь, если в URL-адресе приложения heroku выдается Cannot GET / поскольку по умолчанию нечего получить .
Пригласите себя из учетной записи Hubot Campfire. Теперь войдите в свою учетную запись Campfire и выполните Hubot help . Это даст вам все доступные команды для hubot.
Попробуйте, например, hubot ship it или hubot map me CERN .
Далее мы добавим скрипт Hubot. Есть много доступных с иллюстрациями команд .
Например, мы добавим скрипт github- commits, чтобы каждый раз, когда происходит коммит, Hubot уведомлял нас в чате. Поместите файл github-commits.coffee в папку scripts .
Обновите файл package.json с соответствующими зависимостями, как указано в начале каждого файла сценария hubot в комментариях.
Разверните изменения в Heroku еще раз с помощью git push heroku master .
Перейдите к хранилищу в Github, уведомление о коммите которого будет отображаться в чате. Добавьте в веб-хук в настройках репо. В случае упомянутого сценария «github-commit» веб-крючок будет [HUBOT_URL]:[PORT]/hubot/gh-commits?room=[ROOM_ID]
В следующий раз, когда в репозитории появится коммит, Hubot будет общаться и говорить об этом!

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

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

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

Непрограммная совместная работа на Github

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

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

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

«Мы копаем забавное использование GitHub, как это»

Больше ресурсов

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

Больше удовольствия в сотрудничестве!

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