git (возможно) рабочий процесс разрешения конфликтов

Question

Я пытаюсь определить правильный git рабочий процесс. Есть несколько вопросов, которые смущают меня.

Вы работаете над веткой функций. После того, как вы сделали коммит, вы должны:

1) Использовать ветку объектов (необязательно, если вы работаете только над этим).

2) Объединить (или еще лучше) rebase) от мастера и разрешите конфликты (если есть).

3) Checkout master.

4) Извлечь из удаленного мастера.

5) Объединить ветвь функций (что должно привести к ускоренной перемотке вперед, если все в порядке).

6) Pu sh на расстоянии.

Как я уже упоминал, некоторые вещи не устраивают меня.

1. Шаг 2 предполагает, что мастер обновлен, не так ли?

2. Если это не так (шаг 4 фактически вызывает некоторые изменения в ) тогда что? Вы должны go вернуться к ветви функции и повторить шаг 2?

3. Я не уверен, откуда, но у меня есть представление, что все слияния (или, альтернативно, перебазирование) конфликтуют должно быть разрешено в ветви функций. Это верно? Если да, то почему?

4. Если 3 соответствует true, тогда я должен go освоить, потянуть (чтобы убедиться, что у меня последний мастер), go вернуться в ветвь объектов и выполнить объединить / перебазировать (то есть включить дополнительный шаг, чтобы убедиться, что мастер не позднее)?

РЕДАКТИРОВАТЬ1:

Например, сценарий:

Вы закончил работу над веткой функций и хочу поместить эти изменения в мастер. Вы сейчас находитесь в местной ветке. На локальном мастере нет никаких изменений, так как вы начали работу над веткой компонентов. Однако на удаленном мастере есть изменения. Как справиться с этим сценарием?

Answer 1

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

Затем этот вопрос должен быть рассмотрен другим участником проекта и объединен. Это не позволит вам слить PR, если возникнут конфликты. Который затем вам нужно решить на удаленном SCM или локально, в зависимости от поставщика SCM.

В случае, если вам придется перебазировать master локально. у вас есть два подхода, которые вы можете использовать.

1. Подход, который вы упомянули выше. Где вы переключаете ветви и выполняете ребазинг
2. Вы можете использовать git fetch функцию Git, чтобы вытянуть все ветви, присутствующие на пульте.

Использование второго подхода спасет вас от необходимости переключать ветви, но все равно иметь тот же эффект, что и в первом подходе.

При втором подходе вам нужно будет выполнить:

• git fetch, чтобы получить все изменения на пульте. Это обновит индекс origin хранилища.
• git rebase origin/master. Поскольку мы обновили индекс origin только командой fist, вам нужно будет сказать, что вы хотите выполнить ребаз из основной ветки origin; следовательно origin/master

Вот пример

Здесь develop ваш master

• Обновите индекс origin, чтобы он соответствовал удаленному

users:() ➜  (10/02 22:52) ~/dummy git:(feature/rebase-test) ✗ git fetch
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.
From github.com:praveenprem/dummy
   5029e07..429a6e6  develop    -> origin/develop

• Перебазируйте, используя обновленный индекс origin/develop вместо локального индекса develop.

users:() ➜  (10/02 22:52) ~/dummy git:(feature/rebase-test) ✗ git rebase origin/develop
First, rewinding head to replay your work on top of it...
Fast-forwarded feature/rebase-test to origin/develop.

users:() ➜  (10/02 22:53) ~/dummy git:(feature/rebase-test) ✗ git add .
users:() ➜  (10/02 22:53) ~/dummy git:(feature/rebase-test) ✗ git commit
[feature/rebase-test 9cb6ad0] Add test file 3
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 test-3.txt

users:() ➜  (10/02 22:54) ~/dummy git:(feature/rebase-test) git flow feature finish rebase-test
Switched to branch 'develop'
Your branch is behind 'origin/develop' by 1 commit, and can be fast-forwarded.
  (use "git pull" to update your local branch)
Merge made by the 'recursive' strategy.
 test-2.txt | 1 +
 test-3.txt | 0
 2 files changed, 1 insertion(+)
 create mode 100644 test-2.txt
 create mode 100644 test-3.txt
Deleted branch feature/rebase-test (was 9cb6ad0).

Summary of actions:
- The feature branch 'feature/rebase-test' was merged into 'develop'
- Feature branch 'feature/rebase-test' has been removed
- You are now on branch 'develop'

users:() ➜  (10/02 22:54) ~/dummy git:(develop) git pull
Already up to date.

users:() ➜  (10/02 22:55) ~/dummy git:(develop) git push
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 1.77 KiB | 452.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To github.com:praveenprem/dummy.git
   429a6e6..ae38b95  develop -> develop

Возможно, вы заметили, что когда я замерил брач, он сказал мне, что моя ветвь develop находится за 1 коммитом. Но когда слияние было выполнено git pull перед нажатием на слияние, изменений не было.

Надеюсь, это поможет в вашем случае использования.