GitHub революционизировал мир с открытым исходным кодом, создав — IMHO — первый настоящий сайт социального кодирования. Никогда еще не было так легко внести свой вклад в проект, будь то просто обсуждение некоторых новых функций, сообщение об ошибке или, в лучшем случае, предоставление исправления ошибки или нового патча функции: запрос на извлечение (PR) . Тем не менее, я обнаружил, что многие разработчики пока не знают, как правильно создавать пиар. С этой статьей я надеюсь снизить этот входной барьер.
Прежде всего … учиться мерзавец
Git — наиболее широко используемая система контроля версий, особенно для проектов с открытым исходным кодом. Хотя вы можете использовать SVN и на GitHub, большинство проектов этого не делают. Просто потому, что Git гораздо больше подходит для случая использования распределенной работы, когда множество людей со всего мира клонируют, разветвляют и отправляют новые изменения в ваш репозиторий.
Тем не менее, вы должны знать основы Git и привыкнуть к тому, как он работает. Следовательно, вы должны знать о …
- получать, тянуть и толкать
- проверять, выписываться
- Старший мастер
- положение дел
- добавить и зафиксировать
- Отмена и отмена изменений
- ветвление и слияние
- перебазироваться
- пульты дистанционного управления
Я настоятельно рекомендую вам потратить время и изучить их, привыкнуть к ним, поиграть с местным демонстрационным репозиторием, где вы их опробуете (ничего не нарушая). Поверь мне, это избавит тебя от многих неприятностей и боли.
Эта статья может помочь вам начать: Git Explained: для начинающих
Создать учетную запись GitHub
Каждый серьезный разработчик нуждается в нем. Нет, правда! Перейдите на https://github.com , создайте его и свяжите с локальной оболочкой Git .
Хорошо, у меня есть что поспособствовать. Как мне поступить?
Поиск, кто-то еще уже предложил это или уже представил исправление. GitHub имеет простую, но отличную систему отслеживания ошибок.
Если это ошибка, создайте неудачный тест, попробуйте воспроизвести его локально. У хороших репозиториев уже есть хороший тестовый жгут. Затем отправьте свое исправление в виде пиара (включая тест, подтверждающий его отсутствие).
Если это новая функция предложения, я лично рекомендую связаться с автором (ами). Создайте проблему и предложите свое улучшение и новую функцию. Таким образом, вы получаете дополнительную информацию от автора или основных участников, и особенно вы избегаете идти в неправильном направлении. Отправка нового кода, который не сливается, потому что автор думал об этом по-другому, больно. Поверь мне! ,
Проверьте README.md и ссылки руководств
Обязательно проверьте файл README.md, который автоматически отображается в удобном для чтения виде в корне репозитория GitHub. Многие репозитории содержат инструкции по созданию репозитория и, в частности, рекомендации по внесению вклада, созданию и т. Д.
Таким образом, проверьте, есть ли
- рекомендации, требующие автоматических тестов для ваших новых изменений (это всегда хорошая идея, даже если они явно не требуются)
- рекомендации по фиксации сообщений (например: angular.js , atom.io ).
- правила кодирования
- …
Хорошо, готов начать!
Теперь пришло время собрать ваши трюки с джитами.
Шаг 1: Форк репо
Первый шаг — раскрутить репо, в который вы хотели бы внести свой вклад. GitHub сделает это за вас, просто найдите кнопку форка:
Это автоматически создаст копию хранилища под вашим собственным профилем пользователя GitHub.
Шаг 2: клонируйте свой раздвоенный репо
Теперь, когда у вас есть копия в вашем собственном профиле пользователя GitHub, у вас есть полный доступ для чтения / записи, и вы готовы применить свою реализацию изменений / функций к базе кода. Клонируйте свою вилку и начните кодировать.
На данный момент мы должны говорить о «потоке мерзавца». Этот термин включает в себя пару стратегий и передовых практик при работе с git. Вот пара полезных статей:
Если вы не хотите сейчас углубляться в это, по крайней мере, создайте ветку функций для своих изменений. Это настоятельно рекомендуется.
1
|
$ git checkout -b my- new -feature |
Теперь пришло время кодировать: внедрить ваши изменения.
Шаг 3: отшлифуйте свою историю, раздавите ненужные коммиты
Обычно, когда вы разрабатываете, вы можете иметь много коммитов, даже промежуточных, с сообщениями коммитов, которые, вероятно, только вы понимаете (если даже ..!).
Используйте git rebase
для полировки своей истории и включайте в нее только те, которые имеют отношение к делу и помогают автору более легко просматривать ваши изменения. Вот как это сделать: отполировать коммит вашей ветки .
Шаг 4: Вставьте его в свой разветвленный репозиторий
Теперь добавьте свою ветку в репо:
1
|
$ git push --set-upstream origin my- new -feature |
Шаг 5: Отправьте свой PR
После того, как вы добавили свою ветку в репо, просто откройте ее на GitHub. Должно появиться заметное сообщение, предлагающее вам создать PR.
Нажмите кнопку «Сравнить и получить запрос» и заполните данные.
Вау, ты сделал это! Ваш пиар сделан!
GitHub также имеет отличное руководство о том, как это сделать.
Кстати, вы можете просто добавить дополнительные коммиты в ветку функций вашего репо, и они автоматически появятся в вашем PR.
Ссылка / Синхронизация с оригинальным репо
Если ваш вклад был одноразовым исправлением, вы также можете удалить репозиторий после его объединения. Вместо этого, если вы намереваетесь внести дополнительные изменения, вы можете установить ссылку на исходный репозиторий, чтобы вы могли обновлять мастер своего собственного репо сейчас и потом.
Это делается путем добавления другого удаленного git, который указывает на исходный репозиторий GitHub.
1
|
$ git remote add upstream <the repo url> |
Если у вас есть это, вы можете синхронизировать его, выполнив
1
2
|
$ git checkout master $ git pull upstream master |
Или с git fetch
последующим git merge
(в зависимости от ваших настроек).
Вот статья на странице справки GitHub, которая также может помочь .
Вывод
Содействие имеет жизненно важное значение для поддержания экосистемы с открытым исходным кодом, и вы многому научитесь, делая это! В то же время, тем не менее, уважайте указания автора, будьте вежливы и, используйте Emojis, у них есть веская причина! (это может быть полезно)
Ссылка: | GitHub: будьте в соцсетях, помогайте, учитесь у нашего партнера по JCG Юри Струмпфлохнера в блоге Юри Струмпфлохнер в TechBlog . |