Порядок git операций

Question

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

1. Клонировать репозиторий из GitHub (на данный момент в моем репозитории GitHub есть только главная ветка).
2. Создать новую ветку локально.
3. Внесите изменения в новую ветку и зафиксируйте.

4. Pu sh новая ветка изменится на GitHub, используя git pu sh.

   Вопрос: Теперь создается новая ветка на GitHub? Требуются ли дополнительные аргументы git push?

5. Создать запрос на перенос на GitHub.

6. Слить мою новую ветку с основной веткой на GitHub.

   Вопрос: Могу ли я теперь объединить новую ветвь с основной веткой локально?

7. Удалить локальную новую ветку.

Answer 1

Имейте в виду, запросы на вытягивание не являются функцией git. Они прямо противоречат природе, духу и техническим основам git. Это функция, предоставляемая github для обеспечения контролируемого сотрудничества и взаимодействия. Не используйте их без необходимости, потому что ваш код должен быть рассмотрен кем-то еще вместе с полученным диалогом.

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

1. Клонировать репозиторий из GitHub [один раз].

2. Создать новую ветку локально.

3. Вносите изменения и добавляйте и фиксируйте.

4. Pu sh ветвь на GitHub.

5. Создайте запрос на перенос на GitHub с просьбой объединить эту ветку с master. Попросите отзыв.

   1. Обсуждение кода.

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

6. Когда запрос на вытягивание будет одобрен, объедините ветвь с master на GitHub. Когда GitHub предложит вам удалить ветку, сделайте это.

7. Вернитесь на свой компьютер, переключитесь на master и потяните.

8. Удалить ветку.

9. Начать заново с 2.

Если есть без соавторов или проверки кода тогда ваши шаги будут совершенно неправильными; в этом случае все слияние будет происходить локально, и вы вообще никогда не посетите github.

Answer 2

Вопрос: Теперь создается новая ветка на GitHub? Требуются ли git pu sh какие-либо дополнительные аргументы?

Когда вы sh ветвь, она попытается сделать sh изменения удаленного по умолчанию (в вашем случае GitHub), независимо от того, нужно добавить любые аргументы зависит. Вы можете явно указать pu sh указанной c ветке или pu sh новой ветке с указанным c именем. Когда вы опускаете все, git попросит вас установить «восходящий поток», имя ветки на пульте дистанционного управления:

>git checkout -B new
Switched to a new branch 'new'

>git push
fatal: The current branch new has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin new

Таким образом, вам нужно установить восходящий поток только один раз, и с этого момента вы можете использовать git push без аргументов. Вместо этого вы также можете явно указать pu sh в ветке:

>git push origin new
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
remote:
remote: Create a pull request for 'new' on GitHub by visiting:
remote:      https://github.com/jessehouwing/test/pull/new/new
remote:
To https://github.com/jessehouwing/test.git
 * [new branch]      new -> new

Но это не приведет к установке восходящей ветки и потребует от вас указывать, какая удаленная ветвь должна указывать на pu sh каждый раз, когда вы выполнить git push. Следовательно, в большинстве случаев имеет смысл установить восходящий поток.

Вопрос: Могу ли я теперь объединить новую ветвь с основной веткой локально?

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

>git fetch origin master
From https://github.com/jessehouwing/test
 * branch            master     -> FETCH_HEAD

Теперь А затем создайте новую ветку для следующего набора изменений

git checkout origin/master -B second-new-branch --no-track

Таким образом, у вас никогда не будет локальной копии master, и вы всегда будете работать из ветки создан для вашей конкретной c цели. Это также поможет вам не вносить изменения в неправильную ветку. Я добавил --no-track, поэтому ветка не будет связана с origin/master при нажатии, что позволяет вам сделать новый запрос на перенос.

Таким образом, вы никогда не разрешите конфликты слияния в главном сервере локально и всегда сможете создавать новые ветки из последнего состояния удаленного репо.