Git PullRequest에 대한 회고
PR 순서
- 작업할 Repo를 본인 git에 fork
같은 Repo에서 브랜치만 새로 따도 되나 팀 규칙을 따르는 것 추천 - fork된 본인 Repo를 clone
- 해당 repo에 브랜치 생성
병합할 부모 repo의 브랜치와 동일한 이름을 해도 되나, 사용하는 프로그램에 따라 귀찮아질 수도 있음 - 작업 시작
- 작업이 끝난후 commit -> push(본인 Repo)
- From = 본인 Repo의 브랜치
To = 부모 Repo의 브랜치 PullRequest 생성
PR 이슈
목표
PR을 보내기 전에 내가 보낼 브랜치가 master와 fast-forward 상태가 되도록 만든다.
fast-forward: 부모 브랜치와 컨플릭트없이 곧바로 머지가 될 수 있는 상태
- 원인 배경
- PR을 보낼 브랜치가 master보다 너무 옛날 상태
- GitHub에서 PR을 보냈더니 ‘merge conflict warning’이 페이지에서 보일 때 (같은 코드가 고쳐졌을때 자동으로 보임)
- 해결 방법
내 브랜치에 선 merge후 PR을 생성- 장점: 한번의 merge만으로 쉽게 해결할 수 있다.
- 단점: merge commit이 깔끔하지 않다. ( git에서 수정된 코드만 보고싶은데 컴플릭트해결 내용까지 봐야한다.)
리베이스후 PR 생성- master의 최신 상태를 base로 해서 내 브랜치를 rebase한다.
- rebase
내가 원하는 커밋을 base로 해서 내 브랜치가 마치 해당 커밋에서 딴 것처럼 기록을 조작하는 것이다.
내가 원래 딴 커밋에서부터 내가 목표하는 base 커밋까지 하나씩 옮겨가면서 새로 커밋하는 것이다.
히스토리를 조작하는 위험한 작업이므로 force옵션을 추가해 push한다. - 장점: merge commit 없이 깔끔한 커밋 히스토리를 만들 수 있다.
- 단점: 중간 코드 컨플릭트가 나면 그 사이에 있는 커밋들 모두에서 컨플릭트를 수정해줘야 할 수도 있다.
- 언제 어떤걸 써야할까?
- 상황: master에서 딴지 그리 오래되지 않은 브랜치, 작업량이 많지 않은 브랜치
해결: PR한번 보내본다. conflict warning이 보이면 아래 방법으로 - 상황: 내 브랜치에 커밋이 엄청 많다. 컨플릭트 날 가능성이 매우 높다.(기존 클래스들을 많이 수정했다)
해결:내 브랜치에 선 merge후 PR을 생성 - 상황: 내 브랜치 커밋이 그리 많지 않다. 컨플릭트 날 가능성이 매우 적다. (대부분 클래스들이 새로 만들어졋다)
해결:리베이스후 PR 생성
- 상황: master에서 딴지 그리 오래되지 않은 브랜치, 작업량이 많지 않은 브랜치