Git 워크플로 및 리베이스와 병합 질문

StackOverflow https://stackoverflow.com/questions/457927

문제

저는 다른 개발자와 함께 프로젝트에서 몇 달 동안 Git을 사용해 왔습니다.나는 수년간의 경험을 가지고 있습니다. SVN, 그래서 나는 관계에 많은 짐을 가져오는 것 같아요.

Git이 분기 및 병합에 탁월하다는 말을 들었지만 지금까지는 그것을 볼 수 없습니다.물론, 분기는 매우 간단하지만 병합을 시도하면 모든 것이 엉망이 됩니다.이제 저는 SVN에 익숙해졌지만, 하나의 하위 버전 관리 시스템을 다른 시스템으로 교환한 것 같습니다.

내 파트너는 내 문제가 무작정 병합하려는 욕구에서 비롯되며 많은 상황에서 병합 대신 리베이스를 사용해야 한다고 말합니다.예를 들어, 그가 정한 작업 흐름은 다음과 같습니다.

clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature
git checkout master
git merge my_new_feature

기본적으로 기능 분기를 생성하고, 항상 마스터에서 분기로 리베이스하고, 분기에서 다시 마스터로 병합합니다.중요한 점은 지점이 항상 로컬로 유지된다는 것입니다.

제가 시작한 워크플로는 다음과 같습니다.

clone remote repository
create my_new_feature branch on remote repository
git checkout -b --track my_new_feature origin/my_new_feature
..work, commit, push to origin/my_new_feature
git merge master (to get some changes that my partner added)
..work, commit, push to origin/my_new_feature
git merge master
..finish my_new_feature, push to origin/my_new_feature
git checkout master
git merge my_new_feature
delete remote branch
delete local branch

두 가지 본질적인 차이점이 있습니다.저는 리베이스 대신 항상 병합을 사용하고 기능 브랜치(및 기능 브랜치 커밋)를 원격 저장소에 푸시합니다.

원격 지점을 선택한 이유는 작업하는 동안 내 작업이 백업되기를 원하기 때문입니다.우리 저장소는 자동으로 백업되며 문제가 발생하면 복원할 수 있습니다.내 노트북은 그렇지 않거나 철저하지 않습니다.그러므로 나는 다른 곳에 미러링되지 않은 코드를 내 노트북에 두는 것을 싫어합니다.

리베이스 대신 병합을 선택한 이유는 병합이 표준인 것 같고 리베이스가 고급 기능인 것 같다는 것입니다.내 직감으로는 내가 하려는 작업이 고급 설정이 아니므로 리베이스가 불필요해야 한다는 것입니다.나는 Git에 관한 새로운 Pragmatic 프로그래밍 책을 정독했는데, 거기에서는 병합을 광범위하게 다루고 리베이스에 대해서는 거의 언급하지 않았습니다.

어쨌든, 나는 최근 브랜치에서 내 워크플로를 따르고 있었는데, 그것을 다시 마스터에 병합하려고 했을 때 모든 것이 엉망이 되었습니다.중요하지 않아야 할 것들과의 갈등이 엄청나게 많았습니다.갈등은 나에게 이해가되지 않았습니다.모든 것을 정리하는 데 하루가 걸렸고 결국 원격 마스터로 강제 푸시하게 되었습니다. 로컬 마스터가 모든 충돌을 해결했지만 원격 마스터는 여전히 만족하지 않았기 때문입니다.

이와 같은 작업에 대한 "올바른" 작업 흐름은 무엇입니까?Git은 분기와 병합을 매우 쉽게 만들어 주는데, 아직 보이지 않습니다.

업데이트 2011-04-15

이것은 매우 인기 있는 질문인 것 같아서 처음 질문한 이후 2년 간의 경험을 바탕으로 업데이트해야겠다고 생각했습니다.

적어도 우리의 경우에는 원래 작업 흐름이 올바른 것으로 나타났습니다.즉, 이것이 우리가 하는 일이며 작동합니다.

clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature, commit
git rebase master
git checkout master
git merge my_new_feature

사실 우리의 작업 흐름은 우리가 하는 경향과 약간 다릅니다. 스쿼시 병합 원시 병합 대신.(메모:논란의 여지가 있습니다. 아래를 참조하세요.) 이를 통해 전체 기능 분기를 마스터의 단일 커밋으로 전환할 수 있습니다.그런 다음 기능 분기를 삭제합니다.이를 통해 브랜치에서 약간 지저분하더라도 마스터에서 커밋을 논리적으로 구조화할 수 있습니다.그래서 이것이 우리가 하는 일입니다:

clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature, commit
git rebase master
git checkout master
git merge --squash my_new_feature
git commit -m "added my_new_feature"
git branch -D my_new_feature

스쿼시 병합 논란 - 여러 논평자가 지적했듯이 스쿼시 병합은 기능 분기의 모든 기록을 삭제합니다.이름에서 알 수 있듯이 모든 커밋을 하나로 압축합니다.작은 기능의 경우 단일 패키지로 압축하므로 이는 의미가 있습니다.더 큰 기능의 경우 특히 개별 커밋이 이미 원자적인 경우에는 좋은 생각이 아닐 수 있습니다.그것은 정말로 개인 취향에 달려 있습니다.

Github 및 Bitbucket(기타?) 풀 요청 - 병합/리베이스가 끌어오기 요청과 어떻게 관련되는지 궁금하신 경우 마스터로 다시 병합할 준비가 될 때까지 위의 모든 단계를 수행하는 것이 좋습니다.git과 수동으로 병합하는 대신 PR을 수락하면 됩니다.이것은 스쿼시 병합을 수행하지 않지만(적어도 기본적으로는 아님) 스쿼시나 빨리 감기가 아닌 것이 Pull Request 커뮤니티에서 허용되는 병합 규칙입니다(내가 아는 한).구체적으로 다음과 같이 작동합니다.

clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature, commit
git rebase master
git push # May need to force push
...submit PR, wait for a review, make any changes requested for the PR
git rebase master
git push # Will probably need to force push (-f), due to previous rebases from master
...accept the PR, most likely also deleting the feature branch in the process
git checkout master
git branch -d my_new_feature
git remote prune origin

나는 Git을 사랑하게 되었고 결코 SVN으로 돌아가고 싶지 않습니다.어려움을 겪고 있다면 그냥 버티세요. 그러면 결국 터널 끝에서 빛을 보게 될 것입니다.

도움이 되었습니까?

해결책

"충돌"은 "동일한 콘텐츠의 병렬 진화"를 의미합니다.따라서 병합 중에 "전부 지옥"이 되면 동일한 파일 세트에 대해 엄청난 발전이 있다는 의미입니다.

리베이스가 병합보다 나은 이유는 다음과 같습니다.

  • 마스터 중 하나를 사용하여 로컬 커밋 기록을 다시 작성합니다(그런 다음 작업을 다시 적용하고 충돌을 해결합니다).
  • 최종 병합은 확실히 "빨리 감기" 작업이 될 것입니다. 왜냐하면 마스터의 모든 커밋 기록과 재적용할 변경 사항만 포함하기 때문입니다.

이 경우 올바른 작업 흐름(공통 파일 세트의 발전)이 다음과 같음을 확인합니다. 먼저 리베이스한 다음 병합하세요..

그러나 이는 백업 목적으로 로컬 브랜치를 푸시하는 경우 다른 사람이 해당 브랜치를 끌어오거나 적어도 사용해서는 안 된다는 것을 의미합니다(커밋 기록은 연속적인 리베이스에 의해 다시 작성되므로).

해당 주제(리베이스 후 병합 워크플로)에 대해 바라폰토 댓글에서 두 가지 흥미로운 게시물을 언급했습니다. 둘 다 randyfay.com:

이 기술을 사용하면 현재 버전으로 업데이트된 패치처럼 작업이 항상 공개 브랜치 위에 위치하게 됩니다. HEAD.

(비슷한 기술 바자회를 위해 존재합니다)

다른 팁

TL;DR

git rebase 워크플로는 충돌 해결에 능숙하지 못한 사람이나 SVN 워크플로에 익숙한 사람으로부터 사용자를 보호하지 않습니다. Git 재해 방지:잔혹한 이야기.이는 갈등 해결을 더욱 지루하게 만들고 잘못된 갈등 해결에서 회복하기 어렵게 만듭니다.대신 diff3을 사용하면 애초에 그리 어렵지 않습니다.

Rebase 작업 흐름은 충돌 해결에 더 좋지 않습니다!

나는 기록 정리에 대한 리베이스를 매우 지지합니다.그러나 만일 충돌이 발생한 경우 즉시 리베이스를 중단하고 대신 병합을 수행합니다! 사람들이 충돌 해결을 위해 병합 워크플로에 대한 더 나은 대안으로 리베이스 워크플로를 권장하고 있다는 사실이 정말 안타깝습니다(이 질문의 내용이 바로 이것이었습니다).

병합 중에 "모두 지옥"이 되면 리베이스 중에 "모두 지옥"이 되며 잠재적으로 훨씬 더 지옥이 될 수도 있습니다!이유는 다음과 같습니다.

이유 #1:각 커밋에 대해 한 번이 아닌 한 번만 충돌을 해결합니다.

병합 대신 리베이스를 수행하는 경우 동일한 충돌에 대해 리베이스 커밋 수만큼 충돌 해결을 수행해야 합니다!

실제 시나리오

나는 지점에서 복잡한 메소드를 리팩터링하기 위해 마스터에서 분기합니다.내 리팩토링 작업은 리팩터링하고 코드 검토를 받기 위해 총 15개의 커밋으로 구성됩니다.내 리팩토링에는 이전에 마스터에 있었던 혼합 탭과 공백을 수정하는 작업이 포함됩니다.이는 필요하지만 불행하게도 나중에 마스터에서 이 방법을 변경하면 충돌이 발생합니다.물론, 내가 이 메서드를 작업하는 동안 누군가가 내 변경 사항과 병합되어야 하는 마스터 브랜치의 동일한 메서드에 대해 간단하고 합법적인 변경을 수행했습니다.

내 브랜치를 마스터와 다시 병합할 때가 되면 두 가지 옵션이 있습니다.

자식 병합: 갈등이 생깁니다.나는 그들이 그것을 마스터하고 내 지점(의 최종 제품)과 병합하기 위해 변경한 사항을 봅니다.완료.

자식 리베이스: 나와 충돌이 발생합니다. 첫 번째 저지르다.충돌을 해결하고 리베이스를 계속합니다.나와 충돌이 발생합니다. 두번째 저지르다.충돌을 해결하고 리베이스를 계속합니다.나와 충돌이 발생합니다. 제삼 저지르다.충돌을 해결하고 리베이스를 계속합니다.나와 충돌이 발생합니다. 네번째 저지르다.충돌을 해결하고 리베이스를 계속합니다.나와 충돌이 발생합니다. 다섯 저지르다.충돌을 해결하고 리베이스를 계속합니다.나와 충돌이 발생합니다. 육도 음정 저지르다.충돌을 해결하고 리베이스를 계속합니다.나와 충돌이 발생합니다. 제칠 저지르다.충돌을 해결하고 리베이스를 계속합니다.나와 충돌이 발생합니다. 여덟 번째 저지르다.충돌을 해결하고 리베이스를 계속합니다.나와 충돌이 발생합니다. 제구 저지르다.충돌을 해결하고 리베이스를 계속합니다.나와 충돌이 발생합니다. 제십 저지르다.충돌을 해결하고 리베이스를 계속합니다.나와 충돌이 발생합니다. 십일 저지르다.충돌을 해결하고 리베이스를 계속합니다.나와 충돌이 발생합니다. 열두 번째 저지르다.충돌을 해결하고 리베이스를 계속합니다.나와 충돌이 발생합니다. 열세번째 저지르다.충돌을 해결하고 리베이스를 계속합니다.나와 충돌이 발생합니다. 제 십사 저지르다.충돌을 해결하고 리베이스를 계속합니다.나와 충돌이 발생합니다. 제 십오 저지르다.충돌을 해결하고 리베이스를 계속합니다.

만약에 당신은 나를 농담해야합니다 이것 선호하는 작업 흐름입니다.필요한 것은 마스터에서 한 가지 변경 사항과 충돌하는 공백 수정뿐이며, 모든 커밋은 충돌하므로 해결해야 합니다.그리고 이것은 단순한 공백 충돌만 있는 시나리오. 천국에서는 파일 전체의 주요 코드 변경과 관련된 실제 충돌이 발생하는 것을 금지하고 이를 해결해야 합니다. 저것 여러 번.

추가로 수행해야 할 모든 충돌 해결로 인해 다음과 같은 가능성이 높아집니다. 당신은 실수를 할 것입니다.하지만 git에서는 실행 취소가 가능하므로 실수해도 괜찮습니다. 그렇죠?물론 빼고...

이유 #2:리베이스를 사용하면 실행 취소가 없습니다!

갈등 해결이 어려울 수 있고, 어떤 사람들은 갈등 해결에 매우 서툴다는 점에 우리 모두 동의할 수 있다고 생각합니다.실수하기가 매우 쉬우므로 git을 사용하면 쉽게 실행 취소할 수 있어 매우 좋습니다!

병합할 때 브랜치에서 git은 충돌 해결이 제대로 이루어지지 않으면 삭제하거나 수정할 수 있는 병합 커밋을 생성합니다.이미 잘못된 병합 커밋을 공개/권한 있는 저장소에 푸시한 경우에도 다음을 사용할 수 있습니다. git revert 병합으로 인해 발생한 변경 사항을 취소하고 새 병합 커밋에서 병합을 올바르게 다시 실행합니다.

리베이스할 때 충돌 해결이 잘못되면 망할 수 있습니다.이제 모든 커밋에는 잘못된 병합이 포함되어 있으므로 리베이스*를 다시 실행할 수는 없습니다.기껏해야 영향을 받은 각 커밋으로 돌아가서 수정해야 합니다.재미 없어.

리베이스 후에는 원래 커밋의 일부였던 것이 무엇인지, 잘못된 충돌 해결로 인해 도입된 것이 무엇인지 판단하는 것이 불가능합니다.

*git의 내부 로그에서 이전 참조를 파헤칠 수 있거나 리베이스하기 전 마지막 커밋을 가리키는 세 번째 브랜치를 생성하는 경우 리베이스를 실행 취소할 수 있습니다.

갈등 해결에서 벗어나세요:diff3 사용

다음과 같은 충돌을 예로 들어 보겠습니다.

<<<<<<< HEAD
TextMessage.send(:include_timestamp => true)
=======
EmailMessage.send(:include_timestamp => false)
>>>>>>> feature-branch

충돌을 살펴보면 각 분기가 무엇을 변경했는지, 그 의도가 무엇인지 알 수 없습니다.이것이 갈등 해결이 혼란스럽고 어려운 가장 큰 이유라고 생각합니다.

diff3를 구출해주세요!

git config --global merge.conflictstyle diff3

diff3을 사용하면 각각의 새로운 충돌에는 병합된 공통 조상인 세 번째 섹션이 있습니다.

<<<<<<< HEAD
TextMessage.send(:include_timestamp => true)
||||||| merged common ancestor
EmailMessage.send(:include_timestamp => true)
=======
EmailMessage.send(:include_timestamp => false)
>>>>>>> feature-branch

먼저 병합된 공통 조상을 조사합니다.그런 다음 각 측면을 비교하여 각 분기의 의도를 결정합니다.HEAD가 EmailMessage를 TextMessage로 변경한 것을 확인할 수 있습니다.그 의도는 동일한 매개변수를 전달하여 TextMessage에 사용되는 클래스를 변경하는 것입니다.또한 feature-branch의 의도는 :include_timestamp 옵션에 대해 true 대신 false를 전달하는 것임을 알 수 있습니다.이러한 변경 사항을 병합하려면 두 가지 의도를 결합하세요.

TextMessage.send(:include_timestamp => false)

일반적으로:

  1. 공통 조상을 각 분기와 비교하고 가장 간단한 변경 사항이 있는 분기를 확인합니다.
  2. 간단한 변경 사항을 다른 분기의 코드 버전에 적용하여 더 간단한 변경 사항과 더 복잡한 변경 사항을 모두 포함하도록 합니다.
  3. 방금 변경 사항을 병합한 부분을 제외한 충돌 코드의 모든 부분을 제거합니다.

번갈아 하는:브랜치의 변경 사항을 수동으로 적용하여 해결하세요.

마지막으로 일부 충돌은 diff3을 사용해도 이해하기 끔찍합니다.이는 특히 diff가 의미상 공통적이지 않은 공통 행을 찾을 때 발생합니다(예:두 가지 모두 우연히 같은 위치에 빈 줄이 생겼습니다!).예를 들어, 한 분기는 클래스 본문의 들여쓰기를 변경하거나 유사한 메서드를 재정렬합니다.이러한 경우 더 나은 해결 전략은 병합의 양쪽에서 변경 사항을 검사하고 수동으로 다른 파일에 diff를 적용하는 것입니다.

병합하는 시나리오에서 충돌을 어떻게 해결할 수 있는지 살펴보겠습니다. origin/feature1 어디 lib/message.rb 갈등.

  1. 현재 체크아웃된 분기(HEAD, 또는 --ours) 또는 병합할 브랜치(origin/feature1, 또는 --theirs) 적용하기가 더 간단한 변경사항입니다.삼중점과 함께 diff 사용(git diff a...b)는 다음에 발생한 변경 사항을 보여줍니다. b 마지막 분기 이후 a, 즉, a와 b의 공통 조상을 b와 비교합니다.

    git diff HEAD...origin/feature1 -- lib/message.rb # show the change in feature1
git diff origin/feature1...HEAD -- lib/message.rb # show the change in our branch

  2. 더 복잡한 버전의 파일을 확인해 보세요.이렇게 하면 모든 충돌 마커가 제거되고 선택한 측면이 사용됩니다.

    git checkout --ours -- lib/message.rb   # if our branch's change is more complicated
git checkout --theirs -- lib/message.rb # if origin/feature1's change is more complicated

  3. 복잡한 변경 사항을 체크아웃한 후 더 간단한 변경 사항의 차이점을 가져옵니다(1단계 참조).이 diff의 각 변경 사항을 충돌하는 파일에 적용합니다.

내 작업 흐름에서는 가능한 한 많이 리베이스합니다. 그리고 자주 그렇게 하려고 노력합니다.불일치가 누적되지 않도록 하면 분기 간 충돌의 양과 심각도가 크게 줄어듭니다.

그러나 대부분 리베이스 기반 워크플로에도 병합을 위한 공간이 있습니다.

병합은 실제로 두 개의 부모가 있는 노드를 생성한다는 점을 기억하세요.이제 다음 상황을 고려하십시오.저는 두 개의 독립적인 기능 브랜치 A와 B를 가지고 있으며 이제 A와 B가 검토되는 동안 A와 B 모두에 의존하는 기능 브랜치 C에 대한 작업을 개발하고 싶습니다.

그러면 내가 하는 일은 다음과 같습니다.

  1. A 위에 C 브랜치를 생성(및 체크아웃)합니다.
  2. B와 병합

이제 브랜치 C에는 A와 B의 변경 사항이 모두 포함되며 계속해서 개발할 수 있습니다.A를 변경하면 다음과 같은 방법으로 분기 그래프를 재구성합니다.

  1. A의 새 상단에 분기 T를 만듭니다.
  2. T를 B와 병합
  3. C를 T로 리베이스
  4. T 지점 삭제

이런 식으로 실제로 임의의 분기 그래프를 유지할 수 있지만 위에서 설명한 상황보다 더 복잡한 작업을 수행하는 것은 이미 너무 복잡합니다. 상위 항목이 변경될 때 리베이스를 수행하는 자동 도구가 없다는 점을 고려하면 말이죠.

거의 모든 상황에서 git push Origin --mirror를 사용하지 마십시오.

이 작업을 수행할지 여부를 묻지 않으며 확실하게 하는 것이 좋습니다. 왜냐하면 로컬 상자에 없는 모든 원격 분기가 지워지기 때문입니다.

http://twitter.com/dysinger/status/1273652486

귀하의 설명을 읽은 후 한 가지 질문이 있습니다.당신은 한 번도 해본 적이 없을 수도 있나요?

git checkout master
git pull origin
git checkout my_new_feature

기능 브랜치에서 'git rebase/merge master'를 수행하기 전에?

왜냐하면 당신의 master 브랜치는 친구의 저장소에서 자동으로 업데이트되지 않습니다.당신은 그 일을해야합니다 git pull origin.즉.아마도 항상 변경되지 않는 로컬 마스터 브랜치에서 리베이스할 것입니까?그런 다음 푸시 시간이 오면 본 적이 없는 (로컬) 커밋이 있는 저장소를 푸시하므로 푸시가 실패합니다.

귀하의 상황에서는 귀하의 파트너가 옳다고 생각합니다.리베이스의 좋은 점은 외부인에게는 변경 사항이 모두 자체적으로 깔끔한 순서로 발생한 것처럼 보인다는 것입니다.이는 다음을 의미합니다.

  • 변경사항을 검토하기가 매우 쉽습니다.
  • 계속해서 훌륭하고 작은 커밋을 만들 수 있지만 해당 커밋 세트를 (마스터로 병합하여) 한 번에 공개할 수 있습니다.
  • 공개 마스터 브랜치를 보면 다양한 개발자가 다양한 기능에 대해 다양한 일련의 커밋을 볼 수 있지만 모두 혼합되지는 않습니다.

백업을 위해 계속해서 개인 개발 브랜치를 원격 저장소에 푸시할 수 있지만 리베이스할 것이기 때문에 다른 사람들은 이를 "공용" 브랜치로 취급해서는 안 됩니다.그런데 이 작업을 수행하기 위한 쉬운 명령은 다음과 같습니다. git push --mirror origin .

기사 Git을 사용한 패키징 소프트웨어 병합과 리베이스의 장단점을 아주 훌륭하게 설명하고 있습니다.약간 다른 맥락이지만 원칙은 동일합니다. 기본적으로 브랜치가 퍼블릭인지 프라이빗인지, 그리고 이를 메인라인에 어떻게 통합할지에 따라 결정됩니다.

어쨌든, 나는 최근 브랜치에서 내 워크플로를 따르고 있었는데, 그것을 다시 마스터에 병합하려고 했을 때 모든 것이 엉망이 되었습니다.중요하지 않아야 할 것들과의 갈등이 엄청나게 많았습니다.갈등은 나에게 이해가되지 않았습니다.모든 것을 정리하는 데 하루가 걸렸고 결국 원격 마스터로 강제 푸시하게 되었습니다. 로컬 마스터가 모든 충돌을 해결했지만 원격 마스터는 여전히 만족하지 않았기 때문입니다.

귀하의 파트너나 귀하가 제안한 워크플로에서 이해되지 않는 충돌이 발생하지 않았어야 합니다.그랬더라도 제안된 워크플로를 따르고 있다면 해결 후 '강제' 푸시가 필요하지 않습니다.이는 푸시하려는 분기를 실제로 병합하지 않았지만 원격 팁의 하위 항목이 아닌 분기를 푸시해야 했음을 나타냅니다.

무슨 일이 일어났는지 잘 살펴봐야 할 것 같아요.로컬 브랜치를 생성한 시점과 로컬 브랜치에 다시 병합하려고 시도한 시점 사이에 다른 사람이 (의도적으로든 아니든) 원격 마스터 브랜치를 되감았을 수 있습니까?

다른 많은 버전 제어 시스템과 비교할 때 Git을 사용하면 도구와의 싸움이 줄어들고 소스 스트림에 근본적인 문제를 해결할 수 있다는 것을 알았습니다.Git은 마법을 수행하지 않으므로 변경 사항이 충돌하면 충돌이 발생하지만 커밋 상위 항목을 추적하여 쓰기 작업을 쉽게 수행할 수 있어야 합니다.

내가 관찰한 바에 따르면 git merge는 병합 후에도 분기를 별도로 유지하는 경향이 있는 반면, rebase 이후 merge는 이를 하나의 단일 분기로 결합합니다.후자는 훨씬 깔끔하게 나오는 반면, 전자는 병합 후에도 어떤 커밋이 어떤 브랜치에 속하는지 알아내기가 더 쉽습니다.

"브랜치가 몇 개밖에 없는 단일 개발자라도 리베이스와 병합을 올바르게 사용하는 습관을 들이는 것은 가치가 있습니다.기본 작업 패턴은 다음과 같습니다.

  • 기존 분기 A에서 새 분기 B를 만듭니다.

  • 브랜치 B에 변경 사항 추가/커밋

  • 지점 A의 업데이트를 리베이스하세요.

  • 브랜치 B의 변경 사항을 브랜치 A에 병합합니다."

https://www.atlassian.com/git/tutorials/merging-vs-rebasing/

Git에는 "올바른" 작업 흐름이 없습니다.보트에 떠다니는 모든 것을 사용하세요.그러나 브랜치를 병합할 때 지속적으로 충돌이 발생한다면 동료 개발자와 협력하여 노력을 더 잘 조정해야 할까요?두 분이 계속 같은 파일을 편집하시는 것 같군요.또한 공백 및 파괴 키워드(예: "$Id$" 및 기타)에 주의하세요.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top