TIL - 2025.05.09
🔍 오늘 배운 내용
1. Git 개요
Git은 분산 버전 관리 시스템(DVCS)중 하나로 마치 평행세계처럼 여러가지 기능을 시도하고 백업할 수 있음.
또한 여러 개발자들이 동시에 같은 프로젝트에 작업이 가능하다.
버전 관리 시스템(VCS)는
중앙집중식 버전 관리 시스템과 분산 버전 관리 시스템으로 나뉜다.
VCS의 사용은 개발 팀의 효율성과 생산성을 크게 향상시키며 코드의 안정성을 유지하고, 실수를 쉽게 복구할 수 있게 돕는다.
왜 Git을 사용해야 하는가?
- 버전 관리
- 협업 도구
- 코드의 안정성 유지
- 코드 리뷰 및 추적
- 배포 관리
따라서 현업에서 코딩실력보다 중요할정도로 거의 필수적으로 사용되는 도구이다.
Git은 방구석에서 혼자(로컬) 하는 버전관리라면 Github는 온라인으로 업로드(공유)하고 관리하는 도구다. (전신이 Git이기에 Github와 Gitlab은 똑같음)
2. Git 설치 및 사용
- CLI : 명령어 기반 버전관리 (터미널 작업) **
- GUI : 그래픽 기반 버전관리 툴 (소스트리, GitHub Desktop, Git Kraken 등)
Git 설치 - 기본 설정 + Use VS code Editor
Git bash 설치 후 설정 (아이디, 이메일, master->main)
Git GUI 설치 - GitKraken
Git을 이용한 기본 터미널 명령어 (배포 환경에서는 터미널 환경이기에 익숙해져야함)
3. Git basic
- Git Repository(Repo) : 파일을 관리하고 추적할 수 있는 작업공간
: 이 폴더만 버전관리 할게요.
git init 명령어로 git 레포지토리 생성 (개발 시작할 때 한 번)
-> .git 숨긴 폴더가 생기는데 깃허브에 올려놓지 않고 삭제하면 개발했던게 물거품
- 초보자 주의사항 4가지
- git init 명령어는 버전관리를 시작할 때 최초 1번만 입력하세요!!
- git init을 하면 .git 폴더가 생성되는데 이 폴더를 지우지 마세요!
- git init을 했던 폴더의 하위+상위 폴더에 또 다시 git init을 하지 마세요!!
- github와 같은 원격 저장소에서 clone한 저장소에는 git init을 실행하지 마세요 (깃허브 배울때)
git status 로 버전관리 상태를 표시 (safe 명령어-정보만을 표시)
git add 로 파일 관리 시작
git rm --cached 로 중요파일 add했을때 취소
git commit 으로 버전 생성 (git commit -m "변경내용" 으로 VScode 실행없이 commit 가능)
git log 로 생성된 버전 확인(commit이력) + git log --oneline(간단하게)
실습예제
버전관리 폴더를 생성하고 두 개의 파일을 각각 add 및 commit 하는 과정을 통해 총 4개의 commit log 생성
3. Commit Advanced
Atomic Commit - 커밋을 최대한 작게(자주자주 save)
- 예를 들어 기능추가 commit 하고 버그수정 commit 하기
== 좋은 커밋 메세지 작성하기 (요즘엔 코드 복붙으로 AI가 변경점 요약해줌. 큰 흐름만 파악 후 귀찮은 것은 AI가 해결)
-
제목과 본문을 분리하기
제목과 본문은 빈 줄로 분리해야 한다. 이는 Git의 명령 줄 도구뿐만 아니라 많은 웹 기반 도구들도 이 형식을 사용하므로 중요한 원칙이다. -
제목 줄은 간결하고 명확하게
제목 줄은 가능한 50자 이내로 작성하고, 큰 변화를 요약하는 것이 좋다. 또한, 제목의 마지막에 마침표를 찍지 않는다. -
제목 줄에 명령문을 사용하기 - 과거시제보다 현재시제로 작성
제목 줄은 명령문으로 작성하는 것이 좋다. ("Add feature" not "Added feature" or "Adds feature"). 이는 많은 Git 도구에서 사용하는 규약이다. -
본문에는 "무엇을" "왜" 바꾸었는지 설명하기
본문에는 "무엇을" 변경했는지 보다 "왜" 변경했는지 설명하는 것이 좋다. 코드는 "무엇을" 변경했는지를 설명해주지만, "왜" 변경했는지는 코드만으로는 이해하기 어렵기 때문이다. -
본문을 72자 정도로 제한하기
Git은 자동으로 메시지를 72자로 줄이지 않으므로, 직접 줄 바꿈을 추가하여 본문의 각 줄이 72자가 넘지 않도록 하는 것이 좋다. -
이슈 트래커 ID를 참조하기
관련된 이슈나 버그 트래커 ID를 참조하면, 커밋과 이슈 사이의 관계를 명확하게 할 수 있다.
git commit --amend -m "" 은 최신 커밋 메세지만 수정가능 (깃허브에 공유하기 전에 해야함. 깃허브에 올린 후에 바꾸게 되면 커밋의 해시값이 변경되어 다른 사람의 작업을 방해함)
4. Git ignore (항상 제외하는 파일이 정해져 있기에 개념만 알아두기)
초기에 설정하는 것이 중요
중요한 보안 문서는 add 되는 실수가 없게 ignore 해두기.
.git이 있는 곳에 -> touch .gitignore -> notepad .gitignore -> 폴더는 끝에 / 추가, *.확장자 = 모든 특정 확장자 무시
- gitignore.io 사이트에서 자동으로 언어별로 깃허브에 안 올리는 것들 생성해줌.
5. Git Branch
코드의 특정 버전을 카리키는 포인터와 같은 것.
왜 필요한가?
1. 병렬 개발
각 브랜치는 독립적인 작업 공간이므로, 여러 사람이 동시에 다른 작업을 진행할 수 있다.
2. 버전 관리
각 브랜치는 특정 버전의 코드를 가리킨다. 이를 통해 과거의 어떤 시점으로도 쉽게 돌아갈 수 있다.
3. 안정성
'main' 브랜치는 항상 안정적인 버전의 코드를 유지하면서, 다른 브랜치에서는 새로운 기능이나 실험적인 변경을 시도할 수 있다.
4. 병합과 충돌 관리
브랜치 간의 변경 사항을 병합하는 과정에서 발생할 수 있는 충돌을 더 쉽게 관리할 수 있다.
main 브랜치는 안정적인 코드를 유지하고 새로운 브랜치에 기능추가
- Git의 HEAD는 현재 작업 중인 커밋을 카리키는 포인터.
git branch로 내가 생성한 모든 브랜치 목록을 볼 수 있다.
git branch 브랜치이름 -> 브랜치 생성
git switch 브랜치이름 -> 헤더 이동
git log --oneline --all --graph 모든 로그 확인
git switch -c 로 브랜치 생성하면서 즉시 이동 (자주사용)
git commit -am 은 add를 따로 안해도 커밋(자주사용X, add 먼저하기)
git이 옛날 버전이라 switch가 안 먹힐때 checkout 명령어 사용
branch를 삭제할때 git branch -d(딜리트) 브랜치이름 or -D(강제삭제) -> 삭제해도 커밋은 사라지지 않고 마커(이름)역할만 삭제이기 때문에 2주정도 이내(늦어지면 Git에서
사용되지않는 고아커밋 삭제)에 복구 가능
Git에서 브랜치를 다룰 때 초심자들이 흔히 하는 실수
- 브랜치 전환 시 변경 사항 커밋 또는 스태시 안하기 -> 커밋을 하고 브랜치 이동하기
- 긴 생명주기의 브랜치 사용
- master 또는 main 브랜치에서 직접 작업하기
- 너무 많은 변경을 하나의 커밋에 포함하기
요약 : Git은 강력한 도구지만, 잘못 사용하면 문제를 일으킬 수 있다. 브랜치 전환 전에 변경 사항을 커밋하거나 스태시하기,
적절한 생명주기를 가진 브랜치 사용, master 또는 main 브랜치에서 직접 작업하지 않기, 그리고 작은 단위의 커밋을 만드는 등의 방법을 통해 이러한 실수를 피할 수 있다.
😵 어려웠던 점
- GUI 환경에 익숙해져있던 탓에 CLI 환경에 적응하는 것이 쉽지 않다.
🧠 정리
- Git은 개인이든 협업이든 작업물의 원활한 개발과 관리를 위하여 꼭 필요한 존재이다.
💡 오늘의 깨달음
Git을 GUI환경에서도 이용할 수 있지만 CLI 환경에 익숙해져야 추후 리눅스나 도커 등의 환경에서도 쉽게 적응할 수 있다.
