Git
Github PR(Pull Request) 생성 전 생각해보면 좋을 것들
이번 글은 PR(Pull Request)을 생성하기 전에 한 번쯤 체크해볼만한 내용을 정리해보고자 작성하게 되었습니다. 먼저 제가 생각하는 PR의 목적은 크게 두 가지입니다. [1] 이슈를 처리하기 위한 해결책을 담았다. [2] 코드 리뷰가 필요하다. 어떻게보면 당연한 이야기겠지만, 이 두 가지 목적을 담은 PR은 결국 PR을 올린 당사자가 이해하기 쉬운 것보다 PR을 봐야하는 팀원들 혹은 제 3자의 이해가 직관적이어야 효율적인 PR이라는 생각입니다. 물론 서비스마다, 팀마다 PR 템플릿도 다르고 브랜치 전략도 다를 수 있기 때문에 제가 생각해 본 체크 리스트가 적용되지 않을 수도 있습니다. 또한 많은 분들은 이미 실천하고 계실 수 있기 때문에 가볍게 봐주시면 좋을 것 같습니다. 1. PR Checkli..
Git
작업 중인 브랜치에 다른 히스토리를 반영해야 할 때: Merge? Rebase?
1. 상황 develop(main) 브랜치 하위에 특정 기능을 구현하기 위한 feature/A 브랜치를 생성했습니다. feature/A 브랜치에서 몇 차례 Commit을 진행하고 Push 해둔 상태에서 아직 develop 브랜치에 반영하지는 않았습니다. 한편, 제가 feature/A에서 작업을 하는동안 다른 팀원이 develop 브랜치 하위에 feature/B 브랜치를 생성해서 수정사항을 반영한 뒤, develop 브랜치에서 Merge를 했습니다. 이 때, 저는 다른 팀원이 작업한 develop 변경 사항을 포함하는 동시에 제가 변경한 부분도 반영해서 앞으로의 작업을 이어나가고 싶습니다. * 아래 그림을 두고 설명하자면 feature/a 브랜치의 10~40 부분을 그대로 유지하면서 main의 변경사항 중..
Git
[Git] Rebase는 왜 쓰나
0. 들어가면서 아래와 같은 상황을 보겠습니다. 처음 시작점을 기준으로 Master가 두 번의 Commit을 한 뒤, 'feat' 이라는 브랜치(branch)를 생성했습니다. 그리고 브랜치가 생긴 시점(Base)으로부터 feat 브랜치는 두 번의 commit을 더했고, master 역시 두 번의 커밋을 더 진행했습니다. 이 상황에서 master의 변경 사항을 feat 브랜치에 반영하고 싶습니다. 그러면 아래와 같이 병합(Merge)을 통해 master와 feat의 최신 Commit을 공통의 조상으로 하는 새로운 Commit을 생성할 수 있습니다. 그리고 feat 브랜치는 이제 새로 생성된 Commit의 위치로 이동하게 됩니다. 이를 3-Way Merge라고도 합니다. 한편, 이 상황에서 Rebase를 사..
