Critical
Git Ignore
프로젝트에서 작업하면서 깃을 사용할 때, 갖고 있는 파일이나 디렉토리가 어느 시점에서 깃에게 알려지거나 추적되는 것을 원치 않고 완벽하게 제외되는 상황이 있다. 이때 .gitignore라는 특정 파일을 생성할 수 있다.
이에 앞서서 이런 상황을 필요한지에 대해 알아보자. 가장 흔한 것 중 하나는 비밀스러운 API를 사용하는 경우, 디펜던시 문제, 등등이 있다. 디펜던시의 경우, 어떤 소스코드를 사용하기 위해서는 다른 여러가지 파일이 다운로드되어야 하는데, 이를 모두 깃으로 추적할 필요는 없다.
이를 위해 앞서 얘기했듯이 .gitignore 파일을 저장소의 아무 곳에 넣는데, 보통은 저장소의 최상위 루트에 넣는다. 파일을 만들면 git은 그 파일을 찾고 그 안에서 깃에게 어떤 것을 제외할지 지시할 수 있다. 여기서 ignore 한다는 의미는 깃이 파일이나 폴더를 추적하지 않게 하는 것이다. 이때 .gitignore에 추가를 하면 git 저장소에 올라가지 않기 때문에 저장소 크기 문제, 보안 문제 등을 해결할 수 있다.
그냥 커밋을 하지 않는 것과 같은 효과를 내지만, .gitignore 파일에 등록해놓음으로써 명시적으로 어떤 파일이 일부러 커밋을 안하는 건지 아니면, 커밋을 해야되는데 안한건지를 나타낼 수 있고, 만약 어떤 파일이 이미 커밋된 상태라면 그 파일은 계속 추적되는 상태이기 때문에, .gitignore에 추가함으로써 그 파일의 추적을 막는다. 크라켄 같은 GUI 환경에서는 .gitignore에 추가를 하면 Unstaged files에서도 제외가 된다.
.DS_Store-> 파일을 무시한다.
foldername/->폴더를 무시한다.
*.log-> log라는 확장자을 가지고 있는 파일을 무시한다.gitignore.io
위의 링크는 어떤 응용프로그램을 만들때 언어에 따라 .gitignore에 추가해야될 파일을 보여준다. 프로젝트를 만들 때 참고하자.
Important
Writing Atomic Commits
많은 블로그에서 조언하는 것은 "Keep git Atomic" 인데 여기서 "Atomic"은 무슨 뜻일까? 각각의 커밋이 하나의 변화를 반영하고 있어야 한다. 즉 하나의 커밋이 여러가지 기능 변화 등 여러개의 변화를 갖고 있는 것이 아니라 하나의 변화,단일작업(single thing)만을 반영하고 있어야한다는 뜻이다.
** git add MoodBoard/ -> 여기서 / 는 entire directory를 뜻한다.
Configuring Default Editor
git commit -m "my message"도 좋은 방법이지만 실제 업무에서는 메시지가 굉장히 긴 글일 수도 있기 때문에, git commit을 통해 에디터를 열고 긴 메시지를 써야할 수도 있다. 따라서 원래 설정된 Vim editor를 이용하는 것보다는 Vscode와 같은 에디터를 이용하는 것이 좋을 수 있다.
git config -global core.editor "code --wait" 명령어를 통해서 vscode를 git의 기본에디터로 설정할 수 있다. 여기서 --wait은 커밋 메시지의 편집을 끝내고 저장할 때까지 에디터가 기다려서 커밋메시지를 작성할 수 있게 된다. 이렇게 커밋메시지를 작성할 때에는 화면에 맞추어서 단락을 내려주어야한다. 이때 Vscode에서는 빨간색 글자가 나옴으로써 알 수 있다.
Writing Good Commit Messages
깃 문서에서는 공식적으로 현재시제의 명령형 커밋 메시지를 사용할 것을 권장한다. (Imperative mood-> 명령하듯이 말하는 것) 그러나 일관성을 유지하고 회사의 방침에 따라서 사용하는 것이 옳다.
Navigating the Git Documentation
git documentation->reference manual or Book
Git Log 명령어 자세히 알아보기
git log --pretty-> 로그가 출력되는 방식을 예쁘게 만들어준다.
git log --oneline-> 로그가 한줄로 출력이 된다(태그 ,메시지)
git log --Abbrev-commit-> commit 마다 있는 hash의 길이가 짧아진다.git log --oneline 같은 경우 로그 메시지가 한줄로 출력이 되는데, 만약 로그 메시지가 긴 경우 가장 위의 로그 메시지가 출력이 된다. 따라서 긴 로그 메시지를 작성해야하는 경우는 가장 위에는 전체에 대한 요약이 들어가는 것이 옳다. 이렇게 하면 자신이 작성한 커밋 메시지를 보고 다시 커밋을 재방문하기 용이하기 때문에 유용하다.
Nice To Have
Working With a GUI
Amending(수정하다) Commits
깃으로 작업할 때, 새 커밋을 실행한 다음 그 커밋에 관련 파일을 포함시키지 못할때가 있다. 또는 커밋한 다음 커밋 메시지를 읽어보았는 데 오타가 있는 경우도 있다. 이때 가장 쉬운 방법은 commit을 amend(수정) 하는 것이다. 이 방법은 바로 직전에 커밋한 것을 편집하거나 업데이트를 할 수 있게 해준다. 먼저 git add forgotten_file를 해주고 그 다음에 git commit --amend를 해준다.
--amend-> Replace the tip of the current branch by creating a new commit
