포트폴리오 / 협업 환경 구성 (4)

date/ 24.08.16.

 

브랜치 이름 규칙과 테스트

 

메인 브랜치

• 그대로 둔 상태로 복사를 해갑니다. 언제 복사를 할까요?
  • (보통 develop branch 라는 하위 브랜치를 따서) 기능 개발을 할 때: feature/login, feature/select-product 등 기능의 이름을 붙여서 이름을 작성합니다.
  • 출시 준비: release-1.3, release-1.4 등
  • 긴급 수정: hotfix-1.2.1 등으로 버그 수정 등 관리

 

 

이렇게 브랜치를 생성해보았습니다.

만약 생성한 브랜치를 삭제하고 싶다면 git branch -d (브랜치명) 명령어를 터미널에 입력하면 됩니다.

하지만 이렇게 브랜치를 생성하고, feature/login에서 내용을 수정한 후 feature/select-product로 넘어와도 login 브랜치에서 수정한 내용이 select-product에서도 보입니다. 허거덩~ 이거 왜 이러는 거죠?

 

 

 

커밋 해야 그때부터 브랜치!

 

깃이 어떻게 브랜치를 관리하는지 알아보겠습니다.

 

브랜치를 복사한다고 바로 병렬식으로 협업하여 활용할 수 있는 것은 아닙니다. 커밋을 하지 않으면 달라지는 것이 없습니다! 커밋을 한 시점부터 브랜치가 시작된다고 보면 됩니다. 즉, 커밋 이후 브랜치를 바꾸면 수정 사항이 반영되지 않은 이전의 모습 그대로인 것을 볼 수 있습니다. 왕신기~!

 

vscode 왼쪽 하단을 보면 내가 어느 브랜치에 있는지 알려주고 있습니다. 이걸 꼭 확인해야 합니다. 커밋은 롤백이 되지 않기 때문에, 잘못된 브랜치에서 커밋을 하면 그대로 끝...입니다. 야박하군요

 

 

원격 브랜치 실습

 

그럼 깃허브에서는 브랜치 사용을 어떻게 할까요?

 

• git branch -r: 원격 연결되어 있는 깃허브에 있는 브랜치를 확인하는 명령어
• git push (깃허브저장소별칭) (깃브랜치명): 깃에 만들어둔 브랜치를 원격 브랜치로 복제
  • ex) git push origin feature/login

 

 

Chapter 9. 깃 브랜치 전략

 

브랜치 전략 두 가지

 

깃 플로우라고도 부르는 깃 브랜치 전략은 크게 두 가지가 있습니다. fast-forward와 3-way가 그 두 가지이고, 꼭 둘 중 하나만을 취사선택해야 하는 것이 아니라 다양한 전략을 짜서 사용할 수 있습니다.

 

• fast-forward전략
  • A branch에서 B branch를 생성한 시점부터, A 브랜치에는 아무런 추가 구현을 하지 않고 B 브랜치에만 작업한 뒤 합치는 것
  • 그냥 A에 B가 붙으면 끝이겠죠?
• 3-way 전략
  • 일반적으로 가장 많이 사용하는 전략입니다.
  • A 브랜치에서 B 브랜치를 생성한 시점부터, 두 가지 브랜치에 모두 추가 구현을 하고 서로 비교하여 바뀐 것을 정리하여 합치는 전략

 

브랜치 전략에는 정답이 없습니다. 두 가지를 합쳐서 사용하기도 합니다.

 

 

Chapter 10. 병합과 충돌

 

Pull Request and Merge

 

일단 github의 branch setting에서 어떤 것을 보호할지 체크해서 설정을 바꿔줄 수 있습니다. 그 중 require approvals 옵션을 체크하면 결재자의 승인을 받아야 merge를 가능하게 할 수 있습니다.

 

 

Pull Request에 대해

 

기본적으로 어떤 기능을 구현하였는지, 이슈는 뭐가 있었는지 등 내용을 적어주는 것이 협업하기에 좋습니다. 리드미와 마찬가지로 markdown 형태로 작성이 가능하다는 점이 특징입니다.

 

pull request 버튼을 누르면 어떻게 될까요?

내가 작성한 내용과 요청사항을 띄워주고, 어떤 커밋이 포함되어 있는지 알려줍니다. 충돌이 없는 경우 'This branch has no conflicts with the base branch'라는 문장을 보여줍니다. 이럴 때는 자동으로 병합이 가능하므로 'merge pull request'를 누르면 끝이 납니다.

 

merge이후 남아 있는 브랜치는 지워주는 것이 좋습니다. 브랜치를 다시 살리고 머지를 푸는 것도 가능하니 너무 걱정하지 않아도 됩니다. 이후에는 커밋 이력을 한 번 확인해보세요.

 

 

저는 feature/login 브랜치를 master로 merge pull request 했습니다. 나름 PR 메세지도 써봤습니다.

 

 

 

커밋 히스토리를 확인해 보니 PR한 흔적이 고스란히 남아 있군요.

 

 

merge에 대해 총정리를 해보자면 이렇습니다:

• 브랜치를 생성한다는 것은 "협업"을 하겠다는 뜻입니다.
• 그래서 우리는 주로 브랜치 병합을 깃허브에서 하곤 합니다.
• 그 순서는 아래와 같습니다:
  • 1) main branch를 보호합니다.
  • 2) 병합하고자 하는 브랜치를 main branch로 병합시킵니다. 즉 pull request합니다.
    • PR 메세지를 신경써서 작성하는 것이 좋습니다.
  • 3) 충돌이 일어나는지 깃허브가 자동으로 확인합니다. 충돌이 딱히 없다면...
  • 4) merge합니다. 이 과정을 거치면 merge commit이 하나 추가로 찍히게 됩니다.
  • 5) 브랜치를 삭제합니다.

 

 

Merge된 깃허브 -> 깃에 동기화하기

 

• git fetch -p: 동기화 명령어
• git branch -d (브랜치명): 브랜치 삭제

 

브랜치를 삭제하고 싶다면 그 브랜치에서 일단 벗어나야 합니다. git checkout 명령어를 이용해 벗어나도록 합시다. 그런데 이 상황에서 merge commit을 vscode에서 확인해 보면 머지한 것이 없다고 확인됩니다. 이는 깃허브에서만 머지를 했지, 로컬 깃에서는 머지가 일어나지 않았기 때문입니다. main(master)에서도 동기화를 해줍니다.

 

• git pull origin main(master): 동기화 -> 이후 merge commit이 포함되어 있는 것을 볼 수 있습니다. 

 

Merge된 깃허브 - 깃 동기화 하는 방법을 정리해보면 이렇습니다:

1. git fetch -p를 통해 깃허브 브랜치 목록을 동기화합니다.
2. 다른 곳으로 빠져나간 후 깃 브랜치를 삭제 시도하면 아직 머지가 되지 않았다며 거부합니다. 이는 Main의 merge commit을 동기화시키지 않았기 때문입니다.
3. git pull origin master(main)로 동기화를 진행합니다.
4. branch를 삭제합니다: git branch -d (브랜치명)

 

충돌 해결하기

 

충돌이 발생할 경우 merge 과정에서 깃허브는 아래와 같은 문구를 출력합니다.

"This branch has conflicts that must be resolved."

그리고 옆에 Resolve conflicts 버튼이 생깁니다.

 

우리는 여기서 충돌을 확인하여 결정을 내릴 수 있습니다. 충돌이 일어나는 코드를 확인하여 무엇을 살릴 것인지 결정하고, 수정을 거친 후 mark as resolved를 클릭하면 해결됩니다. 이후 commit merge할 수 있습니다.