Git: пример merge develop в master

Автор: | 21/05/2018
Нет комментариев

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

Переключаемся на мастер, потягиваем последние изменения:

$ git checkout master
$ git pull
Already up to date.

Переключаемся на бранч, который будем мерджить в master, в данном примере это LTHS-380_Update_build_deploy_to_compose:

[simterm]

$ git checkout LTHS-380_Update_build_deploy_to_compose
M       scripts/api_start.sh
M       terraform/terraform-cn.sh
Switched to branch 'LTHS-380_Update_build_deploy_to_compose'
Your branch is up to date with 'origin/LTHS-380_Update_build_deploy_to_compose'.

[/simterm]

M после чекаута указывает на то, что файл был modified:

  • M = modified
  • A = added
  • D = deleted
  • R = renamed
  • C = copied
  • U = updated but unmerged

Но тут эти изменения не нужны, коммитить их не надо, продолжаем.

Подтягиваем последние изменения в девелоп-бранче:

[simterm]

$ git pull
Already up to date.

[/simterm]

Тут изменений нет.

Мержим изменения из мастера в девелоп бранч, что бы сохранить все изменения и решить конфликты, если будут, в девелоп-бранче:

[simterm]

$ git merge master
Already up to date.

[/simterm]

Тут изменений в мастере не было, потому up to date, идём дальше.

Переключаемся на мастер:

[simterm]

$ git checkout master

[/simterm]

Мерджим в него изменения из девелоп-ветки:

[simterm]

$ git merge -m "compose migration complete" --no-ff LTHS-380_Update_build_deploy_to_compose
Removing terraform/files/userdata/eureka.sh
Removing terraform/eureka.tf
Removing packer/eureka/template.json
Removing packer/eureka/app.sh
Merge made by the 'recursive' strategy.
 packer/api/app.sh                   |  1 +
 packer/api/docker-compose.yml       | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 packer/api/template.json            |  8 +++++++-
 packer/eureka/app.sh                | 11 -----------
 packer/eureka/template.json         | 35 -----------------------------------
 terraform/api.tf                    | 35 -----------------------------------
 terraform/eureka.tf                 | 91 -------------------------------------------------------------------------------------------
 terraform/files/userdata/api.sh     | 37 ++++---------------------------------
 terraform/files/userdata/eureka.sh  |  8 --------
 terraform/security_group_api_elb.tf | 74 +-------------------------------------------------------------------------
 terraform/variables.tf              |  3 +++
 11 files changed, 80 insertions(+), 287 deletions(-)
 create mode 100644 packer/api/docker-compose.yml
 delete mode 100644 packer/eureka/app.sh
 delete mode 100644 packer/eureka/template.json
 delete mode 100644 terraform/eureka.tf
 delete mode 100644 terraform/files/userdata/eureka.sh

[/simterm]

Опция --no-ff, или no fast-forward описана в посте Git: merge – зачем нужна опция –no-ff, no-fast-forward.

Теперь осталось запушить изменения в удалённый репозиторий:

[simterm]

$ git push
Counting objects: 1, done.
Writing objects: 100% (1/1), 228 bytes | 228.00 KiB/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To ssh://bitbucket.domain.tld:7999/server-api-infrastructure.git
   391c558..1e23693  master -> master

[/simterm]

Проверяем:

Теперь соберём всё вместе:

  1. git checkout master // переключаемся на мастер, в который будем делать мердж
  2. git pull // подягиваем последние изменения
  3. git checkout develop // переключаемся на бранч, который будем мерджить в мастер
  4. git pull // подтягиваем последние изменения
  5. git merge master // мерджим мастер в девелоп-бранч, решаем конфиликты, если есть, в девелоп бранче
  6. git checkout master // переключаемся на мастер
  7. git merge -m "merge message" develop // мерджим изменения из девелопа в мастер, можно добавить --no-ff
  8. git push // пушим мастер в репозиторий

Если работа над задачей, для которой создавался бранч, закончена — то можно добавить git тег и удалить бранч.

В таком случае процесс будет таким:

  1. git checkout master // переключаемся на мастер, в который будем делать мердж
  2. git pull // подягиваем последние изменения
  3. git checkout develop // переключаемся на бранч, который будем мерджить в мастер
  4. git pull // подтягиваем последние изменения
  5. git merge master // мерджим мастер в девелоп-бранч, решаем конфиликты, если есть, в девелоп бранче
  6. git checkout master // переключаемся на мастер
  7. git merge -m "merge message" develop // мерджим изменения из девелопа в мастер, можно добавить --no-ff
  8. git tag -a v0.1 -m "tag message" // добавляем тег на текущее состояние репозитория
  9. git push origin v0.1 // пушим тег
  10. git branch -d develop // удаляем develop бранч, при необходимости — восстанавливаем из тегов — git checkout -b develop v1.0
  11. git push // пушим мастер в репозиторий

Готово.