Какой рабочий процесс внесет вклад в проект с открытым исходным кодом с помощью запросов на git pull? (например, через Github)

Ответ 1

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

Примечание. Шаги 1, 2 и 3 выполняются только один раз на одной машине для разработки, чтобы все настроить:

1) Убедитесь, что вы работаете локально над своим "форком" проекта, а не над клонированным репозиторием, указывающим на проект как на источник. Чтобы раскошелиться на проект Github, перейдите на https://github.com/entity/project, нажмите "Fork" и выберите подходящую учетную запись GitHub для форка, например. Ваш личный аккаунт на Github. Обратите внимание, что ваш разветвленный проект "origin" больше не будет исходным репозиторием проекта, а будет вашим собственным форком на Github. Будьте осторожны с конфиденциальностью, если вы разветвляете частный проект, так как вы, вероятно, не хотите, чтобы ваш форк был публичным.

2) Клонируйте свою собственную ветку проекта на свой компьютер для разработки и перейдите в этот каталог.

git clone [email protected]:yourgithubuser/project.git

3) Добавьте исходный репозиторий проекта в качестве исходного репозитория в свой разветвленный проект.

git remote add upstream [email protected]:entity/project.git

Оригинальный репо основного проекта теперь "восходящий", а не "происхождение"

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

4) Перед началом работы всегда проверяйте, что основная ветвь вашего разветвленного репо синхронизирована с главной веткой исходного репо проекта:

git checkout master
git fetch upstream
git merge upstream/master
git push origin master

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

git checkout -b myfixes

Это автоматически создает ветку и переключается на нее. Убедитесь, что ветвь уже не существует. Возможно, вы также захотите избавиться от старых веток исправлений, которые уже были объединены в документы (в противном случае в вашем проекте будет множество ненужных веток). Вы можете взглянуть на свои локальные ветки, выполнив git branch, и если в этом списке вы найдете ветку, которая уже была объединена с вышестоящим проектом, то вы можете сделать:

git branch -D myoldfixes
git push origin --delete myoldfixes

Важное примечание: если вы уже работали над веткой на другом компьютере и хотите продолжить эту работу на новом компьютере, вам нужно повторить шаги 2, 3 и 4 на новом компьютере и вместо этого на шаге 5 Для выполнения git checkout -b myfixes вы должны выполнить git checkout myfixes (удалить -b). В противном случае вы можете получить состояние "отстраненная голова", что не очень хорошо (вроде анонимной ветки)

6) Работайте над этой веткой (например, myfixes) и фиксируйте свои изменения:

git commit -a -m "My fixes"

(В качестве альтернативы вы можете создавать отдельные файлы и фиксировать их, не используя -a. Вы можете фиксировать столько раз, сколько хотите, но не оставляйте незафиксированные изменения в ветки)

7) Пока вы работали над исправлениями, исходный репозиторий проекта из вышестоящего проекта мог измениться (из-за того, что над ним работали другие участники). Итак, сначала вам придется перебазировать вашу текущую ветку (myfixes) из ветки назначения upstream. Другими словами, вам нужно воспроизвести свои исправления поверх этой последней работы из основной ветки репозитория upstream, чтобы убедиться, что ваши коммиты по-прежнему совместимы с последними коммитами в апстрим. Это приведет к ускоренному слиянию для запроса извлечения, что нам и нужно:

git checkout myfixes
git pull --rebase upstream master

Примечание: это может привести к конфликтам, но это нормально, их устранение является частью процесса (это происходит чаще всего в очень активных проектах)

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

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

git checkout myfixes
git push origin myfixes -f

9) Наконец, вы можете перейти на Github https://github.com/entity/project (оригинальный проект, а не ваш форк) и нажать "Запрос на извлечение". Убедитесь, что вы выбрали восходящее репо "master" в качестве ветки назначения, а ваше разветвленное репо "myfixes" в качестве исходной ветки (ветка будет автоматически удалена для вас после принятия запроса на получение)

Наслаждайтесь!

Ответ 2

6a) Тема фиксации и формат сообщения фиксации также важны.

Тема обсуждения

Тема фиксации должна охватывать только одно логическое изменение. Например, если вы должны описать изменения кому-либо (например, в сообщении фиксации, см. Ниже), вы не сможете использовать слово "и" для описания темы, например. не "Исправить ошибку 123 и обновить конфигурацию по умолчанию". Это должны быть две отдельные фиксации.

Если у вас есть куча отдельных проблем, адресованных, но не учтенных в рабочем дереве, отличным инструментом является интерактивный add. Помните ли вы эту партию команд, а затем следуйте указаниям:

git add -i
5<CR>
*<CR>

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

Затем, как обычно:

git ci

Сообщение о фиксации

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

Мое любимое руководство по написанию хороших сообщений о совершении - это страница вики Erlang/OTP в сообщениях хорошего фиксации, и к этому я добавлю, что вы не ошибетесь в следующем формате:

Short (<50 chars) present-tense summary of changes

Previously, <a couple sentences clearly describing the previous behavior
and the resulting customer issue>. 

This commit <a sentence or two clearly describing the code change, and the
resulting expected behavior>.