Статьи

Как сотрудничать на GitHub

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

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


Не бойся начинать с малого

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

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


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

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

Как только вы станете частью культурной экосистемы проекта, как вы на самом деле вносите код ?


Поначалу процесс создания кода может показаться сложным.

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

  1. Поместите целевой репо в свою учетную запись.
  2. Клонируйте репо на свой локальный компьютер.
  3. Проверьте новую “ветку темы” и внесите изменения.
  4. Раздвинь ветку своей темы на свою вилку.
  5. Используйте средство просмотра различий на GitHub, чтобы создать пул-запрос через обсуждение.
  6. Сделайте любые запрошенные изменения.
  7. Затем этот запрос объединяется (обычно в основную ветвь), а ветвь темы удаляется из восходящего (целевого) репо.

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

Форк репо на GitHub.com

github_header
разветвление

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

1
git clone git@github.com:jcutrell/jquery.git
clone_url

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

1
2
cd jquery
git remote add upstream git@github.com:jquery/jquery.git

Теперь это позволит вам локально извлекать изменения из источника и объединять их следующим образом:

1
2
git fetch upstream
git merge upstream/master

Однако, прежде чем вносить свои собственные изменения, ознакомьтесь с веткой темы:

1
git checkout -b enhancement_345

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

1
git commit -am “adding a smileyface to the documentation.”

Далее вы добавите эту ветку к своей ветке проекта.

1
git push origin enhancment_345

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

compare_pull_request
Создание запроса на получение с помощью кнопки Сравнить и запрос на получение .
switch_branches
Создание запроса извлечения через выпадающее меню филиала.

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

Обратите внимание, что невероятно важно, чтобы вы проявили полное уважение к администраторам проекта; в конце концов, вы всегда можете использовать свою раздвоенную версию кода, и если они решили не вносить изменения, это потому, что у них есть такая возможность. Помните, что, согласно рассказу сотрудника Github Зака Холмана «Как GitHub использует GitHub для создания GitHub» , запросы на получение запросов – это разговоры. Вот как они должны относиться; вместо того, чтобы ожидать принятия вашего коммита, вам следует ожидать только того, что он откроет разговор о написанном вами коде.


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

1
git commit -am “Adding a header; fixes #3”

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


Часто крупные проекты с открытым исходным кодом получают выгоду от множества различных видов совместной работы.

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

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


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


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