Git

• 로컬에서 1차적인 형상관리를 진행한 후 원격 저장소에 통합을 진행
• 원격저장소에 저장된 내용과 충돌이 발생하면 충돌 해결 진행

브랜치 네임

• 브랜치를 이용해 각 개발자 별로 독립된 공간에서 작업 가능
• 브랜치 네임도 정형화된 규칙을 제안하여 관리할 수 있다.(gitFlow 등)

git vs github 차이

github

• git을 이용해 구현한 서비스
• 무료로 git server 를 제공하고, 웹상에서 코드리뷰를 진행할 수 있는 서비스 등을 제공
• 비공개 사내 git서버 구축 할 수있음.(git enterprise)
• 호스팅 외 이슈 관리, 깃 위키 등 부가서비스들도 제공

git

• 로컬에서 파일 버전관리 할 수 있는 툴

코드리뷰

• 개발자간에 개발 내용을 메인 브랜치에 통합하기 전에 검토하는 것
• 보통 github 내 pull request 기능을 이용하여 온라인 코드리뷰를 진행, 코멘트를 통해 수정
• 온라인 뿐 아니라 오프라인에서도 진행
• 더 좋은 코드에 대해 논의할 때는 조심스러운 상황이 발생
  • 더 좋은 코드(품질)가 개발자간 다를 수 있기 때문

더 좋은 코드리뷰를 위해

• 코드리뷰 요청자는 작업 내용을 최대한 작게 가져간다.
  • 작업단위가 작다는 것
  • 그렇다고 작업 중간에 올리는 것은 아님
• 코드를 검토해주는 협업자는 본인의 시간을 할애해 상대의 코드를 검토해주는 것, 작업 내용이 많아지면 내용을 파악하기도 어렵고 시간도 많이 소요
• 코드에 대한 의견을 얘기하기도 쉽지 않음
• 의견을 제시할 수 있지만 그걸 받아들이고 말고는 상대의 결정
  • 친근하게 작성 + 거절당하는 용기도 필요
• 같은 기능을 구현하는 건 여러가지 방법이 있다고 생각해야함.

룰

• comment : 버그가 있는 코드는 아니지만 가급적 수정했으면 좋겠다는 의도
• Approve : 코멘트는 전달하지만 문제가 있는 코드는 아니므로 수용여부는 개발자가 결정
• Request Changes: 반드시 수정해야하는 코멘트를 전달(버그를 유발하는 코드)

브랜치 관리 전략

git flow

• 정기배포가 있는 환경에 적합하며 수시배포 환경에선 사용되는 브랜치가 많음

github flow

실무에서 개발시 작업 흐름

• 새로운 기능의 추가 혹은 기존 기능의 버그가 발견
• 이슈관리도구(jira)에 티켓 생성
• 개발 담당자는 develop 브랜치에서 feature 브랜치 생성
• feature 브랜치에서 개발 하며 커밋 발생
• 개발 완료 후 github 을 통해 코드 리뷰 진행
• 이때 리뷰어는 팀내 개발자
• 각 조직별로 최소 승인 갯수가 필요하며 해당 승인을 받으면 develop 브랜치에 머지
• 머지된기능은 테스트서버에 배포되어 테스트 진행
  • 테스트를 길게 가져가는 경우, 테스트 전용 브랜치를 만들고 테스트 하고 메인 브랜치에 머지하는 전략으로 수정해서 사용.
• 테스트 완료 후 프로덕션 수준까지 배포가 되면 이슈관리도구의 티켓 종료

feature 브랜치

• 해당 작업을 나타내는 간결한 문장 사용
• 브랜치 이름보다는 커밋메시지가 더 중요

커밋 메시지와 머지 전략

• 시간이 지난 후 해당 코드 변경이 왜 발생했는지를 나타내는 중요한 메시지
• 어떻게 무엇에 대한 커밋인지보다는 왜 발생한 커밋인지를 적는게 중요
• "로그추가, A클래스 변경" 같은 메시지는 코드를 보면 누구나 알 수 있는 정보
• 자세한 내용은 이슈관리도구를 이용하기 위해 커밋메시지에 포함하는 경우 있음
• [ISSUE-001]송금 유효성체크 로직 개발
• 매 커밋마다 id를 넣거나 변경근거를 넣는건 실무에서도 쉽지 않음.

머지 전략

• Merge : feature 브랜치에서 작업한 키밋 히스토리가 그래로 main 브랜치에 포함
• Squash Merge : feature 브랜치에서 작업한 내용을 하나의 커밋으로 합침. feature 브랜치에서 100개의 커밋이 있어도 하나로 합침
  • 커밋 메시지를 잘 적어줘야 그 동안 했던 작업을 잘 나타낼 수 있음
• Rebase Merge : main 브랜치에 머지 시 각 커밋들이 재배치됨
  • 충돌나기 쉬움

github flow

• main 브랜치와 feature 브랜치 2개로 작업
  • hot fix도 main브랜치에서 바로 따옴

주의

• main 브랜치에 merge 시 바로 배포해야함
• 필요 시 테스트용 브랜치를 따로 만들 수 있음