Слияние ветки разработки с мастером

У меня есть две ветви, а именно masterи developmentв репозитории GitHub. Я делаю все свои разработки в ветке разработки, как показано на рисунке.

git branch development
git add *
git commit -m "My initial commit message"
git push -u origin development

Теперь я хочу объединить все изменения на developmentветке в master. Мой текущий подход:

git checkout master 
git merge development
git push -u origin master 

Пожалуйста, дайте мне знать, если процедура, которой я следую, является правильной.

Как правило, мне нравится объединяться masterс developmentпервым, чтобы в случае возникновения каких-либо конфликтов я мог разрешить проблему в самой developmentветке, и мои данные masterостаются чистыми.

(on branch development)$ git merge master
(resolve any merge conflicts if there are any)
git checkout master
git merge development (there won't be any conflicts now)

Между masterэтими двумя подходами нет большой разницы, но я иногда замечал, что я не хочу объединять ветку еще, после объединения, или что еще предстоит проделать большую работу, прежде чем они могут быть объединены так что я склонен оставлять masterнетронутым до финального материала.

РЕДАКТИРОВАТЬ: Из комментариев

Если вы хотите отслеживать, кто и когда произвел слияние, вы можете использовать --no-ffфлаг для слияния, чтобы сделать это. Обычно это полезно только при слиянии developmentс master(последний шаг), потому что вам может потребоваться слиться masterс development(первым шагом) несколько раз в вашем рабочем процессе, и создание узла фиксации для них может быть не очень полезным.

git merge --no-ff development

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

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

git fetch origin master

git merge master

git push origin development:master

Первая строка гарантирует, что он имеет какие-либо восходящие коммиты, которые были сделаны мастеру с момента последнего обновления его локального репозитория.

Второй тянет эти изменения (если они есть) из мастера в разработку

Третий подталкивает ветку разработки (теперь полностью объединенную с master) до origin / master.

Я могу немного ошибиться в его базовом рабочем процессе, но в этом его основная суть.

Объяснение снизу для тех, кто пришел сюда без каких-либо знаний о ветвях.

Основная логика разработки основной ветки такова: вы работаете только с другими ветками и используете master только для объединения других ветвей.

Вы начинаете создавать новую ветку следующим образом:

1) Клонируйте репозиторий в вашем локальном каталоге (или создайте новый репозиторий):

$ cd /var/www
$ git clone git@bitbucket.org:user_name/repository_name.git

2) Создать новую ветку. Он будет содержать последние файлы вашего основного филиала хранилища

$ git branch new_branch

3) Измените вашу текущую ветку git на new_branch

$ git checkout new_branch

4) Заниматься кодированием, фиксирует, как обычно…

$ git add .
$ git commit -m “Initial commit”
$ git push (pushes commits only to “new_branch”)

5) Когда работа в этой ветке завершится, объедините с веткой «master»:

$ git merge master
$ git checkout master (goes to master branch)
$ git merge development (merges files in localhost. Master shouldn’t have any  commits ahead, otherwise there will be a need for pull and merging code by hands!)
$ git push (pushes all “new_branch” commits to both branches - “master” and “new_branch”)

Обновление: я настоятельно рекомендую использовать GitKraken для этого, чтобы видеть визуальное дерево изменений и лучше видеть всю логику и коммиты.

Было бы здорово, если бы вы могли использовать рабочий процесс Git Flow . Он может легко объединить развивающуюся ветку в мастерскую

То, что вы хотите сделать, это просто следовать инструкции git-flow, упомянутой здесь:

ШАГИ:

• настроить проект git-flow
• создавать филиалы и объединять все для развития
• запустить команду git flow release start <version_number>
• затем предоставить содержательное сообщение для релиза
• запустить команду git flow release finish <version_number>
• он объединит все в master и изменит ветку на master .
• выполните команду, git pushчтобы опубликовать изменения на удаленном мастере .

Для получения дополнительной информации посетите страницу - http://danielkummer.github.io/git-flow-cheatsheet/

1. //pull the latest changes of current development branch if any        
git pull (current development branch)

2. //switch to master branch
git checkout master 

3. //pull all the changes if any
git pull

4. //Now merge development into master    
git merge development

5. //push the master branch
git push origin master

Да, это правильно, но похоже, что это очень простой рабочий процесс, в котором вы просто буферизуете изменения, прежде чем они будут готовы к интеграции. Вы должны изучить более продвинутые рабочие процессы, которые поддерживает git. Вам может понравиться подход ветвления темы , который позволяет вам работать над несколькими функциями параллельно, или подход градации, который немного расширяет ваш текущий рабочий процесс.

Если вы используете Mac или Ubuntu, перейдите в рабочую папку ветки. В терминале

Предположим, что Харисдев является отчеством.

git checkout master

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

git merge harisdev 

git push origin master

Последняя команда для удаления ветки.

$ git branch -d harisdev

Шаг 1

Создайте и переключитесь на новую ветку «dev», где ваши локальные git-файлы синхронизируются с удаленной, но ветка «dev» еще не существует.

git branch dev # create
git checkout dev # switch
# No need to git add or git commit, the current
# branch's files will be cloned to the new branch by-default.
git push --set-upstream origin dev # push the "dev" branch to the remote.

Шаг 2

Внесите изменения в ветку «dev» (текущую, если вы выполните шаг 1), зафиксируйте и отправьте их в удаленную ветку «dev».

git add .
git commit -S -m "my first commit to the dev branch" # remove the -S if you're not "secure", secure = when you already setup crypto private and public keys (i.e "verified" green sign in github)
git push -u origin dev # push the changes to the remote, -u origin dev is optional but good to use.

Шаг 3

Объедините свою ветку «dev» в «master».

git checkout dev # switch to "dev" branch if you're not already.
git merge master # optionally, this command is being used to resolve any conflicts if you pushed any changes to your "master" but "dev" doesn't have that commit.
git checkout master # switch to "master", which is the branch you want to be merged.
git merge --no-ff dev # merge the "dev" branch into the "master" one.

Вот как я обычно это делаю. Во-первых, убедитесь, что вы готовы объединить свои изменения в мастер.

1. Проверьте, соответствует ли разработка последним изменениям на удаленном сервере с git fetch
2. Как только выборка завершена git checkout master.
3. Убедитесь, что главная ветвь имеет последние обновления, выполнив git pull
4. Как только подготовка завершена, вы можете начать слияние с git merge development
5. Нажмите изменения, git push -u origin masterи все готово.

Вы можете узнать больше о git merging в статье.

1) В отделе разработки проверьте статус git с помощью следующей команды:

git status

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

git add *

git commit -m "My initial commit message"

git push origin Development

2) В ветке разработки выполните следующие две команды:

git branch -f master HEAD

git push -f origin master

Это подтолкнет ваш код ветки разработки в основную ветку.

Основано на @Sailesh и @DavidCulp:

(on branch development)
$ git fetch origin master
$ git merge FETCH_HEAD
(resolve any merge conflicts if there are any)
$ git checkout master
$ git merge --no-ff development (there won't be any conflicts now)

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

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

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

Затем вы объединяете ветку разработки с локальным мастером. Флаг no-ff создаст узел фиксации в master для отслеживания всего слияния.

После этого вы можете зафиксировать и нажать свое слияние.

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

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

РЕДАКТИРОВАТЬ: мой оригинальный ответ предложил, git merge masterкоторый ничего не делал, это лучше сделать git merge FETCH_HEADпосле получения оригинала / мастера

Как только вы «оформили» ветку разработки, вы ...

 git add .
 git commit -m "first commit"
 git push origin dev
 git merge master

 git checkout master 
 git merge dev
 git push origin master 

Если вы используете Gerrit, следующие команды работают отлично.

git checkout master
git merge --no-ff development

Вы можете сохранить с сообщением фиксации по умолчанию. Убедитесь, что идентификатор изменения сгенерирован. Вы можете использовать следующую команду, чтобы убедиться.

git commit --amend

Затем нажмите следующую команду.

git push origin HEAD:refs/for/refs/heads/master

Вы можете столкнуться с сообщением об ошибке, как показано ниже.

! [remote rejected] HEAD -> refs/for/refs/heads/master (you are not allowed to upload merges)

Чтобы решить эту проблему, администратор проекта gerrit должен создать еще одну ссылку в gerrit с именем 'refs / for / refs / head / master' или 'refs / for / refs /head / *' (которая будет охватывать все ветви в будущем). Затем предоставьте разрешение «Push Merge Commit» на эту ссылку и разрешение «Отправить», если требуется отправить GCR.

Теперь попробуйте вышеупомянутую команду push, и она должна работать.

Кредиты:

https://github.com/ReviewAssistant/reviewassistant/wiki/Merging-branches-in-Gerrit

https://stackoverflow.com/a/21199818/3877642

Я думаю, что самое простое решение было бы

git checkout master
git remote update
git merge origin/Develop -X theirs
git commit -m commit -m "New release"
git push --recurse-submodules=check --progress "origin" refs/heads/Master

Это также сохраняет историю всех используемых веток

1. //push the latest changes of current development branch if any        
git push (current development branch)

2. //switch to master branch
git checkout master 

3. //pull all the changes if any from (current development branch)
git pull origin (current development branch)

4. //Now merge development into master    
git merge development

5. //push the master branch
git push origin master

Error
To https://github.com/rajputankit22/todos-posts.git
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'https://github.com/rajputankit22/todos-posts.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Then Use 
5. //push the master branch forcefully
git push -f origin master