마스터에서 Git 브랜치 업데이트

마스터에서 Git 브랜치 업데이트

---

나는 Git을 처음 접했고 지금은 다음과 같은 상황에 처해 있습니다.

• 4 개의 브랜치 (master, b1, b2, b3)가 있습니다.
• b1-b3에서 작업 한 후 다른 모든 브랜치에 있어야하는 브랜치 마스터에서 변경할 사항이 있음을 깨달았습니다.
• 나는 내가 필요한 것을 변경 master했고 ... 여기 내 문제가 있습니다.

master분기 코드로 다른 모든 분기를 어떻게 업데이트 합니까?

---

두 가지 옵션이 있습니다.

첫 번째는 병합이지만 병합에 대한 추가 커밋을 만듭니다.

각 지점 확인 :

git checkout b1

그런 다음 병합 :

git merge origin/master

그런 다음 다음을 누릅니다.

git push origin b1

또는 리베이스를 수행 할 수 있습니다.

git fetch
git rebase origin/master

---

기본적으로 두 가지 옵션이 있습니다.

1. 당신은 병합합니다. 이것은 실제로 매우 간단하고 완벽하게 로컬 작업입니다.

   git checkout b1
   git merge master
   # repeat for b2 and b3
   

   이것은 일어난 그대로의 역사를 남깁니다. master에서 분기하고 모든 브랜치를 변경하고 마지막으로 master의 변경 사항을 세 브랜치 모두에 통합했습니다.

   git이 상황을 정말 잘 처리 할 수 ​​있으며 모든 방향에서 동시에 발생하는 병합을 위해 설계되었습니다. 모든 스레드를 올바르게 통합 할 수 있다고 믿을 수 있습니다. 그것은 단순히 지점 여부를 상관하지 않는다 b1병합 master또는 master병합 b1, 병합 모든 자식에 동일한 모습을 커밋합니다. 유일한 차이점은이 병합 커밋을 가리키는 분기입니다.

2. 당신은 rebase. SVN 또는 유사한 배경을 가진 사람들은 이것이 더 직관적이라고 생각합니다. 명령은 병합 케이스와 유사합니다.

   git checkout b1
   git rebase master
   # repeat for b2 and b3
   

   사람들은 모든 지점에서 선형적인 역사를 유지하기 때문에이 접근 방식을 좋아합니다. 그러나이 선형적인 역사는 거짓말이고 당신은 그것이 사실임을 알아야합니다. 이 커밋 그래프를 고려하십시오.

   A --- B --- C --- D <-- master
    \
     \-- E --- F --- G <-- b1
   

   병합은 진정한 역사를 만듭니다.

   A --- B --- C --- D <-- master
    \                 \
     \-- E --- F --- G +-- H <-- b1
   

   그러나 rebase는 다음과 같은 역사를 제공합니다.

   A --- B --- C --- D <-- master
                      \
                       \-- E' --- F' --- G' <-- b1
   

   The point is, that the commits E', F', and G' never truly existed, and have likely never been tested. They may not even compile. It is actually quite easy to create nonsensical commits via a rebase, especially when the changes in master are important to the development in b1.

   The consequence of this may be, that you can't distinguish which of the three commits E, F, and G actually introduced a regression, diminishing the value of git bisect.

   I am not saying that you shouldn't use git rebase. It has its uses. But whenever you do use it, you need to be aware of the fact that you are lying about history. And you should at least compile test the new commits.

---

git rebase master is the proper way to do this. Merging would mean a commit would be created for the merge, while rebasing would not.

---

If you've been working on a branch on-and-off, or lots has happened in other branches while you've been working on something, it's best to rebase your branch onto master. This keeps the history tidy and makes things a lot easier to follow.

git checkout master
git pull
git checkout local_branch_name
git rebase master
git push --force # force required if you've already pushed

Notes:

• Don't rebase branches that you've collaborated with others on.
• You should rebase on the branch to which you will be merging which may not always be master.

There's a chapter on rebasing at http://git-scm.com/book/ch3-6.html, and loads of other resources out there on the web.

---

@cmaster made the best elaborated answer. In brief:

git checkout master #
git pull # update local master from remote master
git checkout <your_branch>
git merge master # solve merge conflicts if you have`

You should not rewrite branch history instead keep them in actual state for future references. While merging to master, it creates one extra commit but that is cheap. Commits does not cost.

---

To update other branches like (backup) with your master branch copy. You can do follow either way (rebase or merge)...

1. Do rebase (there won't be any extra commit made to the backup branch).

2. Merge branches (there will be an extra commit automatically to the backup branch).

   Note : Rebase is nothing but establishing a new base (a new copy)

git checkout backup
git merge master
git push

(Repeat for other branches if any like backup2 & etc..,)

git checkout backup
git rebase master
git push

(Repeat for other branches if any like backup2 & etc..,)

---

You can merge, or you can apply individual commits across branches by using git cherry-pick.

---

There are two options for this problem.

1) git rebase

2) git merge

Only diff with above both in case of merge, will have extra commit in history

1) git checkout branch(b1,b2,b3)

2) git rebase origin/master (In case of conflicts resolve locally by doing git rebase --continue)

3) git push

Alternatively, git merge option is similar fashion

1) git checkout "your_branch"(b1,b2,b3)

2) git merge master

3) git push

참고URL : https://stackoverflow.com/questions/3876977/update-git-branches-from-master