Git 병합 마스터를 기능 브랜치로

Git 병합 마스터를 기능 브랜치로

---

git에 다음과 같은 상황이 있다고 가정 해 보겠습니다.

1. 생성 된 저장소 :

   mkdir GitTest2
   cd GitTest2
   git init
   

2. 마스터에서 일부 수정이 발생하고 커밋됩니다.

   echo "On Master" > file
   git commit -a -m "Initial commit"
   

3. Feature1이 마스터에서 분기되고 일부 작업이 완료되었습니다.

   git branch feature1
   git checkout feature1
   echo "Feature1" > featureFile
   git commit -a -m "Commit for feature1"
   

4. 한편, 마스터 코드에서 버그가 발견되고 핫픽스 분기가 설정됩니다.

   git checkout master
   git branch hotfix1
   git checkout hotfix1
   

5. 이 버그는 핫픽스 브랜치에서 수정되어 마스터로 다시 병합됩니다 (아마도 풀 요청 / 코드 검토 후).

   echo "Bugfix" > bugfixFile
   git commit -a -m "Bugfix Commit"
   git checkout master
   git merge --no-ff hotfix1
   

6. feature1 개발은 계속됩니다.

   git checkout feature1
   

이제 내 질문 : 버그가 거기에서도 발생하기 때문에 기능 브랜치에 핫픽스가 필요하다고 가정 해 보겠습니다. 커밋을 기능 브랜치에 복제하지 않고 어떻게이 작업을 수행 할 수 있습니까? 기능 구현과 관련이없는 기능 브랜치에서 두 개의 새로운 커밋을받는 것을 방지하고 싶습니다. 이것은 내가 Pull Requests를 사용하는 경우 특히 중요해 보입니다.이 모든 커밋은 Pull Request에도 포함될 것이며 이미 수행되었지만 검토되어야합니다 (핫픽스는 이미 마스터에 있음).

나는 할 수 없습니다 git merge master --ff-only: "치명적 : 빨리 감기, 중단 할 수 없습니다 .",하지만 이것이 도움이되었는지 확실하지 않습니다.

---

master에서 브랜치를 리베이스 할 수 있어야합니다.

git checkout feature1
git rebase master

발생하는 모든 갈등을 관리합니다. 버그 수정 (이미 master에 있음)이있는 커밋에 도달하면 git은 변경 사항이 없으며 이미 적용되었을 수 있다고 말합니다. 그런 다음 (마스터에 이미있는 커밋을 건너 뛰면서) rebase를 계속합니다.

git rebase --skip

당신이를 수행하면 git log당신의 기능 분기에, 당신은 버그를 수정 한 번만 표시 커밋을 참조 마스터 부분에 있습니다.

더 자세한 논의는 이 정확한 사용 사례를 다루는 Git 책 문서 git rebase( https://git-scm.com/docs/git-rebase )를 참조하십시오 .

================ 추가 컨텍스트 편집 ===================

이 답변은 @theomega의 특정 상황을 고려하여 질문에 특별히 제공되었습니다. 이 부분을 참고하십시오.

기능 구현과 관련이없는 기능 브랜치에서 [...] 커밋을 방지하고 싶습니다.

master에 대한 그의 private 브랜치를 리베이스하는 것이 정확히 그 결과를 낳을 것입니다. 반대로 master를 브랜치에 병합하면 그가 특별히 원하지 않는 일을 정확하게 수행 할 수 있습니다. 브랜치를 통해 작업중인 기능 구현과 관련이없는 커밋을 추가합니다.

질문 제목을 읽는 사용자를 처리하려면 질문의 실제 내용과 컨텍스트를 건너 뛰고 항상 (다른) 사용 사례에 적용된다는 가정하에 맹목적으로 상위 답변 만 읽으십시오. 자세히 설명하겠습니다.

• 리베이스 전용 브랜치 (즉, 로컬 리포지토리에만 존재하고 다른 사람과 공유되지 않음) 만 리베이스합니다. 공유 브랜치를 리베이스하면 다른 사람들이 가질 수있는 복사본이 "파괴"됩니다.
• 브랜치 (마스터 브랜치이든 다른 브랜치이든)의 변경 사항을 퍼블릭 브랜치에 통합하려는 경우 (예 : 브랜치를 풀 요청을 열기 위해 푸시했지만 이제 마스터와 충돌이 발생하여 업데이트해야합니다. 갈등을 해결하기 위해 분기) 병합해야합니다 (예 : git merge master@Sven의 답변에서 와 같이).
• 선호하는 경우 로컬 프라이빗 브랜치에 브랜치를 병합 할 수도 있지만 브랜치에서 "외부"커밋이 발생한다는 점에 유의하십시오.

마지막으로,이 답변이 @theomega를위한 것이지만 귀하의 상황에 가장 적합하지 않다는 사실에 만족하지 않는다면, 아래에 댓글을 추가하는 것은 특별히 도움이되지 않을 것입니다. 어떤 답변이 선택되었는지 제어 할 수 없습니다. @theomega만이합니다.

---

How to merge the master branch into the feature branch? Easy:

git checkout feature1
git merge master

There is no point in forcing a fast forward merge here, as it cannot be done. You committed both into the feature branch and the master branch. Fast forward is impossible now.

Have a look at gitflow. It is a branching model for git that can be followed, and you unconsciously already did. It also is an extension to git which adds some commands for the new workflow steps that do things automatically which you would otherwise need to do manually.

So what did you do right in your workflow? You have two branches to work with, your feature1 branch is basically the "develop" branch in the gitflow model.

You created a hotfix branch from master and merged it back. And now you are stuck.

The gitflow model asks you to merge the hotfix also to the devel branch, which is "feature1" in your case.

So the real answer would be:

git checkout feature1
git merge --no-ff hotfix1

This adds all the changes that were made inside the hotfix to the feature branch, but ONLY those changes. They might conflict with other development changes in the branch, but they will not conflict with the master branch should you merge the feature branch back to master eventually.

Be very careful with rebasing. Only rebase if the changes you did stayed local to your repository, e.g. you did not push any branches to some other repository. Rebasing is a great tool for you to arrange your local commits into a useful order before pushing it out into the world, but rebasing afterwards will mess up things for the git beginners like you.

---

Basing on this article you should:

• create new branch which is based upon new version of master

  git branch -b newmaster

• merge your old feature branch into new one

  git checkout newmaster

• resolve conflict on new feature branch

The first two commands can be combined to git checkout -b newmaster

This way your history stays clear because you don't need back merges. And you don't need to be so super cautious since you don't need git rebase

---

Zimi's answer describes this process generally. Here are the specifics:

1) Create and switch to a new branch. Make sure the new branch is based on master so it will include the recent hotfixes.

git checkout master
git branch feature1_new
git checkout feature1_new

# Or, combined into one command:
git checkout -b feature1_new master

2) After switching to the new branch, merge the changes from your existing feature branch. This will add your commits without duplicating the hotfix commits.

git merge feature1

3) On the new branch, resolve any conflicts between your feature and the master branch.

Done! Now use the new branch to continue to develop your feature.

---

You might be able to do a "cherry-pick" to pull the exact commit(s) that you need in to your feature branch.

Do a git checkout hotfix1 to get on the hotfix1 branch. Then do a git log to get the SHA1 hash (big sequence of random letters and numbers that uniquely identifies a commit) of the commit in question. Copy that (or the first 10 or so characters).

Then, git checkout feature1 to get back onto your feature branch.

Then, git cherry-pick <the SHA1 hash that you just copied>

That will pull that commit, and only that commit, into your feature branch. That change will be in the branch - you just "cherry-picked" it in. Then, resume work, edit, commit, push, etc. to your heart's content.

When, eventually, you perform another merge from one branch into your feature branch (or vice-versa), git will recognize that you've already merged in that particular commit, know that it doesn't have to make it again, and just "skip over" it.

---

Here is a script you can use to merge your master branch into your current branch.

The script does the following:

• Switches to the master branch
• Pulls the master branch
• Switches back to your current branch
• Merges the master branch into your current branch

Save this code as a batch file (.bat) and place the script anywhere in your repository. Then click on it to run it and you are set.

:: This batch file pulls current master and merges into current branch

@echo off

:: Option to use the batch file outside the repo and pass the repo path as an arg
set repoPath=%1
cd %repoPath%

FOR /F "tokens=*" %%g IN ('git rev-parse --abbrev-ref HEAD') do (SET currentBranch=%%g)

echo current branch is %currentBranch%
echo switching to master
git checkout master
echo.
echo pulling origin master
git pull origin master
echo.
echo switching back to %currentBranch%
git checkout %currentBranch%
echo.
echo attemting merge master into %currentBranch%
git merge master
echo.
echo script finished successfully
PAUSE

---

git checkout feature_branch_name
git pull origin master_branch_name

참고URL : https://stackoverflow.com/questions/16955980/git-merge-master-into-feature-branch