안녕하세요. 꼬동입니다.
오늘은 제가 업무상 필요했던 Git 지식을 몇 가지 정리해보려고 합니다.
정말 이 놈의 Git 때문에 식겁했던 적이 두 번 정도 있었는데.. 얼마나 죄송했는지
지나간 일이지만, 다시는 이런 일을 !! 벌이지 않기 위해서 !!! 제 블로그에 글을 정리해보려 합니다.
참고로, 본 글의 제목에 with Fork라는 글이 더 붙었는데, 쟤들은 git에서 제공하는 clone과 같은 fork를 뜻 하는게 아니고, GUI 툴인 Fork를 말하는 겁니다.
Fork - a fast and friendly git client for Mac and Windows
Fork - a fast and friendly git client for Mac and Windows
fork.dev
원래라면 GitHub Desktop이라는 GUI를 썼는데, 추천 받아서 Fork 써봤는데, 너무 좋더라고요. ^^7
추천해주셔서 감사합니다. ^^7
어찌됐건 이 Fork 라는 친구와 함께 제가 깨달은 Git 지식을 같이 알아봅시다.
Git PR Conflict 발생 시 행동
Git PR을 올렸다고 칩시다.
충돌이 안난다면, 오예 축하드립니다. 머리 아픈 일이 하나 줄었군요. 어서 다른 일을 하러가세요.
충돌이 난다면, 끙... 당신은 머리 아픈 일이 하나 더 생겼습니다.
예시가 필요할거 같기에, 일부러 충돌을 내는 파일과 브랜치를 만들어봅시다.
// master branch
첫 번째 커밋
두 번째 커밋 // <-- 제가 기능을 만들기 위해 branch를 만든 순간
세 번째 커밋 // <-- 제가 작업 중에 누가 Push를 했네요 !
// fourth branch
첫 번째 커밋
두 번째 커밋
네 번째 커밋 // <-- 제가 기능을 만들었습니다.
위와 같은 상황에서 제가 fourth branch를 master branch에 밀어넣으면 어떻게 될까용 ?
아마 충돌이 나겠죠 !
아래와 같이 말이죠.
뭐 충돌은 해결할 수 있기에, PR을 올리고 머지를 한다고 칩시다.
성공적으로 해결을 했다고 칩시다.
그 과정은 중요하지 않으니까요.
근데 해결을 하고 오니 한가지 과정이 더 생겼습니다.
뭘까요 ?
Merge branch 'master' into hotfix/fourth <== 이 친구입니다.
뭐 사실 요게 기능적으로 문제가 있진 않습니다.
Merge 잘 됐으니까요.
하지만, 대한민국 사람들 강박의 민족 아닙니까. 좀 예쁘게 Git을 관리하고 싶다면, 저 merge하는게 너무 꼴 보기 싫을 수 있습니다.
그렇기에 저희는 rebase라는 방법을 통해서 Git Tree를 이쁘게 만들어 보려합니다.
다시 아래와 같은 상황으로 돌아간다고 합시다.
만약, 저희가 hotfix/fourth를 master의 세 번째 커밋 후에 commit을 남긴다고 했을 때, master의 리프 커밋의 자식 커밋으로 나아가겠죠?
두 번째 라인의 자식이 아니고, 세 번째 커밋의 자식이 되는거니 base가 바뀐다 ~ 라고 이해하시면 되는데,
그렇기 때문에 rebase라고 불리는 거 같습니다. (제 뇌내망상입니당)
그럼 한 번 도전해보죠.
hotfix/fourth라는 branch에서 (checkout 한 상황) master를 우클릭 해봅시다.
중간에 Rebase 'hotfix/fourth' to Here 보이시죠. (Interactively는 뭔지 모르겠습니다. 아시는 분 댓글 달아주세요 ^^7)
위에서 말했다 시피 현재 branch의 base를 요기로 rebase하겠다. 라고 이해하시면 될 거 같습니다.
한 번 눌러보도록 하죠.
무지성 Submit ㄱㄱ
바로 등에 식은 땀 나게 만드는 Error 등장
천천히 읽어보면 Conflict 났으니 수정하세요 ~ 라는 의미입니다.
사실 맞죠. 어찌됐건 코드 자체는 충돌나는 코드를 서로 합치려고 했으니까요.
되도록이면 Fork로는 conflict 해결하지 않는 것을 추천드립니다.
직접 코드를 보면서 충돌 해결하는 것이 여러분들의 미래에도 좋을거에요.
vscode 켜보고 확인해보면,
아항 해결하고 다시 돌아가봅시다.
커밋하고 돌아가보면 ?
이 상태에서 PR을 올리고 와보겠습니다. 당근, 충돌은 없겠졍
어떤가요.
훨씬 이쁘지 않나요.
뭐 물론 결론만 따진다면, 여러분들의 코드는 역할을 똑같이 할 것입니다만, 이런게 쌓이고 쌓이면, 나중에 팀원들과 협력할 때 충분히 Git Tree의 가독성을 책임지는 좋은 습관이 될 수 있을 것입니다.
또한, 코드를 리뷰하는 팀원들 입장에서도 더 편해지는 장점도 있죠 !
단, 이를 무지성으로 남발한다면, 큰 문제가 있을 수 있습니다.
바로 다른 개발자가 이 변경사항을 사용하고 있는 경우인데요. 리베이스는 히스토리를 강제로 조작하기 때문에 다른 사람이 만약 이 히스토리를 보고 있다면 완전 깃 히스토리가 꼬이게 됩니다.
그렇기 때문에 이력을 조작하고 푸시를 하는 건 다른 개발자에게 위험한 행위여서 무조건 혼자 사용하는 브랜치에서만 하도록 합시다.
이 외에도 일하면서 겪은 다양한 Git 전략들이 있는데, 내일 출근을 해야하기 때문에, 오늘은 여기서 마무리 지어볼까 합니다.
아마 더 적을 수 있는 ... Git 전략들이 음..
- Git branch 전략
- Cherry Pick
- Commit
- 왜 CLI를 사용하는가
- CLI로 3-way 병합
요 정도가 있겠네요.
어휴 숙제가 늘었네 ^_^
그럼 다음에 위의 주제로 뵙도록 하겠습니다.
이상 실무 사례에서 필요한 Git 지식 with Fork 였습니다. ^_^