평소에 깃에 대해 협업, 버전관리의 선택사항 툴 정도로만 생각했지
내부적으로 어떻게 동작하는지에 대해 자세히 알지 못하였다
이번 기회에 자세히 알아보겠다

• git의 탄생
• git init
• Modified ,Staged , Committed
• Git 주요 명령어
• git 사용 규칙

git의 탄생

Git 기존의 버전 관리 시스템의 느린 속도와 높은 비용, 중앙 집중식 모델의 제한점에 대한 불만으로
Git은 2005년에 리누스 토르발즈(Linus Torvalds)에 의해 개발된 분산 버전 관리 시스템이다

기존의 버전 관리 시스템(VCS : Version Control System) 은 많은 문제와 한계를 가지고 있었다고 한다
CVCS (Centralized Version Control Systems : 중앙 집중식 버전관리 시스템)의
Subversion (SVN), CVS, Perforce 등의 시스템 중앙 서버에서 버전을 관리하였다

이로 인해 발생한 문제와 한계

• 성능 문제 ( 통신이 필요함)
• 보안 취약점 ( 해킹 )
• 브랜치 병합의 어려움
• 데이타 손실 위험

위와 같은 사례로 CVCS의 문제를 극복한
분산 버전 관리 시스템 (Distributed Version Control Systems, DVCS)
Git, Mercurial 등이 출범하였다

git의 사이트의 로고 옆에 쓰여져 있는 문구

--everything-is-local  // 모든 것이 로컬이다

Git에서는 각 개발자가 전체 리포지토리(저장소)의 복제본을 로컬 컴퓨터에 가지고 있다.

Git은 각 커밋 시 파일 시스템의 스냅샷을 저장합니다. 이는 Git이 단순히 파일 변경 내용만을 추적하지 않고, 각 커밋의 시점에서 전체 파일 시스템의 상태를 저장한다는 것을 의미함

Git init

git을 설치하고 사용하기 위해선 깃을 초기화 시켜야 한다
git init을 실행하면, 작업 디렉토리 내에 .git 디렉토리가 생성됩니다.
이 과정을 통해 프로젝트 디렉토리는 버전 관리가 가능한 Git 저장소로 변환된다
git 디렉토리는 저장소의 모든 메타데이터와 객체 데이터베이스를 포함하며, Git의 핵심 데이터가 저장되는 장소이다

• HEAD: 현재 체크아웃된 커밋을 가리키는 파일입니다. 초기에는 아직 커밋이 없으므로 보통 master 브랜치(혹은 설정에 따라 main)를 가리키도록 설정됩니다.

• config 파일: 이 파일에는 저장소의 설정 정보가 저장됩니다. 사용자의 이름, 이메일, 원격 저장소 주소 등 저장소별 설정이 이 파일에 기록됩니다.

• objects 디렉토리: Git은 변경 내역을 객체 형태로 저장하며, 이 객체들은 이 디렉토리에 저장됩니다. 초기 상태에서는 비어 있지만, 커밋을 추가할 때마다 새로운 객체가 생성됩니다.

• refs 디렉토리: 브랜치, 태그 등의 참조들을 저장합니다. 특히 refs/heads와 refs/tags 하위 디렉토리가 이곳에 위치합니다.

• index 파일: 이 파일은 스테이징 영역의 상태를 기록합니다. 작업 디렉토리의 파일 중 어떤 것이 다음 커밋에 포함될 예정인지 관리합니다.

Modified ,Staged , Committed

주요개념!
Committed, Modified, Staged 는 Git 내부적인 동작으로 해당 주요 상태를 갖게된다

1. Modified는 수정한 파일을 아직 로컬 데이터베이스에 커밋하지 않은 것을 말한다.

• git status 명령어를 실행하면 수정된 파일이 "Changes not staged for commit"으로 나열

2. Staged란 현재 수정한 파일을 곧 커밋할 것이라고 표시한 상태를 의미한다.

• git status 명령어를 실행하면 스테이지된 파일이 "Changes to be committed"로 나열

3. Committed란 데이터가 로컬 데이터베이스에 안전하게 저장됐다는 것을 의미한다.

• git log 명령어를 실행하면 저장된 커밋의 목록과 각 커밋의 세부사항을 확인할 수 있다.

Git 주요 명령어

add

git add [file name]
변경 사항이 있는 모든 파일 add
git add . 
or
git add --all
or
git add -a
add 취소하기 (reset)

git reset // add한 파일 전체를 Unstaged 상태로 변경한다.

git reset HEAD [파일명] // 지정한 파일을 Unstaged 상태로 변경한다.
commit
git commit -m ["커밋 메시지"]
변경 사항이 있는 모든 파일 add와 동시에 commit
git commit -am ["커밋 메시지"]
commit 취소하기 (reset)
git reset --soft HEAD^ // staged 상태로 되돌린다 (add 만 한 상태)
git reset --mixed HEAD^ // default, unstaged 상태로 되돌린다 (add 하기 전 상태)
git reset --hard HEAD^ // 수정했던 내역까지 삭제한다.
git reset HEAD~2 // 마지막 2개의 commit을 취소한다.

remote repository 등록하기

git remote add [remote 리포지토리 주소]
특정 브랜치 생성하며 remote에 push 하기
git push origin [브랜치 이름]

브랜치 생성

git branch [브랜치 이름]
or
git checkout -b [브랜치 이름]

브랜치 이름 변경

git branch -M [새 브랜치 이름]

브랜치 이동

git checkout [브랜치 이름]
브랜치 이름 바꾸기
git branch -M [변경할 브랜치 이름]

이전 commit과 비교하여 파일 변경 사항 확인하기 (diff)

git diff
스테이징 영역과 최근 커밋 비교
git diff --staged

브랜치 삭제

git branch -d [브랜치 이름]

원격 브랜치 삭제
git push [원격 이름] --delete [브랜치 이름]

commit 로그 보기 (log)

git log
git log -p // 각 커밋의 diff 결과를 포함해 보여준다.
git log -3 // 최근 3개의 log를 보여준다.
git log --oneline // 한줄 요약
// Q를 누르면 git log를 escape 할 수 있다.

stash 현재 브랜치에서 변경 사항 commit없이 임시로 저장하기

git stash // 스택에 임시로 하던 작업을 저장한다.
git stash list // stash 목록을 확인한다.
git stash apply // 가장 최근의 stash를 가져와 적용한다.
git stash apply [stash 이름] // 특정 stash를 가져와 적용한다.
git stash apply --index // stash를 가져오면서 Staged 상태였던 파일들을 다시 Staged로 만들어준다.
git stash drop // 가장 최근의 stash를 스택에서 제거한다.
git stash drop [stash 이름] // 특정 stash를 스택에서 제거한다.
git stash pop // apply + drop 형태, 적용하면서 스택에서 제거한다.
git stash show -p | git apply -R // 잘못 적용한 stash를 원래대로 되돌린다.

git 사용 규칙

1. 명명 규칙 일관성 유지

브랜치, 태그, 커밋 메시지에 일관된 명명 규칙 적용

2. .gitignore 파일 활용

프로젝트에 포함되지 않아야 하는 로그 파일, 시스템 파일, 빌드 생성 파일 등을 .gitignore 파일에 명시하여 Git 추적에서 제외

3. 적절한 커밋 크기 유지

너무 많은 변경사항을 한 번에 커밋하기보다는 논리적으로 관련된 변경사항들을 작은 단위로 나누어 커밋

4. 중요한 지점 태깅

안정적인 릴리스나 중요한 마일스톤에 도달했을 때는 해당 커밋에 태그를 붙여 관리

5. 분기 전략 선택

Git Flow, GitHub Flow, GitLab Flow 등 프로젝트와 팀의 규모 및 요구에 맞는 분기 전략을 선택하여 사용

Github Flow란?

GitHub에서 제안하는 간단하고 효율적인 Git 브랜치 관리 전략
1. main 브랜치가 항상 배포 가능한 상태 유지
2. 새로운 작업은 브랜치로 생성
3. 브랜치에 커밋을 추가 ( 브랜치 작업 사항을 수시로 업로드 )
4. Pull Request를 생성하여 토론 및 리뷰 요청
5. 코드 리뷰 및 토론
6. PR 검토 후 main에 병합

TIP : Git은 기본적으로 대소문자를 구분하는 시스템이다

예를들어 bugfix 와 bugFix 는 리눅스 유닉스 환경에서 별개의 브랜치로 작동한다
실수 방지를 위해 카멜 케이스 혹은 오로지 소문자로만 작성해야 휴면에러 예방에 도움

• Linux & Unix

Linux/Unix: 이러한 시스템에서는 대소문자가 구분되므로, bugfix와 bugFix는 서로 다른 브랜치로 취급됩니다.

• Window

Windows: 일반적으로 Windows 파일 시스템은 대소문자를 구분하지 않으므로, bugfix와 bugFix를 동일한 브랜치로 취급할 수 있습니다. 그러나, Git 설정에 따라 이 행동이 다를 수 있습니다.