그래서 보통 git에서 feature 브랜치를 만들고, 작업을 한 다음 master (trunk) 브랜치와 병합합니다.트렁크의 코드에서 이전 분기를 업데이트하는 방법은 무엇입니까?
필자는 마스터로 병합되지 않은 지형지 물을 만들었습니다.
이제 마스터 분기가 몇 주 또는 몇 달 동안 진행되어 이제 해당 기능 분기를 다시 작업하려고하지만 마스터 분기에있는 모든 항목으로 업데이트하려고합니다.
기능 분기는 모든 새 파일이므로 모든 병합 충돌이 있어야합니다.
어떻게해야합니까?
참고 : 중요한 변경 사항이므로 다시 병합하지 않으려면이 코드를 분기에 보관하고 싶습니다.
당신이 그 이론을 설명 할 수 있다면 나는 그것이 위대하다는 것을 이해할 수있다.
기능 분기를 검사하고 master를 기능 분기 (git merge master)로 병합하거나 master (git rebase master) 맨 위에 기능 분기를 리베이스하십시오.
당신이 선택한 것은 당신이 당신의 역사가 어떻게 보이는지에 달려 있습니다.
병합하는 경우 이전 커밋은 이전 버전의 마스터 위에 계속 유지되며 변경 사항이 포함 된 새로운 병합 커밋 및 새 마스터 버전이 계속 존재하게됩니다. 원래의 역사를 정확하게 반영하고 있기 때문에 리바이스보다 충돌이 적기 때문에이를 좋아하는 사람도 있습니다. 그러나 이런 종류의 연습은 많은 병합 커밋으로 혼란스러운 역사를 창출 할 수 있습니다. 'git bisect'명령은 많은 병합이있는 기록에도 제대로 작동하지 않습니다.
리베이스하면 새 마스터 리비전의 일련의 커밋이 수행되고 원래의 커밋을 잃게됩니다. 이것은 직선적 인 선형 역사를 만듭니다. 또한 'git rebase -i'를 사용하여 커밋을 정리하거나 마스터에 추가하기 전에 커밋을 정리할 수 있습니다. 각 커밋에 대해 충돌을 해결해야하므로 병합 커밋을 한 번 수행하는 대신 리베이스를 수행하면 충돌이 더 많이 발생합니다.
필자는 아직 게시하지 않은 코드를 리베이스하는 것을 선호하며 병행하여 두 곳에서 동시에 발생하는 개발을 표시하기 위해 내역이 실제로 병합되어야합니다 (예 : 포크와 수정 된 프로젝트 업스트림에서 변경 사항을 업 스트림으로 보내려면 때때로 업스트림에서 변경 사항을 병합합니다.
Vincent의 말은 옳다. 나는 당신에게도 rebase를 추천 할 것이다.
마침내 기능을 마스터에 병합하면 개발 내역이 논리적으로 보입니다. 예는 :
last_master_commit_before_feature_merge
feature_commit1
feature_commit2
...
last_feature_commit <-master
이것은 예를 들어, 기능 중 하나가 버그를 만들어 커밋, 경우, 역사를 다시 살펴보고를 통해 병합의 무리를 따라하지 않고 한 커밋 식별하기 쉽다는 것을 의미합니다 역사도. This page은 리베이스에 대한 자세한 정보를 제공해야합니다.
git checkout my_feature_branch
git branch backup_branch
git rebase master
이 그 아무것도 끔찍하게 잘못 가야 그래서 그리고 당신은, 당신이 할 수있는 리셋 버튼을 칠 필요가 : 당신이 리베이스를 선택하면
, 당신이하기 전에 백업 지점을 만듭니다.