[TIL / 25.03.25] 제목은 gitignore 트러블슈팅으로 하겠습니다,, 근데 이제 cherry-pick, rebase를 곁들인

정신 없이 고치고 문제 해석하느라 과정에선 스샷 없이 진행합니다..

 

1. 상황 설명

dev 브랜치 내에 각자의 디렉토리를 생성해두고 그 안에 각자 개인과제 풀이 프로젝트를 넣어야 하는 상황.

이에 따라서 디렉토리의 depth가 커져 DS_Store 파일도 그만큼 많아져서 gitignore를 최상위에서 한꺼번에 관리하자는 결론이 나왔음.

 

다만, 이 gitignore 작업을 내 개인 브랜치에서 할 게 아니라 dev 브랜치에 최신 사항 위에 바로 올리고 푸쉬했어야 했는데, 내 개인 브랜치에서 작업을 진행함.

 

뭔가 나 혼자 했다면 다시 지우고 dev 브랜치로 가서 다시 만들었을 것 같은데, 역시 깃과 깃헙에 유능한 팀원분의 지도 하에 문제 해결을 해보도록 했습니다.

 

2. 문제 해결

우선 해결 당시에는 정말 뇌가 너무 혼란스러워서 무슨 기술을 중간에 썼는지 키워드로만 기억하고 그 과정에 대한 근거들과 모든 흐름들이 자연스럽게 이해할 수가 없었기에,,, 해결해주신 분께 해당 상황에 대한 설명을 요청드림.

• sks 브랜치에서 dev에서 해야할 작업을 했음.(실수 발생)
• sks 브랜치에서 이미 작업된 내용이 있지만, 그냥 그 위에 dev에서 해야할 작업을 진행하고 커밋 (루트에 .gitignore 추가하는 작업) 
  • 이 커밋은 나중에 지울거임
• commit 되지 않은 변경사항 stash (dev 브랜치로 checkout 하기 위함임)
• dev 브랜치로 checkout
• sks의 head commit(루트에 .gitignore 추가했던 커밋)을 cherry-pick 해온 후 push
  • 이러면 dev 입장에선 그냥 .gitignore를 하나 추가한 깔끔한 상태
• 이제 난장판이 된 sks 브랜치를 정리하러 다시 sks로 체크아웃
• 아까 체리픽당한 그 커밋은 원래 dev에서 했어야함 (1번에서 실수한 거) -> hard reset으로 커밋 기록 제거
• 5번에서 기반이 되는 dev에 변경사항이 생겼으므로 rebase 진행 (sks의 커밋들을 dev 위로 쌓아올림)
• 3번에서 stash 했던거 복구 (stash apply)

일부 과정에선 이렇게 하는게 좋진 않은데.. 라고 하셨는데 일단 문제 해결과 내 견문이 넓어지니깐 무조건 오케이고,

궁금한 점

rebase 진행해서 sks의 커밋들을 dev 위로 쌓아올림.

내가 rebase를 잘 알지 못했어서 이참에 정의를 찾아보았다.

 

Rebase : 두 개의 공통 Base를 가진 Branch에서 한 Branch의 Base를 다른 Branch의 최신 커밋으로 branch의 base를 옮기는 작업. 용어 그대로 베이스를 다시 설정하는 작업.

 

이 경우 sks 브랜치에서 커밋된 사항들 몇개가 있었어도 그 시작점(베이스)을 dev의 최신 커밋으로 설정하는 작업을 했던 것임.

 

 

리베이스의 기능을 알고나니 왜 브랜치를 깔끔하게 만들어줄 수 있는지 조금이나마 이해가 된다. 이 부분은 실제로 경험해보고 찾아봐야 명확하게 이해할 수 있을듯.

---

reset도 hard, mixed, soft가 있고 그 외에 방금 상황에서 쓴 기능만 stash, hard reset, rebase, cherry-pick, checkout이 있다.

확실히 상황에 맞춰 기능들을 잘 조합해야하는데, 아직 경험이 많이 부족한 것 같고 브랜치도 잘 읽지 못하는 상황이라 경험이 필요하다.

 

내가 그들에게 어떠한 도움을 주고 있는가? 에는 솔직히 주고 있지 못해서 걸리는 부분이 많지만, 얻는 부분이 많다는 것에 감사하고 있다.

아 마스터반으로 옮기길 정말 잘했다. (사실 모두에게 벽느껴지고 있긴함 ㅋㅋ..)