Merge하기
1. 새 브랜치에서 파일 내용 수정 후 커밋
2. main 브랜치로 이동
main 브랜치는 앞서 커밋된 내용이 아닌 원본 상태
3. feat/new-branch를 main으로 merge
Merge conflict
new-branch와 main에서 같은 위치의 내용을 수정한 뒤 merge 해 충돌을 발생시키고 해결해보자.
feat/new-branch 내용 변경 후 커밋
main 내용 변경 후 커밋 후 merge => conflict 발생
해결
conflict된 내용을 수동으로 수정하고 add하면 all conflict가 fixed된 것을 확인할 수 있다.
merge는 조심스러워서 pr을 날려서 주로 병합했었는데 연습 레포지토리로 걱정없이 궁금한 내용을 커밋하고 지우고 머지하다보니 자신감이 붙는 것 같다.
💡브랜치를 포인터라고 생각하자
브랜치 'new'에서 새로운 커밋을 했을 때 브랜치 'new'은 새로운 커밋을 가리키는 포인터이고, 브랜치 'old'는 과거 커밋을 가리키는 포인터이다.
오픈소스 기여하기
⇒ fork로 복제해와서 자유롭게 커밋 푸시 후 merge해달라 요청
1. fork 생성
오른쪽 상단 fork 버튼에서 Create a new fork를 클릭하고
fork를 생성한다.
내 레포지토리에 오픈소스가 fork된 것을 확인할 수 있다.
2. 오픈소스 수정
3. 원본저장소에 병합 요청
내가 fork한 원본 veloper:master보다 2 commits을 더 했다고 쓰여있다. Contribute를 클릭해 Open pull request를 누른다.
Pull Request 템플릿 / Contribution Guideline에 따라 작성한 PR을 날리면 관리자가 해당 내용을 확인하고 merge allow를 결정한다.
기타. upstream 저장소에서 변경 내역 반영하기
Upstream 저장소로부터 fetch(새로고침)한다.
$ git fetch upstream로컬 저장소의 master 브랜치로 이동 후 merge한다.
$ git checkout master
$ git merge upstream/master자신의 원격 저장소인 origin에 반영하려면 git push를 수행한다.
$ git push💡upstream과 origin (모두 remote 저장소)
upstream : fork한 원본 저장소
origin : 내 레포지토리에 존재하는 fork해온 저장소
브랜치 vs 포크
브랜치는 하나의 원본저장소에서 분기를 나누는 개념. 하나의 원본 저장소에서 코드 커밋 이력을 편하게 볼 수 있지만 사람이 많아질수록 관리가 힘들다.
포크는 여러 원격저장소를 만들어 분기를 나누는 개념. 원본 저장소가 있기 때문에 코드를 부담없이 수정할 수 있다. 원본 저장소 이력을 보려면 따로 주소를 추가해야 한다는 단점이 있다.
팀 단위에서는 브랜치를 주로 사용한다.
브랜치 관리
작업 중인 브랜치
feat/기능이름 : 보통 한 사람이 개발하는 기능
fix/버그이름
hotfix/급한버그
직접 커밋은 위 브랜치에서만 해야 한다.
작업이 완료된 브랜치
dev 또는 main
위 브랜치에서는 머지만 한다.
