Git workflow для разработки на форке

Question

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

1. fork upstream
2. работа над моим мастером
3. выдача запроса на тягу к моему мастеру ... проходит время ...
4. объединение восходящего потока / мастера с моим мастером
5. обратно в 2.

или

1. fork upstream
2. ветвь моего мастера в dev
3. работа над dev
4. выдача pull-запроса противdev ... время проходит ...
5. объединить upstream / master с моим master
6. reranch master или слить master с dev
7. обратно в 2

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

Answer 1

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

1. Я создаю ветку из master апстрима. Если я работаю над определенной функцией или ошибкой, я назову ветку, чтобы отразить это; в противном случае я назову это dev или еще много чего.
2. Работайте на dev, перебирая из master восходящего потока по мере необходимости.
3. Нажмите dev (или как я назвал ветвь) и выполните мой запрос на извлечение.
4. Продолжайте перетягивать изменения вверх по течению в мою master ветку.

То есть, я не делаю любую работу на master. Это создает простой, чистый запрос ветвления / вытягивания для сопровождающего в верхнем течении.

Answer 2

Есть также очень важный git rebase, который вытягивает / объединяет любые внешние изменения в ветке, к которой вы перебазируете. Именно так я и делал изменения в Qt в прошлом (он размещен на gitorious, у которого есть отличная функция запроса слияния). Шаги 1 и 2, вероятно, будут просто номером два для вас.

1. создать собственный клон "master" в отдельном проекте
2. работа над веткой, разрабатываемой в настоящее время, или создание новой рабочей ветки.
3. перед выполнением запроса на получение, выполните git rebase origin/master или что-то подобное, чтобы убедиться, что ваш коммит корректно применяется к текущему мастеру. Это имеет приятный побочный эффект, что ваши изменения появляются "на вершине стека", то есть после всех других коммитов.

Надеюсь, это поможет вам в том, что вы пытаетесь сделать.