- 로컬 develop 브랜치에 a 작성
- git add , git commit, git push 명령어로 원격 develop에 push
- git switch -c feature2 생성 후 a → a2로 수정 , B추가
- 원격 feature2 → develop pr날리고 merge
- git switch -c feature1 생성 후 a → a1로 수정, C추가 후 원격 feature1으로 push
- 원격 feature1 → develop pr날리고 merge but… 충돌! merge 비활성화상태
충돌 발생원인?
현재 feature1, feature2 모두 같은 파일을 수정했기 때문에 누구 걸 써야 될지 몰라서 충돌한 것
- 3 way merge: merge 할 땐, 각 브랜치의 마지막 커밋과 공통 조상 커밋을 비교합니다.
- base에 없던 내용: 이 경우 feature1, feature2가 다른 파일을 추가해도 충돌이 없습니다. develop의 마지막 커밋, feature1의 마지막 커밋이 다르지만, base에 원본이 없어서 둘 다 merge 해옵니다.
- base에 있던 내용인데 base ≠ develop ≠ feature1인경우 충돌이 발생합니다.
충돌 해결
- 충돌을 해결하기 위해선 먼저 로컬 feature1에서 git pull origin develop을 해야합니다. 이 때 base를 어디에 두냐에 따라 병합하는 모양이 달라집니다.
병합 방식
- 단순 merge : public 같이 쓰는 브랜치
- git switch main
- git pull shin
위에 설명한 3-way-merge 방식입니다. 원격에서만 사용할 저장소( 작업물을 합치는 develop, 배포에 사용할 main)의 경우 전체 브랜치의 병합과정을 추적할 수 있어야 하고 commit 번호가 달라지면 혼동이 생기기 때문에 해당 방식을 사용합니다.
로컬에서 테스트 결과
보면 각 브랜치의 마지막 커밋 번호 변경 없이 새로 병합된 커밋이 추가됩니다.
- rebase: 개인 작업 브랜치
- git switch shin ( shin 브랜치에서 rebase main을 해야 공통조상으로 부터 추가된 shin의 커밋들을 patch함)
- git rebase main( main 마지막 커밋으로 base를 옮김 )
- git switch main ( main으로 가서 )
- git merge shin ( main 마지막 커밋 뒤에 patch된 shin 커밋들을 추가)
base를 마지막 커밋으로 바꿔서 pull해오는 방식입니다. 개인이 작업할 때 사용할 브랜치(feature1, feature2..)에서 작업 히스토리를 깔끔하게 볼 수 있기에 해당방식을 사용합니다.
로컬에서 테스트 결과
공통 조상 이후의 shin 커밋들을 main 마지막 커밋 뒤에 붙이기
shin의 마지막 커밋에 충돌이 있어서 수정 → 원본 사라지고 새로운 번호로 커밋 생성 → main 뒤에 shin의 차이나는 커밋들이 합쳐지고 하나의 히스토리로 보임
- 우리는 개인 브랜치에선 rebase방식을 쓸 거라서 먼저 git switch develop 해줍니다.
- git pull origin develop으로 최신 개발 파일을 머지해옵니다.
- git rebase feature1을 입력해서 base를 feature1의 마지막 커밋으로 옮깁니다.
- 아까 충돌되는 부분이 그대로라면 위 오류가 뜨고 rebase가 되지 않습니다.
- vscode는 충돌난 부분을 파일로 보여주고 둘중 뭘 쓸지 고르라고 합니다. 아예 다른 내용을 작성해도됩니다. 이때 팀원과 어떤 코드를 남길 지 상의하면됩니다.
- 충돌난 내용을 수정 후 git add . → git merge develop 해줍니다. ( 아무작업 없을 땐 merge만)