NB CAMP를 하면서, 비전공자임에도 정말 코딩을 잘하는 사람은 많고 스스로의 위치가 몸으로 느껴지는 하루였습니다. 오늘 간단하게 과제에 대해서 리뷰를 받았습니다. 그것은 바로, TIL입니다. 해당 노트를 작성하며 자연스럽게 하루를 마무리하고, 다음날에 맞이할 저 자신을 위해서 복기를 하는 용도로 사용할 것 같습니다!
TIL📘 이란?
우선, TIL이란 무엇인지 설명드리겠습니다.
Today I learned의 줄임말로써, 오늘 내가 배운 내용을 적어나가 특정 프로젝트가 끝났을 경우에 하나의 커다란 바인더를 형성하여 그간 있었던 일들을 복기할 수 있는 역할을 하게 됩니다.
Git & Github
깃 허브는 전 세계에서 가장 인기 있는 '소스 코드 호스팅 및 협업 플랫폼'으로 수백만 명 이상의 개발자 및 조직이 사용하고 있습니다. Github는 오픈 소스 프로젝트부터 기업용 개발까지 다양한 분야에서 사용되며, 많은 대표적인 오픈 소스 프로젝트와 기업이 선택하고 있습니다.
Git과 Github의 관계
저 또한 매우 헷갈렸던 부분으로 물론 내일 배움 캠프의 섹션으로 수강을 했지만, 본인이 정리하는 것이 필요하다고 생각이 들어 다시한번 정리해보겠습니다!
깃허브는 깃의 Remote Repository로써 클라우드 상의 외부 서버에서 서비스 해주는 단순 Repository입니다. 이러한 깃의 원격 저장소 서비스라고 풀이할 수 있는 깃허브외에도 Git Lab, Bitbucket이 있습니다.
사용하는 방법은 간단합니다. 원격 개인 노트북이나 PC에 로컬로 존재하는 Local Repository를 동기화해서 사용하면, 여러 개발자가 함께 공동 작업을 진행할 수 있습니다.
소프트웨어 형상 관리 Git
Git은 형상 관리 도구 또는 버전 관리 시스템으로, 프로그램의 소스 코드 버전을 관리해주는 오픈 소스 소프트웨어 툴입니다. 물론 프로그램 소스 코드 외에 문서의 형상 관리도 깃을 통해서 진행 할 수 있지만, 주로 텍스트로 이뤄진 코드와 같은 파일의 형상 관리를 위해서 사용이 됩니다.
근본적으로, 이렇게 형상 관리에 힘쓰는 이유는 기업의 측면에서 회사에서 개발한 코드는 사내 자산 그 자체가 되기 때문에 코드를 상시 백업하고, 오류 수정을 원할하게 하기 위해서 이 같은 시스템을 사용합니다.
Git의 사용방법
위의 사진에서 보는 것 처럼 깃을 수월하게 사용하기 위해서는 위의 4가지 영역을 잘 관리하고 구분해야 합니다.
- 작업 영역 : 실제 소스 코드 작업이 이뤄지는 Local Pc의 디렉토리와 파일을 의미합니다.
- 스테이징 영역 : '작업 공간'에서 작업한 내용 중에 깃이 관리하는 Local Repository로 저장하기 위해 저장할 대상을 선정하는 임시의 영역으로 저장할 대상이 되는 파일을 선택하는 영역을 의미합니다.
- Local Repository : 버전 관리가 이뤄지는 Git의 실제 저장소를 말합니다.
- Remote Repository : 다른 개발자와 코드를 공유하기 위해 로컬 리포지터리와 동기화되는 원격저장소이며, 깃 허브 등의 서비스를 의미합니다.
git add - staging area에 파일을 local repo로 보낸다.
git commit -m "commit message" - local repo 반영된 내용을 remote repo에 동기화 시킨다.
git push <repo name><branch name> - git clone으로 복제하여 가져온 경우, 원격 저장소명은 자동으로 origin으로 생성된다.
- 최초 동기화 명령 입력 단계에서 -u --set -upstream 을 통해 단순 git push/pull을 통해 동기화가 가능하다.
git push origin master:master
git pull origin master:master - pull을 하는 경우규칙적인 Commit 메세지 작성하는 방법
기볹거으로 커밋 메세지를 알아보기 위해서 중요한 것 중 하나는 Naming 방법입니다. 이를 명시적이고 규칙적으로 작성해주는 것이 중요합니다.
커밋 메세지의 7가지 규칙
- 제목과 본문을 빈 행으로 구분합니다.
- 제목을 50글자 이내로 제한합니다.
- 제목의 첫 글자는 대문자로 작성합니다.
- 제목의 끝에는 마침표를 넣지 않습니다.
- 제목은 명령문으로! 과거형을 사용하지 않습니다.
- 본문의 각 행은 72글자 내로 제한합니다.
- 어떻게 보다는 무엇과 왜를 설명합니다.
자세한 커밋 메세지의 구조는 아래의 코드 블럭과 같습니다.
$ <type>(<scope>): <subject> -- 헤더
<BLANK LINE> -- 빈 줄
<body> -- 본문
<BLANK LINE> -- 빈 줄
<footer> -- 바닥 글<type>은 해당 commit의 성격을 나타내며 아래 중 하나여야 합니다.
feat : 새로운 기능에 대한 커밋
fix : build 빌드 관련 파일 수정에 대한 커밋
build : 빌드 관련 파일 수정에 대한 커밋
chore : 그 외 자잘한 수정에 대한 커밋(rlxk qusrud)
ci : CI 관련 설정 수정에 대한 커밋
docs : 문서 수정에 대한 커밋
style : 코드 스타일 혹은 포맷 등에 관한 커밋
refactor : 코드 리팩토링에 대한 커밋
test : 테스트 코드 수정에 대한 커밋<body>는 본문으로 헤더에서 생략한 상세한 내용을 작성합니다. 헤더로 충분한 표현이 가능할 경우는 생략합니다.
<footer>는 바닥글로 어떤 이슈에서 왔는지와 같은 참조 정보를 추가하는 용도로 사용합니다.
- Example
Feat: 관심지역 알림 ON/OFF 기능 추가(#123)
시군구의 알림을 각각 ON/OFF 할 수 있도록 기능을 추가함
- opnion0055: 구분 코드
해결: close #123위 처럼 작성할 수 있고, 이렇게 규칙을 정하거나 따랐을때 누구든지 보기 쉬운 커밋을 진행할 수 있습니다.
코드 컨벤션
Code convention은 다양한 언어로써, 작성이 되어 지는 언어에 대해서 알아보기 쉽게 하기 위한 하나의 또다른 규약이라고 볼 수 있습니다! 그래서, 이러한 규약은 개발자들이 정하는 방향에 따라 달라질 수 있습니다.
🏃오늘 한 일
- 자바 강의 Chapter One 수강 및 과제 수행
- 깃허브 커밋 타이밍 관련 규칙 정리
- 코드 컨벤션 및 코드 설계 원칙 정리
🏃내일 할 일
- 다른 코드 컨벤션 규칙 찾아 정리하기
- 김영한님 스프링 강의 수강하기
- 자바 강의 Chapter Two 수강 및 과제 수행
- 계산기 Level 2까지 설계하기
- 백준 문제 5개 선별 후 최소 2개 풀기
References
1. TIL Picture
2. Git & Github
3. Git/Git Lab / Bitbucket
4. Commit rules
5. Code convention
