Development Policy

Kanban

Issue Board

It is a system that divides columns according to progress status and tasks and writes down issues in each column to understand the current status of work at a glance.

We decided to organize Kanban in Project Issue Board. All tickets will be issued and automatically assigned a unique number. For example, if #4 is assigned, the related commit is #4. Tickets (issues) must be archived and closed after completion.

In Korean

각자의 할 일을 간판 형태로 만들어 TODO와 전체적인 업무를 한 눈에 파악할 수 있는 시스템입니다.

해당 레포지토리의 Issue Board를 칸반으로 사용합니다. 생성된 모든 티켓들은 자동으로 고유한 번호가 매겨집니다. 예를 들어 티켓 번호가 #4라면 커밋에 #4를 붙여 작성하시면 됩니다. 완료된 이슈들은 close하고 archive처리를 해야 합니다.

Why use Kanban

This is to manage in real time who is doing what and what needs to be done in the future. And commit management becomes easier.

In Korean

각자가 하고 있는 일을 한 눈에 알 수 있고, 앞으로 해야 하는 일들을 팀원 모두가 동기화된 상태로 볼 수 있습니다. 추가적으로 커밋 관리도 쉬워집니다.

What is a ticket?

• One ticket (issue) per task.
• It is easier to manage commit records with tickets than to search for commit records later. Currently, a ticket number (issue number) is automatically assigned to each task in the GitHub project, so you can just use it as is. (i.e. git commit -m "#4 fix: Fix something") +Not all commits need to have a ticket number.
• Whenever you think of something that needs to be done, just add a ticket to Kanban. When adding a ticket, fill out Assignees, Milestone, Tile Tracking, Due Date, and Label except for Confidentiality.
• It doesn't necessarily have to be one commit per ticket. There will be many tickets with no commits at all, and one ticket may have multiple commits.

In Korean

• task 하나당 하나의 티켓(issue)입니다.
• 커밋 기록에서 어떤 일을 했는지 검색하는 것보다, 티켓을 사용하는 것이 해당 task에 어떤 커밋이 진행되었는지 관리하기 쉽습니다. 앞서 설명했듯 티켓 하나당 고유번호가 붙여지기 때문에 그대로 커밋에 사용하시면 됩니다. (예를 들어 #4 fix: Fix something과 같은 형식입니다.) 모든 번호에 티켓 번호가 있어야 하는 것은 아닙니다. 너무 작은 일이라면 넘겨도 무방합니다.
• 뭔가 해야 할 것 같은 일이 생각날 때마다 칸반에 티켓을 추가하면 됩니다. 티켓을 추가할 때는 Confidentiality를 제외한 나머지, Assignees, Milestone, Tile Tracking, Due Date, Label은 모두 작성합시다.
• 꼭 하나의 티켓당 하나의 커밋일 필요는 없습니다. 티켓 하나는 task 하나이기 때문에, 하나의 task를 해결하기 위해 여러 개의 커밋이 필요할 수도 있고, 아예 커밋이 없는 티켓도 존재할 수 있습니다.

Git Rules

Branch creation rules

The reason for using branches instead of pushing to main is to enable Pull Request. There are four main types of branches used.

• main: A branch that must always be in production state.
• develop: A branch branching from main and a branch that collects features.
• hotfix: This is the branch to use if a problem occurs after collecting features. Write a name including the feature you are fixing in the format fix/feature1.
• feature: This is the branch where each feature will be written. Just write an intuitive name such as IssueTab, HTML2MD, etc.

In Korean

메인으로 푸시하는 대신 브랜치를 사용하는 이유는 Pull Request를 사용하기 위해서입니다. branch는 크게 4가지를 사용합니다.

• main : 항상 production 상태를 유지해야 하는 브랜치입니다.
• develop : main에서 분기되는 브랜치이며, feature들을 수합하는 브랜치입니다.
• hotfix : feature들을 수합했는데 문제가 발생할 경우 사용하는 브랜치입니다. fix/feature1의 형식으로 수정하는 기능을 포함해 이름을 작성합니다.
• feature : 각 기능들을 작성할 브랜치입니다. IssueTab, HTML2MD 등 브랜치 기능을 작성하면 됩니다. 브랜치 이름은 직관적인 이름으로 작성하면 됩니다.

Commit message rule

• Use the appropriate header for Commit.
• Write concisely and understandably.
• All commit header and content should be written in English.
• When using a new header, please add it below.
• The ticket number is placed before the header. For example, it is like #4 fix: Fixed some issues.
• Use commit template below

# commit template set
git config --local commit.template .gitmessage

# use comment char ';' to write issue number in commit template
git config --local core.commentChar ';'

# write commit using commit template
git commit

Commit Headers

header	Meaning	Example
fix	Bug fixes	fix: fixed logo sticking out from top navbar in mobile
feat	Add new features	feat: added page skeleton for user login
BREAKING CHANGE	Commit with major changes in config or functionality	BREAKING CHANGE: Changed the Calendar component to something else!
docs	Edit development documentation	docs: minor fix in the backend readme
config	Change development or build config	config: changed gitignore config to rule out more files
test	Test related addition, change, deletion	-
refactor	Refactoring	-
etc	Various cases of ambiguous tagging	etc: added toy files to check git commands

Reference: https://www.conventionalcommits.org/en/v1.0.0/

In Korean

• Commit에는 아래 표에 있는 알맞은 헤더를 사용합니다.
• 커밋 헤더는 직관적으로 이해할 수 있게 작성합니다.
• 모든 커밋 내용은 영어로 작성합니다.
• 새로운 헤더를 사용하고자 하는 경우, 표에 추가하시면 됩니다.
• 티켓 번호는 헤더 앞에 붙입니다. 예시를 들자면 #4 fix: Fixed some issues와 같습니다.
• 아래에 있는 커밋 템플릿을 사용합니다.

헤더	의미	메시지 예시
fix	버그 수정	fix: fixed logo sticking out from top navbar in mobile
feat	기능 추가	feat: added page skeleton for user login
BREAKING CHANGE	config 혹은 기능적으로 큰 변화가 있는 커밋	BREAKING CHANGE: Calendar 컴포넌트를 다른 것으로 바꾸었습니다!
docs	문서 수정	docs: minor fix in the backend readme
config	개발/빌드 config 변경	config: changed gitignore config to rule out more files
test	test 관련 추가/변경/삭제	-
refactor	리팩토링	-
etc	태그 달기 애매한 각종 사례들	etc: added toy files to check git commands

Commit conflict resolution

For the safety of main, modify the project in each branch.

git checkout -b newFeature # Create the newFeature branch and use that branch

• All merge or pull request must be done after all test cases are passed!

In Korean

메인의 안전을 위해 각 브랜치에서 코드를 수정해야 합니다.

• 모든 병합 또는 풀 요청은 모든 테스트 케이스를 통과한 후에 수행되어야 합니다!