발단

새로운 브랜치를 만들고, 코드를 작성하고, 원격 저장소에 push하고, Github에서 PR을 생성한다.
일반적인 개발 Cycle이다.
이 때, naming 해야할 일이 아주 많아지는데 매 번 창의력의 한계에 부딪힌다...

그 중 하나가 바로 PR naming 이다.

예를 들어보자.

새로운 API endpoint가 추가되었다. PR이름은 뭐라고 지어야 할까?
add endpoint..? create endpoint..?? update API???

이런 naming은 내가 아는 바로는 공식적인 convention이 없다.
설령 있다고 해도 이런 부분을 다루지는 않는다.
아래는 한 naming convention을 전문적으로 다루는 사이트에서 발췌한 이미지다.

원문 Pull Request Naming
Short, informative summary...

전개

그래서 찾아보았다.
흥미롭게도, 개발 뿐 아니라 여러 방면에서 이런 정보를 찾고 정리하시는 분이 많은 듯 하다.
Stack exchange에서 좋은 글을 봤다.
terminology - Update vs Modify vs Change - Create vs Add - Delete vs Remove

내가 원하던 내용을 다루고 있다.
여기서 채택된 답변은 프로그래밍과 일반적인 상황으로 구분지어서 용어를 어떻게 사용할 지 정리해두었다.
영어 공부까지 할 수 있으니 매우 마음에 든다. (힣)

절정

위 답변을 정리해보도록 한다.

프로그래밍

프로그래밍 측면이라고 설명했지만 CRUD에 매우 집중된 경향이 있어보인다.

• 우리는 record를 create한다. 그리고 이를 container에 add한다.

• 그리고 container에서 remove한 후 delete 혹은 remove 한다.

• change는 아직 영구적이지 않은 것을 나타내고, update는 영구적인 것을 나타낸다. modify는 대체로 쓰이지 않지만 record를 flag로 사용할 때 쓸 수 있다.

일반 언어

• 처음부터 새로 만들어내면 create
• 이미 존재하는 것에 추가하는 것이면 add
• 어떤 것의 속성을 바꾼다면 modify
• 데이터를 바꾼다면 update
• 기존의 것을 완전히 대체한다면 change
• container에서 제거한다면 remove (soft delete 같은 느낌?)
• create와 정 반대로 완전히 지워버리면 destroy
• 영구적인 삭제는 delete

결말

답변 작성자의 추천은 따로 옮겨적진 않았다.
여기서부터는 개인 혹은 팀 단위로 약속을 정하면 될 듯하다.
내 개인적인 견해로는,

• 기능이 추가되면 add (feature branch의 대부분이 이럴 듯 하다.)
• 기능이 수정되면 change 혹은 update
• 데이터가 추가되면 update
• 코드가 제거되면 remove
• 데이터가 제거되면 delete

이렇게 정해놓았다.
정해놓는 이유는, 이걸 무조건 따르라!
가 아니라
PR naming 할 때 참고하고 덜 고통받기 위함이다...

끝!