지난 시간에 브랜치에 대해서 알아봤는데 오늘은 브랜치를 생성하고 Github에 올리는 작업을 해보겠습니다. 그 후 브랜치를 사용할 때 많이 나오는 상황에 대한 두 가지 전략을 배우고, 병합과 충돌이라는 개념도 배워보겠습니다.
📖브랜치 전략(이름 규칙, git flow)
브랜치의 이름은 자유롭게 원하는 것으로 작성이 가능합니다. 하지만 협업을 진행하게 되면 통일성이 있는 게 좋습니다. 그래야 사람들이 알아보기 편하기 때문입니다. 회사나 팀에 따라 다양한 규칙을 정하고 작성하게 되는데 한 가지 예시만 보여드리고 넘어가겠습니다.
main 브랜치 : 자주 사용되지는 않고 최종적으로 배포하는 버전을 관리하는 브랜치. 해당 브랜치의 버전이 실제 배포되어 사용되는 버전입니다.
기능 개발 : 'feature/기능'. Dev 브랜치 밑에 있는 경우도 있습니다.
출시 준비 : 'release-버전'. 기능 개발이 끝나고 출시를 하기 위해서 사용하는 브랜치입니다.
긴급 수정 : 'hotfix-버전'. 급하게 해결할 필요가 있는 문제가 발생한 경우 사용하는 브랜치입니다.
이 외에도 다양한 브랜치 전략을 사용하고 있으니 찾아보셔도 좋을 것 같습니다.
🍯tip! 저번 시간에 사용했던 git 명령어들이 기억이 안 나는 경우가 있습니다. 여러 방법 중 git 명령어 이용하기에 대해 알려드리겠습니다. 단순하게 `git`을 입력하는 것 입니다. 그렇게 되면 배우지 않은 명령어부터 배웠던 명령어까지 나오게 됩니다. 여기서 더 나아가 `git help Git명령어`를 사용하면 웹 페이지가 나와 더 자세한 내용을 볼 수 있습니다.git 명령어를 사용하면 나오는 명령어 목록
📖브랜치 실습
임시로 만들었던 브랜치들을 모두 삭제하고 이름 규칙에 따라 새로운 브랜치를 만들어서 실습을 진행하겠습니다. 브랜치를 만들고 feature/login브랜치에서 newTest 파일의 내용을 살짝 바꿔보겠습니다.
feature/login 브랜치에서 newTest 파일 내용 수정 후 feature/profile 브랜치로 이동
이건 뭐 아무렇지 않게 진행할 수 있습니다. 이 상태에서 commit 하지 않고 feature/profile브랜치로 이동해 보겠습니다.
잠깐! 뭔가가 이상합니다. feature/login 브랜치에서 변경했던 내용이 그대로 왔습니다. 검색해 보니 경고 문구를 띄워주는 경우도 있습니다. 경고 문구에는 '현재 로컬에 변경 사항이 있다. 브랜치를 바꾸기 전에 커밋 또는 stash를 해라'라고 나옵니다. 왜 경고 문구가 안 뜨는지는 잘 모르겠습니다.
경고 문구에 대한 개인적인 생각 이동하는 두 브랜치 모두 main을 기준으로 생성한 뒤 커밋이 하나도 없어 같은 브랜치도 인식했다.
경고 문구를 알았으니 이제 다시 변경했던 feature/login으로 돌아가 커밋해 보고 차이점을 보겠습니다.
feature/login 브랜치에서 변경 사항을 커밋하고 feature/profile과 비교
커밋하고 나서 보니까 변경사항이 다른 것을 볼 수 있습니다. 자 이제 변경된 feature/login 브랜치를 Github에도 올려보겠습니다.
`git push origin feature/login` 명령어를 통해 올릴 수 있습니다. 원격 브랜치의 상태도 바뀐 것을 볼 수 있습니다. 이제 Github에도 진짜로 바뀌었나 확인해 보겠습니다.
Github에서도 성공적으로 feature/login 브랜치가 만들어지고 커밋 사항까지 잘 적용된 것을 확인할 수 있습니다. 그런데 노란색 박스로 뭔가 하라고 하는데 해당 부분은 아래 병합 & 충돌 파트에서 설명과 함께 진행하도록 하겠습니다.
📖병합(merge) & 충돌(conflict)
병합의 종류는 크게 두 가지가 있습니다. fast forward 방식과 3-way 방식입니다. 병합을 진행하기 전 알아보고 넘어가겠습니다. 병합은 두 브랜치를 합치는 것을 말하기에 브랜치 A와 브랜치 A에서 생성된 브랜치 B가 있다고 하겠습니다.
📄fast forward
병합 전
병합 후
fast forward는 브랜치 B에서만 커밋이 일어난 경우입니다. 하나의 브랜치에서만 커밋이 발생한 경우에는 병합이 문제없이 진행됩니다. 다르게 이해해 보면 브랜치 B보고 '너 이제 브랜치 A해라'라고 하는 것과 같습니다. 브랜치 B는 만들었지만 크게 의미가 없어지는 것입니다. 이런 경우는 혼자 개발할 때 많이 발생할 수 있고, 협업을 하는 경우에는 드물게 발생할 것이라고 생각합니다.
📄3-way
병합 전병합 후
3-way의 경우 브랜치 B에서도 커밋이 있고, 브랜치 A에서도 커밋이 있는 경우입니다. fast forward와 달리 두 브랜치 모두 커밋이 존재하기 때문에 두 브랜치에서 변경 사항을 하나로 합쳐(병합, merge) 새로운 하나의 커밋을 생성하게 됩니다.
이제 병합에 대한 실습을 진행하는데 fast forward의 경우 위의 실습을 이어서 진행하는 것으로 대체하겠습니다. 시간이 지나 Github에 접속했다면 위에서 봤던 노란 박스가 없어져 있을 수 있는데 당황하지 않고 찾으면 됩니다.
노란 박스가 사라졌을 때 찾는 방법
이 작업은 pull request라고 부릅니다. 풀 리퀘스트를 진행하면 메시지를 작성하도록 되어있는데 해당 메시지에는 변경 사항에 대해 적는 곳입니다. 다른 사람도 읽을 수 있기 때문에 정리해서 올리는 습관이 중요합니다.
🍯tip! 풀 리퀘스트 메시지의 경우 markdown이 적용되기 때문에 활용하면 더 깔끔하게 정보를 정리할 수 있습니다.
pull request 메시지 작성 with markdown
메시지를 작성하고 풀 리퀘스트를 생성하게 되면 Github에서 병합을 할 수 있는지 알려줍니다.
pull request에 문제가 없다
기분 좋은 녹색으로 문제없이 가능하다고 알려줍니다. 풀 리퀘스트를 성공하면 이제 병합된 브랜치는 필요가 없어졌습니다. 삭제해야 됩니다. 그런데 Github는 삭제까지 버튼으로 가능하게 도와줍니다.
브랜치 삭제까지 간편하게
깔끔하게 삭제하고 main 브랜치를 보면 잘 병합되어 커밋 사항들이 반영되어 있는 것을 확인할 수 있습니다.
잘 병합된 화면
Github는 정리가 끝났는데 로컬 환경이 아직 정리가 안 됐습니다. 로컬 환경까지 깔끔하게 정리해 보도록 하겠습니다.
그런데 문제가 발생했습니다. 로컬 환경에는 Github에서 이미 다 사라진 정보들이 남아 있습니다. 여기서 필요한 것은 동기화 작업입니다. 우선 `git fetch -p` 명령어를 통해 원격저장소의 브랜치 목록을 동기화합니다.
명령어를 통한 원격 브랜치 동기화
이제 필요 없어진 로컬 브랜치를 삭제합니다.
필요없어진 브랜치 삭제
병합이 안 됐다는 메시지가 뜨면서 삭제가 되지 않습니다. 분명히 병합을 끝내고 왔는데 무슨 문제일까요? 로그를 보겠습니다. pull을 안 받았습니다. pull을 받아 main 브랜치를 동기화시켜줍니다.
pull 받아 main 브랜치 동기화 시키기
이제 다시 feature/login 브랜치를 삭제하겠습니다.
필요없어진 브랜치 삭제하기
성공적으로 브랜치까지 삭제된 모습입니다.
다음으로 3-way에서 충돌이 발생하고 해결하는 과정을 보겠습니다. 모든 불필요한 브랜치들을 삭제하고, feature/1 브랜치를 만들어줍니다. 협업 과정을 가정하기 위해서 만들었던 폴더도 열어 이번에는 feature/2 브랜치를 만들어줍니다. 강제로 충돌을 발생시키기 위해서 두 폴더에서 newTest의 내용을 각각 feature1과 feature2로 바꾸겠습니다. 그다음은 위 실습과 동일하게 커밋하고 push한 후 Github로 이동하겠습니다. feature1을 먼저 풀 리퀘스트하면 아무런 문제 없이 병합이 됩니다. 이제 feature2를 병합해보려고 하는데 문제가 생깁니다. 충돌이 발생했습니다.
경고문이 뜬 pull request 메시지 작성 화면
우선 풀 리퀘스트를 생성하고, Github가 알려주는 방식으로 충돌을 해결해 보겠습니다.
충돌을 해결하라는 Github
충돌을 해결하기 위해서 들어가 보면 어디서 충돌이 발생했는지 알려줍니다. '<<<<<< feature/2' 에서 '=======' 전까지 feature/2에 작성된 부분이고, '=======' 이후부터 '>>>>>> main'까지는 main에 작성된 부분입니다. 이 중에서 남기고 싶은 부분만 남겨두고 우측 상단에 'Mark as resolved'라는 버튼을 누르면 풀 리퀘스트를 안전하게 마무리할 수 있습니다.
충돌이 발생한 부분을 알려주고 해결하는 화면
여기서 끝나는 것이 아니라 fast forward 실습과 같이 로컬 환경도 정리를 다 해야 마무리가 됩니다. 최종 커밋 기록들을 보여주는 것으로 마무리하겠습니다.
📄오늘 처음 사용한 명령어 정리
git : 까먹었던 명령어를 간단하게 찾아볼 수 있는 명령어
git push origin 브랜치이름 : 브랜치의 변경사항을 Github에 올리는 명령어
