Git과 Github

• 소스트리 사용 O
• 변경사항 취소 O
• 브랜치의 개념 O
• 브랜치 병합 O

• 소스트리 로컬 저장소와 원격 저장소 연결 성공
  https://velog.io/@sunjoo9912/Git%EA%B3%BC-Github-%EC%86%8C%EC%8A%A4%ED%8A%B8%EB%A6%AC-%EC%82%AC%EC%9A%A9

• 주석 남기지 않기
  -> 커밋 메세지를 활용하자

📌참고 자료

• 좋은 커밋 메세지 작성 1
• 좋은 커밋 메세지 작성 2
• 좋은 커밋 메세지 작성 3

git 커밋 메시지를 잘 쓰려고 노력해야 하는 이유

• 더 좋은 커밋 로그 가독성
• 더 나은 협업과 리뷰 프로세스
• 더 쉬운 코드 유지보수

$<label>:<title>$

• 제목의 길이는 최대 40글자까지 간단 명료하게 작성
• 명령문 사용, 마침표(.) 사용 X
  다음 문장 뒤에 제목을 배치해서 문법이 잘 어울리나 확인
  If applied, this commit will {제목}
• 제목을 작성하고 반드시 빈 줄 한 줄을 만들어야 함
• $<label>$ 리스트
  feature : 새로운 기능
  fix : 버그 수정
  style: formatting, missing semi colons, etc; no production code change
  refactor: refactoring production code, eg. renaming a variable
  docs : changes to the documentation
  etc : 기타 변경사항

$<description>$

• 내용의 길이는 한 줄당 60글자 내외에서 줄 바꿈
• 어떻게 보다는 무엇을, 왜 변경했는지를 작성할 것
• 모든 커밋 메시지를 제목과 본문으로 구성할 필요는 없다
  때에 따라서는 변경사항을 한 줄로 요약한 커밋 메시지가 더 효율적이다

$<issue-number>$

• 연관된 이슈 첨부, 여러 개 추가 가능

☁️

• 일관된 규칙을 사용하여 커밋 메세지를 남기는 것이 매우 중요해보인다

• 그러나 아직은 어느 상황에서 어느 lable을 사용해야할 지 명확하게 구분하기 힘들고 (검색해보면 사람마다 정한 lable과 규칙들이 조금씩 다르다), 커밋 메세지 하단에 이슈를 첨부하는 의미와 그 기능이 이해가 안간다

• 현재로서는 정확한 lable 사용과 이슈 첨부를 못 하더라도,
  git/github/sourcetree에 익숙해지고 작은 단위로 커밋하는 습관을 들이는 것에 집중해야겠다