공통 피드백

요구 사항을 정확하게 준수한다

과제를 제출하기 전에 과제 진행 요구 사항, 기능 요구 사항, 프로그래밍 요구 사항을 모두 충족하였는지 다시 한번 확인한다. 이러한 요구 사항들은 미션마다 다르므로 항상 주의 깊게 읽어 본다.

기본적인 Git 명령어를 숙지한다

Git은 개발자 간의 협업을 위한 가장 기본적인 프로그램으로, 컴퓨터 파일의 변경 사항을 추적하고 여러 사용자 간의 해당 파일에 대한 작업을 조정한다. 지금은 add, commit, push 등의 간단한 명령어만 배워도 충분하지만, Git에 대해 미리 알아두어도 나쁠 것은 없다.

Git으로 관리할 자원을 고려한다

package.json 파일만 있으면 node_modules 폴더를 생성할 수 있다. 따라서 Git을 통해 node_modules 폴더를 관리할 필요가 없다. IntelliJ IDEA의 .idea 폴더와 Visual Studio Code의 .vscode 폴더도 IDE에서 자동으로 생성하는 폴더이므로 Git으로 관리할 필요가 없다. Git에 코드를 추가할 때는 Git을 통해 형상 관리해야 하는 코드인지 고려하는 것이 좋다. 또한 .gitignore에 대해서도 알아본다.

package-lock.json의 역할을 이해한다

package.json 파일은 일반적으로 유의적 버전(semantic versioning)을 사용하며, package-lock.json에는 파일이 생성될 당시의 의존성 트리에 대한 정보가 있다. 이를 통해 node_modules를 커밋하지 않더라도 팀원들이 동일한 의존성을 설치할 수 있게 한다.

커밋 메시지를 의미 있게 작성한다

해당 커밋에서 수행된 작업을 이해할 수 있도록 커밋 메시지를 작성한다. 또한 팀의 좋은 코드 리뷰 문화는 작은 커밋을 작성하는 것에서 비롯된다.

커밋 메시지에 이슈 또는 풀 리퀘스트 번호를 포함하지 않는다

일부 프로젝트에서는 작업을 이슈 또는 풀 리퀘스트와 연결하기 위해 커밋 메시지에 이슈 또는 풀 리퀘스트 번호를 포함하기도 한다. 그러나 이 접근 방식은 원본 저장소의 관련 없는 이슈 또는 풀 리퀘스트에 영향을 미칠 수 있다. 따라서 이 과정에서는 커밋 메시지에 이슈 또는 풀 리퀘스트 번호를 포함하지 않는다.

풀 리퀘스트를 만든 후에는 닫지 말고 추가 커밋을 한다

이미 풀 리퀘스트를 생성하면 변경을 위해 새 풀 리퀘스트를 만들 필요가 없다. 변경이 필요한 경우 추가 커밋을 하면 자동으로 반영된다. 그러므로 미션 제출 기간 이후에는 추가 커밋을 금지한다.