git 연습 사이트로 rebase 공부하기 (merge는?)

우선 사이트는 이거다
 https://learngitbranching.js.org/?locale=ko
제목 뿐만 아니라 기초부터 전부 연습해볼 수 있다

---

저번에 일경험을 하면서 처음으로 브랜치를 꽤 많이 만들어봤다
전에는 똑같은 노트북으로만 개발을 하니까  dev, deploy, 종종 새로운 기능 테스트할 때
이 정도만 구분해도 큰 문제는 없었다
일경험에서는 이름브랜치 아래 각자의 브랜치를 만들었는데, 버그, 기능별로 브랜치를 만들었다
 
그리고 출근 안한 날 코드를 수정/추가하고 싶은데
깃허브에 제대로 올라와있지 않으면 곤란해
퇴근전 빠르게 푸시할 수 있도록ㅎㅎ
꼬이지 않게 이쁘게 하려고 신경을 썼다 
 
이때는 dev를 작업 브랜치에 merge해서 충돌 없앤 후 다시 dev에 merge를 하는 방식으로 했다
rebase는 main 바뀌었을 때 썼나..? 기억이 안난다
rebase, cherry-pick은 거의 사용한적이 없던것 같다

---

마침 x에서 "rebase" 가 핫한 토픽이 된것을 발견 
rebase를 해야 한다 굳이? 아니다 여러 의견들이 많이 보였다
보통 rebase를 main의 내용 즉 최신 내용을 기준으로 반영하고 싶을때 사용하는 걸로 알고있긴 했다
거기서 말하는 rebase의 이점은 "커밋 이력이 깔끔하다"는 것이었다
내가 merge하면서 느꼈던 게 히스토리가 더럽다는 거였는데!
 
그렇게 rebase를 당장 체험하기 위해
https://learngitbranching.js.org/?locale=ko
이 사이트에서 연습을 해봤다
 
그렇게 merge와 rebase의 차이점, 장단점을 찾아본 후 
결론은 일단은 그냥 merge 해야겠다 였다
물론 내가 어느 조직에 있었다면 그걸 따랐겠지만
각각을 적절한 상황에 쓰는 것이 좋겠다는 생각이 들었다
 
우선 나는 커밋이 main에 일렬로 이쁘게 되어있는 것이 좋다고 생각했는데
굳이 main에 자잘한 커밋 내역을 보여주지 않고,
'00기능이 추가'되었다 이정도만 보이는 것이 오히려 좋다는 이야기도 있었다
 
또 reabase는 충돌이 났을 경우 더욱 복잡해진다
main이 a -> b-> c 이미 진행되고 있는 상황에서 
내 작업브랜치가 a-> x -> y -> z 일 경우
main에 변경된 내용이 x와 충돌이 났을 때,
y, z 에도 영향을 줘 더욱 복잡해질 수 있다
 
그래도 rebase가 내가 순서대로 뭘 했는지 보기 좋은건 맞는것 같다
 
결론은 뭘 쓰던지 간에
복잡해지지 않도록 사전에 방지하고 해결하는것이 최고 인듯 하다