GitHub 실전 예시를 통해 실무 활용법을 파악해두자

📌 Github Flow

 

회사에서 새 프로젝트를 진행할 경우 개발 과정을 github에 기록한다는 사실은 누구나 알고 있을 것입니다.
그러므로 IT기업에서 github 활용법을 모른 채 협업을 진행한다는 것은 있을 수 없는 일입니다.
모든 기업이 아래와 같은 형태로 프로젝트를 진행하지는 않겠지만 큰 틀을 파악하고자 아래와 같이 작성했습니다.

 

👀 새 프로젝트가 생성되었습니다.

• 팀장님
  • 팀장이 본인 깃헙계정(또는 회사계정)에 신규 레포를 생성한다.
  • 신규 프로젝트(github projects)를 생성해서 해당 레포에 배정한다.
  • 해당 프로젝트 주소를 링크로 팀원에게 전달한다.
• 팀원
  • 팀 프로젝트(팀장 깃헙 링크)에 접속한다.
  • 프로젝트의 취지에 맞춰 Issues 란에 투두리스트를 작성한다.
    • 프로젝트 특성에 따라 본인이 이슈를 작성해야할 수도 있고, 팀장이 짜서 배정할 수도 있다.
    • 투두리스트 단위에 맞춰 commit할 예정이므로 하나의 작업 단위가 너무 커서는 안된다(한번의 commit으로 너무 많은 코드가 변동되어서는 안된다.)
    • issue 작성 후 오른편 리스트의 Projects(작은 글씨) 란을 클릭해 해당 issue가 해당하는 프로젝트와 status를 지정해줍니다.(프로젝트에 카드가 반영됩니다.)
  • 팀 프로젝트 레포를 개인 깃헙으로 Fork합니다.
  • Fork한 리모트 레포를 로컬에 설치합니다. (git clone)
  • 작업 내용에 맞는 branch를 따서 작업을 진행합니다.
    • commit을 더럽히는 실수 방지를 위해 main에서 바로 작업하는 것보다 branch를 파서 실수에 대한 대비를 미리 해두는 것이 좋다.
  • 이슈사항에 맞춰 개발을 진행합니다.(branch에서)
    • 각 투두리스트는 commit까지만 거칩니다. (push는 main에서 한꺼번에)
  • 투두리스트의 마지막 목록을 완료한 후 해당 commit의 상세 내용으로 아래 내용을 기입합니다.
    • Done 작업 이름
    • Close #1 (이슈넘버)
  • main 브랜치로 이동해서 merge 후 git push origin main 을 실행
    • 포크한 본인의 리모트 레포에 업데이트 합니다.
  • 리모트 레포(내 깃헙 사이트)에 접속해서 contribute 란의 open pull requests를 실행해서 지금까지의 commit내역을 팀장 레포에 전달합니다.
    • 송수신 전달 방향을 잘 지정해서 pull 합니다.
    • pull requests 양식에 맞춰 최종 커밋 메시지을 작성합니다.
      • 보통 최종적으로 작성한 commit 메시지가 자동적으로 옮겨집니다.
      • 만일 그렇지 않다면 또 다시 작성하며 어떤 작업이 Done 되었고 이슈 넘버 몇 번이 Close 되었는지 등의 정보를 줍니다.
• 팀장
  • 이메일 또는 깃헙 내부에서 pull requests가 들어온 것을 확인합니다.
  • File changed란에서 작업 내역을 확인하고 Conversation란에서 코멘트를 답니다. (피드백 또는 추가 요청 사항)
  • 코멘트 작성 후 finish review를 클릭해서 change requests를 선택 후 제출합니다.
    • 수정사항이 없을 경우 approve를 선택합니다.
• 팀원
  • pull requests 란에서 피드백 받은 내용을 확인하여 comment를 달고 수정 작업을 진행한다.
    • 간단한 수정이면 개인 fork main에서 바로 수정하고, 그렇지 않다면 branch→main 과정을 다시 밟는게 안전하다.
  • 수정 완료 후 다시 add, commit, push까지 진행하면 본인이 fork뜬 origin main 레포에 push했음에도 팀장님 리퀘스트 창에 바로 표기가 된다.
    • 한번 pull requests가 open 된 파일의 경우 재수정 시 지속적으로 수정사항이 pull requests창에 반영된다.
    • (pull requests 수정사항이 너무 쌓이게 되면 어떤 Task에 대한 내용인지 구분하기 어려워 지므로 팀장은 적당한 선에서 pull requests를 닫는 것이 좋다.)
• 팀장
  • 팀원의 수정사항을 pull requests 창에서 file changed란을 통해 상황을 확인 후 conversations 창으로 이동해 이상없으면 resolve conversation을 클릭해 준다. (이상이 있다면 또다시 comment를 단다.)
  • File changed 창에서 viewed를 클릭해서 해당 코드는 완료되었음을 표시한 뒤 Review changes를 클릭해서 리뷰 작성 후 Approve한다.
  • Conversation에서 Merge full requests를 클릭해서 최종적으로 레포에 반영합니다.
• 또 다른 팀원이 pull requests 진행 완료된 최신 레포를 업데이트 할 경우
  • git remote add upstream [팀장레포링크] 입력을 수행합니다.
  • 이는 본인이 과거 fork한 레포가 이미 있다는 것이 전제이며, 프로젝트 내용물을 최신화하는 개념이므로 git clone과는 다르다.
  • git remote set-url —push upstream no-push 입력을 통해 팀장 레포에 다이렉트로 push하는 상황이 발생하지 않도록 시스템적으로 차단하는 설정을 한다.
  • git pull upstream main을 입력해서 프로젝트의 최신사항을 내 fork에 반영한다.
    • 여러 사람이 참여하는 프로젝트의 경우 언제 최신사항이 변동되었을지 알 수 없으므로 작업 시 git pull을 우선적으로 실행하는 것이 좋다.