1. 개요
- 팀 프로젝트를 최소 3회 이상 해오면서, git 관련해서 기본적인 것들은 많이 해봤다고 자부했다.
- 최근 사야매 프로젝트를 시작하면서, 처음으로 커밋 내역, 이슈 내역 등을 꼼꼼하게 관리하기로 룰을 짜고 작업을 하고 있다.
- 그런데, 필자가 생각보다 git을 자유자재로 사용하지 못하고 있음을 느꼈다.
- 특히, 브랜치를 이동하면서 하는 작업에서 아직 많이 미숙하다고 느꼈다.
- 그래서 사야매 프로젝트를 하면서 git 관련해서도 좀 더 성숙해지고자 한다.
- 종종 이렇게 git 관련된 글들을 적을 일이 많을 것 같다.
- 참고로 작성되는 글들은 특정한 목차를 가지진 않다.
- TIL 느낌으로 적을 예정이고, 경험적으로 잘 몰랐던 것들, 새로 알게 된 내용, 알고 있었지만 다시 정리한 내용을 중심으로 작성할 예정이다.
2. git branch를 이용하며 겪은 시행착오
- github docs에서 설명하기로 branch는 git에서 커밋을 넘나드는 하나의 포인터라고 한다.(출처)
- 개인적으로 좀 더 비유를 해보자면, 브랜치를 생성하는 행위는 레포지토리에 하나의 버전을 새로 생성하는 행위랑 같다고 느낀다.
- branch는 git을 이용해 프로젝트의 버전/형상을 관리하는 데 정말 유용한 기능이고, 기본적인 개념이라고 생각한다.
- 아래는 branch를 이용하면서 겪은 시행착오와 이의 해결방법에 대한 소개다.
1) 체크아웃한 브랜치는 체크아웃한 기점의 형상을 기억한다.
- 정말 기본적인 내용인데, 다음과 같은 시행착오를 어처구니없이 겪었다.
1. dev 브랜치에서 checkout한 feat/team 브랜치에서 remote의 feat/team으로 커밋을 푸시했다.
2. feat/team에서 dev로 pr을 날렸다.
3. 로컬로 돌아와서, CRLF 개선을 위해, issue/line 브랜치를 생성했다.
- 이 때, checkout -b 명령어를 이용했는데, 그만 dev 브랜치가 아니라 feat/team 브랜치에서 이를 실행했다.
4. issue/line에서 작업을 하고 마찬가지로 remote의 issue/line으로 커밋을 푸시했다.
5. issue/line에서 dev로 pr을 날렸다.
- 이 작업에서 기대했던 결과물과 실제 결과물은 다음과 같았다.
기대 결과물
dev <- feat/team PR file changes
- c
- b
- a
dev <- issue/line PR file changes
- d
- c
- b
- a
실제 결과물
dev <- feat/team PR file changes
- c
- b
- a
dev <- issue/line PR file changes
- d
- c
- b
- a
- 요컨대, feat/team에서 체크아웃을 했기 때문에, feat/team의 형상을 issue/line이 담아버린 것이다.
- feat/team의 커밋내역은 아직 dev에서 merge되지 않은 상태였기 때문에, issue/line의 dev PR에도 feat/team의 PR 내역인 a,b,c가 중복해서 올라갔다.
- feat/team의 PR을 먼저 승낙한다면 문제가 안생기겠지만, feat/team을 뒤에 승낙한다면, 문제가 발생할 수도 있을 거란 생각이 든다.
- 이 시행착오를 통해 배운 점은 다음과 같다.
새 브랜치를 생성할 때에는 어느 브랜치를 기점으로 만들어야 하는지 잘 신경써야 한다. 브랜치는 그것을 생성한 베이스 브랜치의 형상을 기준으로 생성되기 때문이다.
- 작업을 할 때 다음 순서에 익숙해질 필요가 있다는 생각도 들었다.
일반적으로 main-dev-feature의 구조로 브랜치 전략을 많이들 사용한다고 한다.
이를 기반으로 로컬에서 브랜치를 사용하는 루틴을 생각해볼 때,
1. dev에서 작업을 한다.
2. 작업이 완료되면, remote에 push할 브랜치로 checkout -b 한다.
3. 해당 브랜치에서 remote 브랜치로 push한다.
4. 다시 dev로 체크아웃을 하고, 로컬 브랜치는 삭제한다.
(혹시 다시 브랜치 내역을 살려야한다고 해도, remote에 저장되어 있기 때문에 문제될 건 없다.)
번외) checkout 시 넘어가는 파일 여부
- main 브랜치와 dev 브랜치가 있고, dev 브랜치에서 다음 두 상황이 있다고 했을 때, 각 상황에서 main에 넘어가는 파일은 다음과 같다.
> 상황1: dev에서 작업을 하고 커밋을 했다.
- 결과: main으로는 아무것도 넘어가지 않는다.
> 상황2: dev에서 작업만 하고 커밋은 하지 않았다.
- 결과: main으로 아무것도 넘어가지 않는다.
> 상황3: dev에서 다른 로컬 브랜치 A를 rebase 받고 작업을 했다. 커밋은 하지 않았다. (main은 로컬 브랜치 A와 관련이 없다.)
- 결과: 로컬 브랜치 A 내역은 main으로 가지 않고, dev에서 작업한 것만 넘어간다.
'TIL' 카테고리의 다른 글
git branch 잘 이용하기 | 2. 깔끔한 커밋 관리를 위한 rebase (1) | 2023.06.14 |
---|---|
CRLF/LF 이슈 (0) | 2023.06.09 |
eslint replace ... 에러 (0) | 2023.05.23 |
class 접근 제한자와 ()=> ({}) 용법 (0) | 2023.02.07 |
Redis X nestJS cache manager (0) | 2023.02.07 |