Skip to content

Git Conventions

Kim Namjun edited this page Nov 29, 2016 · 9 revisions

Definition

Git 사용에 대한 대략적인 규칙에 대해서 정의합니다.

Remote repo에 commit, pull request, issue 등 Github이나 Git 에서 프로젝트 진행 시 사용하는 방법에 대해서 참고해 주세요.

수정 기록

    1. 22 v1.2 각자의 repository 에 대해서 fork->pull req 방식에서 모두 팀장님의 repo에서 작업하는 방식으로 수정

분류

commit

기본

  1. 모든 소스코드의 커밋 메시지 길이는 50자 이하로 왠만하면 해주세요. (어쩔 수 없는 경우에는..)

  2. 반드시 첫 문자는 대문자로 해주세요.

  3. 커밋 로그 마지막에는 마침표를 찍지 말아주세요.

1. 일반적인 소스코드 기능 추가나 구현, 삭제의 경우

(Add | Create | Delete) (function) 의 규칙을 따라주세요.

예시는 아래와 같습니다.

Add CVE Update from remote server <- 기능을 새로 생성한 경우
Create CVE Search <- 해당 기능을 Remote repo에 새로이 넣는 경우
Delete deprecated function <- 불필요한 기능을 삭제하는 경우

2. Issue close나 버그를 최종적으로 해결한 것을 확인한 경우

Fix (bug tag number with hashtag) (summarized message of bug) 의 규칙을 따라주세요.

예시는 아래와 같습니다.

Fix #1 https authentication error in cve_download()

branch

Naming conventions

  • 개발 관련 브랜치는 모두 dev, 이 중 특정 기능을 개발하는 branch 라면 dev-*(이름)으로

pull request

각자 개발한 내용이 담긴 branch 인 dev-* 브랜치에서 dev 브랜치로 pull request를 날려주세요.

팀장님의 Repo에서도 CI를 Merge 하기 전에 별도로 작업을 진행하지만 아래 링크를 참조해서 CI 해주시면 감사하겠습니다.

여기서는 Travis-CI 를 사용합니다. 해당 내용을 참고해 주세요^^ 무료니깐 맘껏 쓰셔도 됩니다.

issue

  1. 이슈는 누구나 생성할 수 있습니다.
  2. 이슈를 생성할 때 담당자를 지정해주세요.
  3. 꼭 라벨링을 해서 해당 이슈가 어떠한 이슈인지를 인지할 수 있도록 해주세요.
  4. 제목과 내용은 이메일을 보낸다고 생각하시고 상세하게 해주시고, 만약 소스코드에 문제가 있다면 해당 소스코드의 어떤 줄이 문제가 있는지 상세하게 알려주시고, 왠만하면 해당 소스코드의 줄에 대한 링크를 첨부해 주셔서 해당 소스코드의 몇번째 줄인지 찾을 필요 없이 해주시면 감사하겠습니다.

예시는 아래와 같습니다.

@(담당자의 계정)

androtools.py 의 해당 [내용](https://github.com/bunseokbot/androtools/blob/master/androtools.py#L21) 이 이해가 가지 않습니다.

굳이 이렇게 할 필요 없이 하나만 선언해도 되지 않나요?

이렇게 하니깐 한줄이면 될 코드가 열줄이 되어서 시스템이 다운되지 않습니까? (시비조는 안됩니다ㅠㅠ)

검토 부탁드립니다.

Clone this wiki locally