Что после слияния запросов на вытягивание?

Question

Предположим, я работаю над функциональной веткой на моем локальном компьютере. Теперь, после определенных коммитов, я делаю пул-реквест.

Теперь предположим, что мой пул-реквест был принят и функциональная ветка слита с веткой разработки удаленно. Теперь, что происходит с моей локальной веткой функций. Будет ли он также автоматически объединен в моей локальной системе, или мне придется объединить его с разработкой самостоятельно? 1005 *

Answer 1

Позвольте мне объяснить это на небольшом примере. Рассмотрим начальную настройку некоторого удаленного репозитория.

# Your initial remote repository setup
hash1---hash2---hash3 <- origin/develop , origin/HEAD


# You checked things into your local then git copies would be:
## Your remote repository's snapshot would look like:
hash1---hash2---hash3 <- origin/develop , origin/HEAD

## Your local repository's snapshot would look like:
hash1---hash2---hash3 <- develop , HEAD


# You create separate brach 'feature' out of it and add two commits to it:
## Your remote repository's snapshot would look like:
hash1---hash2---hash3 <- origin/develop , origin/HEAD

## Your local repository's snapshot would look like:
hash1---hash2---hash3 <- develop
                  \
                 hash4---hash5 <- feature, HEAD


# You checked in remotely and raised pull-reqeust:
## Your remote repository's snapshot would look like:
hash1---hash2---hash3 <- origin/develop, origin/HEAD
                  \
                 hash4---hash5 <- origin/feature 

## Your local repository's snapshot would look like:
hash1---hash2---hash3 <- develop
                  \
                 hash4---hash5 <- feature, HEAD

Вы слили ветку feature с develop удаленно, здесь все может go неприятно. Возможны два исхода:

1. Ускоренное слияние <- самый простой. </li>
2. 3-стороннее слияние <- сложное, в вашем случае не произойдет. Поэтому на время пропустим его объяснение. </li>

Если происходит слияние Fast-forward. Это случается, когда у вас нет конфликтов слияния. Мол, в этом случае вы никогда не столкнетесь, так как активен только один разработчик и только одна ветка проверяется.

# Fast-forward merge happens
## Your remote repository's snapshot would look like:
hash1---hash2---hash3 
                  \
                 hash4---hash5 <- origin/develop, origin/HEAD, origin/feature 

## Your local repository's snapshot would look like:
hash1---hash2---hash3 <- develop
                  \
                 hash4---hash5 <- feature, HEAD

Теперь предположим, что вы продолжили работу над своей локальной feature веткой и добавили еще две фиксации, затем:

# Added two more commits on local branch:
## Your remote repository's snapshot would look like:
hash1---hash2---hash3 
                  \
                 hash4---hash5 <- origin/develop, origin/HEAD, origin/feature 

## Your local repository's snapshot would look like:
hash1---hash2---hash3 <- develop
                  \
                 hash4---hash5---hash6---hash7 <- feature, HEAD

# You checked local 'feature' branch's code in and raised a pull-request.
## Your remote repository's snapshot would look like:
hash1---hash2---hash3 
                  \
                 hash4---hash5 <- origin/develop, origin/HEAD
                            \
                            hash6---hash7 <- origin/feature 

## Your local repository's snapshot would look like:
hash1---hash2---hash3 <- develop
                  \
                 hash4---hash5---hash6---hash7 <- feature, HEAD


# You merged local 'feature' branch's into develop branch.
## Your remote repository's snapshot would look like:
hash1---hash2---hash3 
                  \
                 hash4---hash5
                            \
                            hash6---hash7 <- origin/develop, origin/HEAD, origin/feature

## Your local repository's snapshot would look like:
hash1---hash2---hash3 <- develop
                  \
                 hash4---hash5---hash6---hash7 <- feature, HEAD

Теперь, допустим, вы объединили свои удаленный origin/develop переходит в локальную develop ветку, затем:

## Your remote repository's snapshot would look like:
hash1---hash2---hash3 
                  \
                 hash4---hash5
                            \
                            hash6---hash7 <- origin/develop, origin/HEAD, origin/feature

## Your local repository's snapshot would look like:
hash1---hash2---hash3 
                  \
                 hash4---hash5---hash6---hash7 <- <- develop, feature, HEAD    

Если вы внимательно посмотрите на макет выше, то оба они одинаковы. Хотя есть небольшая разница в их представлении, но именно это я и сделал, чтобы объяснить вам концепции слияния.

В заключение, это полностью зависит от вас, хотите ли вы по-прежнему работать над этой веткой, или вы можете просто отбросить ее, потому что в конечной ветке есть только определенный указатель на некоторый фиксированный ha sh на вашем git график.

Answer 2

Вы всегда вносите изменения в свою ветку функций, пока ваша функция не будет полностью разработана. После того, как функция полностью разработана, вы go выполняете запрос на слияние, а затем, если ваши изменения выглядят нормально. Они объединены в ветку разработки. При создании запроса на вытягивание вы можете выбрать в пользовательском интерфейсе «Удалить исходную ветвь после принятия запроса на извлечение», иначе вам придется удалить ветку вручную. локальная система develop ветка не обновляется. Итак, вам нужно будет запустить git pull, чтобы обновить ветку разработки. Это не автомат c.