[GIT] 프로젝트 기여하기

프로젝트 변수

• 개발자의 수
  • 개발자들이 얼마나 활발하게 활동하느냐가 중요하다. 작은 프로젝트에서는 둘, 셋 정도의 개발자가 활동할 수 있지만, 대규모 프로젝트에서는 수백 명 이상의 개발자가 매일 수십, 수백 개의 커밋을 만들어 낼 수 있다.
• 프로젝트의 워크플로
  • 프로젝트에서 선택한 워크플로도 중요한 역할을 한다. 중앙집중형 방식인지, 관리자가 모든 패치를 검사하고 통합하는 방식인지, 개발자끼리 수정사항을 검토하고 승인하는 방식인지 등에 따라 기여 방식이 달라진다.
• 접근 권한
  • 프로젝트에 대한 읽기/쓰기 권한의 여부도 고려해야 한다. 쓰기 권한이 있는지 여부에 따라 직접적인 수정이 가능한지, 혹은 수정사항을 프로젝트에 반영하는 정책이 어떻게 구성되어 있는지 등이 중요하다.

커밋 메시지 작성에 대한 가이드라인

• 공백문자 체크
  • 커밋 전에 git diff --check 명령으로 공백문자 오류를 확인합니다. 이를 통해 불필요한 공백으로 인한 문제를 방지할 수 있습니다.
• Changeset의 논리적 분리
  • 각 커밋은 논리적으로 구분되는 Changeset이어야 한다. 한 주제로 요약 가능하며 여러 이슈를 한 번에 수정하더라도 Staging Area를 이용하여 한 커밋에 하나의 이슈만 담도록 한다.
• 커밋 메시지 작성 규칙
  • 첫 라인에는 50자 이내의 간략한 메시지를 작성하고 한 라인을 비운다.
  • 그 다음 라인부터 자세한 설명을 작성한다.
  • 현재형 표현을 사용하고 명령문으로 시작하는 것이 좋다.

비공개 소규모 팀

• 프로젝트는 두 개발자로 이루어져 있으며, 모든 개발자는 공유하는 저장소에 쓰기 권한을 갖는다.
• 보통 중앙집중형 버전 관리 시스템과 유사한 방식을 사용하지만, Git의 오프라인 커밋 및 브랜치 기능도 사용합니다.
• 개발자 A가 저장소를 Clone하고 파일을 수정한 후 로컬에서 커밋을 생성한다.
• 개발자 B가 저장소를 Clone하고 작업이 완료되면 변경사항을 서버로 Push합니다.
• Push 결과는 `<oldref>..<newref> fromref → toref` 형태로 표시되며 ordref는 이전 레퍼런스를 newref는 새 래퍼런스를, fromref는 로컬 레퍼런스 toref는 push한 리모트 레포런스를 나타냅니다.
• 개발자 A가 Push하면 B로 인해 거부됩니다.
• 여기서 SVN과 다른 점이 발견됩니다. SVN은 자동으로 서버가 merge를 해주기 때문에 push가 됩니다.
• 개발자 A는 B의 내용을 fetch하고 로컬에서 merge합니다.
• 그 후에 Push를 합니다.

• $ git log --no-merges 브랜치..리모트 브랜치
  # 리모트 브랜치에 속한 커밋 중 브랜치에 속하지 않은 커밋을 찾아냅니다.

비공개 대규모 팀

• 비공개 대규모 팀에서는 팀을 여러 개로 나누어 각 팀이 독립적으로 작업하는 경우가 많습니다.
• Integration-Manager 워크플로를 사용하여 작은 팀이 작업한 결과물을 통합하고 공유 저장소의 master 브랜치를 업데이트합니다.
• 개별 팀은 각자의 브랜치를 만들어 작업하고, Integration-Manager는 해당 브랜치를 Pull하여 Merge합니다.
• 개발자 A가 featureB 브런치로 작업 후 커밋 개발자 B가 feature2로 push한 경우 

• $ git fetch origin
  $ git merge origin/feature2
  $ git push -u origin featureB:feature2

• -u 옵션은 --set-upstream으로 featureB 브랜치는 리모트 feature2 브랜치를 추적하도록 해서 이후 push 나 pull할 때 좀 더 편하게 사용할 수 있습니다.

공개 프로젝트 Fork

• 모든 개발자가 쓰기 권한을 가지지 않는다.
• Fork를 이용하여 원래 저장소에서 갈라져서 나온 쓰기 권한이 있는 저장소가 만들어집니다.

• $ git clone <메인 저장소 url>
  $ git checkout -b featureA
  $ git remote add myfork <Fork 저장소 url>
  $ git push -u myfork featureA

• 관리자가 featureA를 프로젝트에 포함시키고 싶지 않을 때 해당 브랜치를 Merge 하기 이전 상태로 master 브랜치를 되돌릴 필요가 없기 때문입니다.
• pull request를 이용하여 관리자에게 push 내용을 알려주어야 합니다.

• $ git request-pull origin/master myfork

GIT을 이용한 이메일 보내기

• mbox 형식의 patch 파일 생성합니다.
• 각 커밋이 별도의 Patch 파일로 생성되며, 파일 이름에는 순서대로 번호가 부여됩니다.

• $git format-patch -M origin/master

• .gitconfig 파일에서 이메일 부분을 설정합니다.
• IMAP 서버를 이요해서 보내는 방법

• [imap]
    folder = "[Gmail]/Drafts"
    host = imaps://imap.gmail.com # SSL 사용할때는 imap://
    user = user@gmail.com
    pass = YX]8g76G_2^sFbd
    port = 993 # SSL 사용할때만
    sslverify = false # SSL 사용할때만

• $ cat *.patch |git imap-send

• SMTP 서버를 이용해서 보내는 방법

• [sendmail]
    smtpencryption = tls
    smtpserver = smtp.gmail.com
    smtpuser = user@gmail.com
    smtpserverport = 587

• $git send-email *.patch