저는 프로젝트에서 다른 개발자와 함께 작업하고 있으며 원격 저장소로 Github를 사용하고 있습니다. 저는 git 1.7.7.3을 사용하는 Mac에 있고, git 1.7.6을 사용하는 Windows에 있습니다.
이게 무슨 일이야
- 우리 중 한 명 (그를 개발자 A라고 부르겠습니다.하지만 어느 것이 문제가되지 않습니다)는 일련의 커밋을 GitHub에 푸시합니다.
- 다른 하나 (개발자 B)는 일부 로컬 커밋을 수행합니다.
- B는
git pull. - B는
git push. - 커밋 내역 로그를 보면 github.com:foo/bar의 Merge branch ‘master’가 보입니다.
커밋 로그는 시간이 지남에 따라 “Merge branch”메시지로 흩어져 있으며 개발자 A가 변경 한 내용을 커밋하는 것으로 개발자 B도 표시합니다. 이 문제를 방지하기 위해 우리가 찾은 유일한 방법은 git pull --rebase3 단계에서 를 수행하는 것이었지만 리베 이싱이 어떤 부작용을 가져올 지 모르겠습니다. 다중 개발자 git repo에서 작업하는 것은 이번이 처음이므로 정상적인 동작입니까? 이 문제를 해결하는 방법에 대한 의견이 있으십니까?
답변
당신이보고있는 커밋은 완벽하게 괜찮습니다. A가 pull효과적으로 실행 된 git fetch다음 git merge일반적으로를 실행할 때 병합이 발생합니다 git pull.
병합 대신 리베이스를 사용하는 대안이 가능하지만 일반적으로이를 피해야합니다. 리베이스를 사용하면 선형 기록을 유지할 수 있지만 원래 발생한 분기에 대한 모든 정보도 제거됩니다. 또한 현재 분기의 기록이 다시 작성되어 대상 분기 (귀하의 경우 원격)에 포함되지 않은 모든 커밋이 다시 작성됩니다. 재 작성된 커밋은 서로 다른 커밋이므로 다른 사람과 함께 개발할 때 많은 혼란을 야기 할 수 있습니다. 따라서 경험상 이미 푸시 된 커밋을 다시 작성 해서는 안됩니다 .
표시되는 커밋은 두 개 (또는 그 이상)의 분기를 결합하기위한 것입니다. 다른 작업을 수행하지 않고 여러 분기를 병합하는 커밋을 갖는 것은 완벽합니다. 사실 히스토리를 볼 때 분기를 결합하는 병합 커밋이있을 때 매우 명확합니다. 리베이스와 비교하여 병합을 사용하면 공존 한 실제 분기를 포함하여 개발 된 원래의 역사 를 효과적으로 볼 수 있습니다 .
짧게 말하면, 예, 커밋을 병합하는 것은 완벽하며 걱정할 필요가 없습니다.
답변
이 답변은 나의 이해, 다이어그램 및 결론이 잘못되어 수정되었습니다.
git pullgit이 병합되기 때문에 병합 커밋이 발생합니다. 병합 대신 리베이스를 사용하도록 분기를 설정하여 변경할 수 있습니다. 풀에서 병합하는 대신 rebase를 사용하면 공유 저장소에 더 선형적인 기록이 제공됩니다. 반면에 병합 커밋은 브랜치에서의 병렬 개발 노력을 보여줍니다.
예를 들어 두 사람이 같은 지점에서 일하고 있습니다. 분기는 다음과 같이 시작합니다.
...->C1
첫 번째 사람이 작업을 마치고 지점으로 이동합니다.
...->C1->C2
두 번째 사람이 작업을 마치고 푸시를 원하지만 업데이트가 필요하기 때문에 할 수 없습니다. 두 번째 사람의 로컬 저장소는 다음과 같습니다.
...->C1->C3
풀이 병합으로 설정되면 두 번째 사람 저장소는 다음과 같습니다.
...->C1->C3->M1
\ /
->C2->
M1은 병합 커밋입니다. 이 새로운 브랜치 기록은 리포지토리로 푸시됩니다. 대신 풀이 로컬 리포지토리를 리베이스하도록 설정되면 다음과 같습니다.
...->C1->C2->C3
병합 커밋이 없습니다. 역사는 더 선형 적으로 만들어졌습니다.
두 가지 선택 모두 지점의 역사를 반영합니다. git을 사용하면 선호하는 히스토리를 선택할 수 있습니다.
실제로 rebase가 원격 브랜치에 문제를 일으킬 수있는 곳이 있습니다. 이것은 그러한 경우 중 하나가 아닙니다. 우리는 이미 복잡한 브랜치 히스토리를 단순화하고 공유 저장소와 관련된 히스토리 버전을 보여주기 때문에 리베이스를 사용하는 것을 선호합니다.
branch.autosetuprebase = always를 설정하여 git이 자동으로 원격 분기를 master 대신 rebase로 설정하도록 할 수 있습니다.
git config --global branch.autosetuprebase always
이 설정은 git이 각 원격 분기에 대한 구성 설정을 자동으로 생성하도록합니다.
branch.<branchname>.rebase=true
이미 설정된 원격 브랜치에 대해 직접 설정할 수 있습니다.
git config branch.<branchname>.rebase true
이전 진술에 대해 질문하고 추구해 주신 @LaurensHolst에게 감사드립니다. 나는 확실히 git이 pull and merge 커밋과 함께 작동하는 방법에 대해 더 많이 배웠다.
병합 커밋에 대한 자세한 내용은 ProGit-Book 의 프로젝트 에 기여를 참조하세요 . 개인 작은 팀 섹션 쇼 커밋을 병합합니다.
답변
넌 할 수있어:
git pull --rebase
그러나 이렇게하면 항상 공동 작업자 위에 변경 사항이 적용됩니다. 그러나 오염 된 병합 메시지는받지 않습니다.
답변
실제로 이것에 대한 훨씬 더 간단한 대답이 있습니다. 개발자 B가 커밋하기 전에 끌어 오기만하면됩니다. 이렇게하면 원격 저장소의 커밋 기록과 병합하려고하는 로컬 커밋에서 로컬 저장소에 만든 기록으로 인해 발생하는 병합 커밋을 방지 할 수 있습니다. pull을 할 때 ‘changes will be overwrite’줄을 따라 무언가를 말하는 메시지를 받으면 두 사람이 같은 파일을 터치했음을 의미하므로 다음과 같이하십시오.
git stash
git pull
git stash pop
그런 다음 병합 충돌이 있으면 해결할 수 있습니다.
답변
git pull을 수행하면 “Merge branch”메시지가 삽입됩니다. git pull을 수행하여 원격 분기를 로컬 분기에 병합했습니다.
git pull을 수행하고 충돌이 발생하면 git 로그에 충돌을 해결 한 사용자가 보낸 것으로 충돌하는 파일에 대한 업데이트가 표시됩니다. 충돌을 수정 한 사람이 파일을 다시 커밋하기 때문이라고 생각합니다.
내가 아는 한 그것이 git이 작동하는 방식이며 그 주위에는 방법이 없습니다.
Rebasing은 git 히스토리를 날려 버릴 것이므로 언제 병합이 발생했는지 알 수 없습니다.