Git, Github 특강

협업과 코드관리

• command 이용해 사용하는 것을 추천

https://daunje0.tistory.com/6

github의 wiki나 다양한 기능을 활용하자!

코드리뷰

• 코드리뷰를 요청한 개발자가 미처 발견하지 못한 버그가 숨어있는 경우는 분쟁의 소지가 없음
• 더 좋은 코드에 대해 논의할 때는 조심스러운 상황이 발생하기도 함
• "더 좋은 코드"가 개발자간에 다를 수 있기 때문
• 코드리뷰의 유형
  • 질의응답
  • 칭찬 ^^ 선칭찬 후요구
  • 이해한 내용 확인하기
• 코드리뷰 요청자는 작업 내용을 최대한 작게 가져간다

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

브랜치 관리 전략

• git에서 브랜치는 개발자간의 독립적인 공간을 제공
• 브랜치 명만 보고도 해당 작업이 어떤 작업인지 유추 가능
• 원격에 브랜치가 쌓이는 것은 좋지 않다. merge 이후 삭제?

GitFlow

master branch는 언제든지 문제없이 빌드되어야 하고 배포될 수 있는 고결한 상태를 유지한다.

새로운 배포

• master -> develop -> release

• develop branch에는 여러 feature branch가 모인다. 버그 발생, 빌드 안됨 등이 발생 가능하다. 런타임 동안 알 수 있기 때문에 release에서 QA가 진행되며 바로 바로 수정하고 commit이 쌓일 것이다.

• 작업이 완료되면 master branch에 올라간다.

branch 종류

• feature
  기능개발을 위해 develop으로부터 생성하는 브랜치
• develop
  완료된 feature 브랜치들이 머지되는 브랜치, 배포 간격 사이에 추가 기능들이 머지되어 있음
• hotfix
  이미 배포되어 있는 상태에서 급히 수정이 필요한 버그가 있을 경우 master로부터 생성되는 브랜치, 수정 이후 master와 develop으로 머지
• release
  배포 시점이 다가오면 develop으로부터 생성

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

실무에서 개발 시 작업 흐름

이슈 관리 도구(jira)

• 머지된 기능은 테스트서버에 배포되어 테스트 진행
• 테스트 완료 후 프로덕션 수준까지 배포가 되면 이슈관리도구의 티켓 종료
• Task > Sub Task > 건별로 PR이 갈 수가 있도록
• 요령이 없이 작게 올리는 것의 폐해
  • "작업 단위"를 작게 쪼갠다는 단위
  • 작업을 완료하지 않고 중간에 올리라는 말이 아니다. "이거 아직 안되서 그래요." 이런 Comment가 오고 간다면 작업 단위를 잘못 나눈 것이다.

1. CI(지속적인 통합) 관점: 잘게 나누고 master에 merge되고 배포되는 것
2. 현실적인 방안
   master에서 중간 branch를 하나 딴다. 거기서 개발자들이 브랜치를 각각 또 판다. feature branch에서 중간 branch에 merge한 이후 master로 들어갈 때는 큰 commit이 발생.

feature 브랜치

• feature/configure-json
• 개인당 하나씩 브랜치를 따라.
• merge되면 사라지는 branch 이름보다는 commit 메시지가 더 중요하지 않을까?

commit 메시지와 merge 전략

https://meetup.nhncloud.com/posts/122

• 시간이 지난 후 해당 코드변경이 왜 발생했는지를 나타내는 중요한 메시지
• 어떻게, 무엇에 대한 커밋인지보다는 왜 발생한 커밋인지를 적는게 중요

• 작업 완료 이후 브랜치를 머지할때 3가지 방식 존재
• merge: feature 브랜치에서 작업한 커밋 히스토리가 그대로 main 브랜치에 포함됨

1. 일반 Merge
   

2. Squash Merge

• feature 브랜치에서 작업한 내용을 하나의 커밋으로 합침.
• 새로운 커밋 메시지 필요
• Issue Id도 여기서 넣으면 된다.
• Squash Merge를 할 때 커밋 메시지를 제대로 작성하면 매번 커밋할 때마다 메시지 고민 하지 않아도 된다.

• 퉁쳐질 때 커밋 메시지만 잘 쓰면 됨
• 일반 Merge를 하면 처음부터 커밋 메시지에 신경을 많이 써야 한다. Main 브랜치에 들어가니까!

3. Rebase Merge

• main 브랜치에 머지 시 각 커밋들이 재배치됨
• 좋은데, 충돌나기 쉬운 방법
  

테스트용 브랜치

• 동시에 QA
• feature -> test
• feature -> master

Git 명령어

Git pull

다른 팀원이 Pull Request, Merge 완료 -> pull

git pull의 동작 방식

• Fetch: 원격 저장소의 최신 변경 사항을 로컬 저장소로 가져옵니다.
• Merge: 가져온 변경 사항을 현재 로컬 브랜치에 병합합니다.

코드가 지워질 수 있는 경우

git pull은 단순히 원격 저장소의 변경 사항을 로컬로 가져와 병합하는 과정이기 때문에 직접적으로 코드를 삭제하지 않는다. 하지만 다음과 같은 경우 충돌이 발생할 수 있다.

• 동일한 파일의 동일한 부분을 수정한 경우: 로컬과 원격 저장소에서 동일한 파일의 동일한 부분을 수정한 경우 충돌이 발생한다. 이 경우 Git은 자동으로 병합할 수 없기 때문에 수동으로 충돌을 해결해야 한다.
• 삭제된 파일을 수정한 경우: 원격 저장소에서 삭제된 파일을 로컬에서 수정한 경우에도 충돌이 발생할 수 있다.

Git Fetch

❗ fetch 와 pull 의 차이점

pull 을 실행하면, 원격 저장소의 내용을 가져와 자동으로 병합 작업을 실행하게 된다.
그러나 단순히 원격 저장소의 내용을 확인만 하고 로컬 데이터와 병합은 하고 싶지 않은 경우에는 fetch 명령어를 사용하면 된다.

fetch 를 실행하면, 원격 저장소의 최신 이력을 확인할 수 있다. 이 때 가져온 최신 커밋 이력은 이름 없는 브랜치로 로컬에 가져오게 된다.

다른 작업자들의 작업물을 바로 내 로컬에 반영하려면 fetch는 잊고 pull만 하면 된다(fetch + 내 파일에 반영이 pull 이므로)