git에 대해서 어느정도 기본은 사용한다고 생각했는데,
역시나 자만은 금물
부족한 부분이 참 많다.
개인 프로젝트나 일반 작은 협업시에는 문제가 없었나 싶은데, , , 내가 지금까지 계속 이렇게 해왔던 것 같은데
그때는 지금처럼 VSC 사용 + command 사용을 하지는 않았고, git bash만 사용했어서 문제가 없었을지도,,
진짜 이유를 몰랐을 때는 막막하고, 아진짜 왜이러지 싶었는데
원인을 알고 차근차근 생각해보면 다
일맥상통 | 유저 에러
그리고 오류 트리거 하고 나서 느낀 건데,
메모나 기록이 중요한것은 물론,
chatGPT에 의존하는 것이 아닌, 확실히 검색을 해야 된다는 것을 느꼈고
어떠한 문제가 생겼을때
1. 이 문제가 왜 생겼지에서
2. 어떤 문제가 현재 발생중인지
3. 그러면 그 문제에서 어떤 동작을 하고 있는지
4. 그 동작을 왜할까? 생각을 하면서 해당 git에 대한 구조를 살짝 생각해 봤으면 더 좋았을 것 같다는 생각이 들었다.
서론
협업을 하면 브랜치를 생성하고, PR을 날리면서 서로 review를 하면서 진행한다.
브랜치는 아래와 같이 생성하고, 이동을 할 수 있다,.
# 브랜치 생성
git branch {브랜치명}
# 브랜치 이동
git checkout/(or 요즘은 switch) {브랜치명}
코드를 작성하고 새로 만든 브랜치에 Push하는 방법은
git add .
git commit -m "{커밋메시지}"
git push origin {브랜치명}
위와 같이 진행하고, 하나의 테스크가 끝났다면, PR을 생성하고 날려서 팀원들에게 코드 리뷰와 확인을 받는다.
문제가 없으면 main으로 merge하면 된다.
그리고 사용한 브랜치는 삭제해준다.
git branch -d {브랜치명}
그리고 코드 동기화는 git pull을 해주면 된다.
문제 발생
그리고 이런 저런 작업을 하다가 PR을 하려고 하는데,
아래와 같이 내 온전한 브랜치에 다른 사람들의 커밋도 존재한다.
그래서 이런 부분에서 왜 이렇게 되지? 하다가
팀원분이 branch rebase에 대해서 알려주셨다.
rebase는 merge 와는 다르게, 브랜치를 합치는 방법은 동일하지만, 다시 세팅하는 거라고 이해하면 된다고 한다. 그래서 몇몇개는 rebase로 문제를 해결했지만,
commit 하나하나씩 처리를 해주어야 하는 부분에서 시간을 너무 소요했던 것 같다.
그러는 도중에 실수도 있어서, 변경한 부분을 변경하지 않도록 해서 문제가 발생한 부분도 있었다.
문제 인식
그러면 왜 이렇게 됐는가?
분명히 내 문제일터인데, 발생하는 문제사항은
PR을 날려서 main에 merge하려고 하면, 다른 사람들의 commit 들이 보인다.
- commit 은 문제 없이 진행됨
여기서 확인해볼 수 있던거는, 나는 main에서 분기를 했다고 생각하지만,
local 의 main 브랜치에서 분기를 했다는 점이 문제였다..
즉, 브랜치 생성할 때의 문제였다.
원하는 브랜치에서 분기를 딸때, 해당 브랜치에서 git branch {branch_name}을 작성해주면 된다.
그러나 내 local에 있는 main이 아니라, remote에 있는 main에서 새로 브랜치를 따서 작업을 해주어야 했다.
- 그래서! 내가 이전에는 문제가 크게 없었나 싶고 (이전에는 git bash, git GUI를 사용해서 했으니,, 현재는 command와 VSC를 보고 했으니)
- 내가 git에서 local과 remote와 그 중간 사이에 하나가 더 있다는 개념은 알고 있었는데, 그것을 응용해서 생각해봐야 문제점을 빠르게 파악할 수 있었을듯하다.
아래와 같이 remote main에서 진행해야 한다.
보통의 경우에는 origin/main 으로 해준다.
그래서 git checkout origin/main으로 체크아웃한 후, 거기서 새로운 브랜치를 만들고 switch를 해주니
main에 commit 한 부분에 대해 섞이지가 않았다.
git checkout {remote 설정 이름}/main
git checkout -b {브랜치명}
git add .
git commit
git push origin {브랜치명}
아래는 머지된 후, 단계인데
git branch -D 브랜치명 : 이 부분은 local 브랜치를 제거하는 것
git push origin :브랜치명 : 이 부분은 local에서 브랜치를 제거했으니, 그것을 원격 브랜치에 반영한다는 것
<merge된 후 >
git checkout main
git branch -D {브랜치명}
git push origin :{브랜치명}
git pull origin main
git push origin main
이런 식으로 해주면 된다...
이 문제는 내가 개념을 알고는 있었고,
그리고 문제에 대해서 조금만 더 생각해보고 분석해봤으면 나 스스로가 판단하고 이유를 찾을 수 있었던 문젠가 싶다.
내가 가지고 있는 개념적 지식들을 실무적으로, 이를 적용해서 사용하기에 대한 방법을 배우는 중인 것 같다.
그 과정이 재미있긴 한데, 아직 많이 미숙한 것 같긴하다.
다음 이러한 기회가 있으면, 이번에 얻은 교훈을 적용해볼 것 같다!
TMI : 나 혼자 과대생각일 수 있지만, 팀 리더가 내가 git에 헤매는 것을 보고 다음 테스크를 git을 줘서 더 공부하라는 큰 그림을 본 것일까.,? (상황적으로도 맞았던것 같기도 하다.)
참고
- https://jeeumu.tistory.com/240
'공부 > 개발' 카테고리의 다른 글
클린 코드 vs 소프트웨어 설계 철학 (0) | 2025.04.02 |
---|---|
[Mac] 맥북(mac)에 홈브류(Homebrew) 설치하기 (0) | 2025.03.07 |
[Git] 브런치 삭제 (0) | 2023.06.01 |
Flutter Design Pattern (0) | 2023.03.09 |
[NLP] 식물 아닌 모델 관찰일지 (0) | 2022.07.26 |