Github 팀 프로젝트 어떻게 시작하면 좋을까

최근 연구실에서 특허 검색 프로젝트를 새롭게 시작하게 되었고 학군단 동기들과 빅콘테스트에 참여하면서 Github에 대한 중요성을 다시 한번 느꼈습니다.

아는 사이 또는 친한 사람과 프로젝트를 진행할 수도 있지만 보통 그렇지 않은 경우들이 많습니다. 그리고 아무리 친한 사람이어도 프로젝트에 진행하게 되면 감정이 상할 수도 있습니다. 프로젝트를 시작할 때 인성규칙, 코딩규칙, github 규칙 등 을 정해놓으면 불필요한 갈등들을 피할 수 있다고 생각합니다!

그래서 팀 프로젝트에 시작하기 앞서 함께 정의하면 좋은 규칙들과 github 사용에 대해 정리하려고 합니다.

인성 규칙

1. 단체 미팅 중에는 가능한 존댓말을 사용하며 예의있게 행동한다.
2. 자신의 일에 책임감을 가지고 한다.
3. 시간 약속을 철저히 지킨다.
4. 만일 일정 내에 업무가 되지 않을 경우 가능한 사전에 의사소통하도록 한다.

Github 협업 규칙

Github 협업 프로세스

1. ISSUE 티켓 생성 (Assignees, labels 등 포함, 템플릿 따라 작성)
2. Fork 한 Repo에서 ISSUE에 해당하는 Branch 생성
3. 생성한 Branch에서 ISSUE에 해당하는 작업 진행
4. 자신의 Repo에 commit 및 push
5. 공용 Repo에 PR 요청 (Reviwers, Labels 등 포함, 템플릿 따라 작성)
6. Review 이후 Merge 완료 (수정 필요시 4번으로 다시 이동)
7. 종료된 ISSUE, PR은 comment와 함께 Close

네이밍 규칙

• Branch 네이밍 방법
  1. 이름 + “-“ + 내용 + “-“ + 이슈번호

• ISSUE 네이밍 방법
  1. 키워드 중심으로 작성한다.

• PR 네이밍 방법
  1. 키워드 (프로젝트 시작 전 키워드 설정)
     • 예시) SET - 환경세팅, MP - 메인페이지, TS - 텍스트 검색, IS - 이미지 검색
  2. 키워드 + 이슈번호 + “-“ + 제목작성

Label 제작

• 기본 Label 세팅은 다음과 같다. (아래 그림 참고)

• 프로젝트에 필요한 Label은 가능한 초기에 추가하도록 한다.

ISSUE 제거 방법

1. PR과 ISSUE 동기화 방법
   • PR요청 시 Linked issues에 ISSUE 티켓을 연결시킨다.
   • 연결시키면 해당 PR이 merge 되어 종료 시 ISSUE티켓도 같이 없어진다.
2. PR 완료 이후 ISSUE 제거 방법
   • PR요청 merge가 되어 close 된 뒤에 ISSUE를 제거하고자 한다면
   • 해당 ISSUE에 이슈번호를 작성한 뒤에 ISSUE를 close 한다.
   • ex) #14 PR로 인해 해당 ISSUE 종료합니다.

코드 규칙

코드 작성

• ’ vs “ —> “
• 변수, 함수명은 항상 소문자로 작성한다. (전역 변수일 때만 대문자로 작성)
• try, except을 사용할 때는 한 번 더 고민해 본다.
• for을 사용할 때는 두 번 더 고민해 본다.
• 들여 쓰기는공백 4칸을 권장.
• 한 줄은 최대 79자까지
• 최상위 함수와 클래스 정의는 2줄씩 띄어쓰기

변수

• 상대방이 알아볼 수 있도록 작성한다.
• 변수명 규칙은 (주어)(동사)(명사) 순으로 작성한다.
• ex) 이미지 생성 : ImageCreate→ image_create
• 단어가 반복될 때는 가독성을 위해 “_“를 붙인다.
• ex) 텍스트 검색 : textsearch(x) → text_search

함수명

• 간단하게, 이해할 수 있게, 정확하게
• 함수 내 코드는 꼭 1가지 기능만 할 수 있도록 한다.

공백

다음과 같은 곳의 불필요한 공백은 피해야 한다.

• • 대괄호([])와 소괄호(())안

  # Correct:
  spam(ham[1], {egg: 2})

  #Wrong:
  spam( ham[ 1 ], { egg: 2 } )

 

• • 쉼표(,), 쌍점(:)과 쌍반점(;) 앞

  # Correct:
  if x == 4: print x,y; x, y = y,x

  #wrong:
  if x == 4 : print x , y ; x, y = y , x

• • indexing or slicing

  # Correct:
  dct['key'] = lst[index]

  # Wrong:
  dct ['key'] = lst [index]

• • 불필요한 띄어쓰기

  # Correct:
  x = 1
  y = 2
  long_variable = 3

  # Wrong:
  x             = 1
  y             = 2
  long_variable = 3

• • arrow

  # Correct:
  def munge(input: AnyStr): ...
  def munge() -> PosInt: ...

  # Wrong:
  def munge(input:AnyStr): ...
  def munge()->PosInt: ...

 

그 외 기본적인 코드 규칙들

• 그 외 기본적인 코드 규칙들(PEP 8 Style Guide for Python Code)

앞서 정의했던 인성규칙, Github 규칙 등 제가 프로젝트할 때 진행하기 편했던 방법이었으며 지극히 주관적인 규칙입니다. 아직 많이 부족하지만 앞으로 더 추가할 예정이며 협업에 있어서 필요한 것들에 대해 공부할 것입니다.