왜? Git (2) -Rep

Git Repository

 

1. Git Repository
2. git init
3. git config
4. Local VS Global Config
5. Working VS Git Directory
6. git commit
7. gitignore

 

 

 

Repository 는 저장소를 의미한다.

저장소는 프로젝트의 코드, 문서 및 기타 파일을 저장하는 위치다.

협업, 버전 제어 및 코드 관리를 위한 중앙 허브 역할을 한다.

여러 사람이 서로의 작업을 덮어쓰지 않고도 동일한 프로젝트에서 작업할 수 있다.

Git repository를 만듦으로써 여러사람과의 협업의 시작이 가능해진다.

우리는 이제 Git repository 의 사용법에 대해서 알아보자.

 

 

git init

 

 

 

이 git init명령으로 새 Git 저장소를 만들 수 있다.

기존의 버전 없는 프로젝트를 Git 저장소로 변환하거나 새 빈 저장소를 초기화하는데 사용한다.

대부분의 다른 Git 명령은 초기화된 저장소 외부에서 사용할 수 없으므로

일반적으로 새 프로젝트에서 실행하는 첫 번째 명령이다.

 

 

 

여기서 open git bash 를 클릭하면

 

 

이런 git bash 창이 나타나고 여기에 

 

git init

 

 

을 쳐서 git 에 한발자국 다가가보자.

 

 

git config

 

 

 

이 git config명령은 글로벌 또는 로컬 프로젝트 수준에서

Git 구성 값을 설정하는 데 사용되는 편의 기능이다.

이러한 구성값은  .gitconfig 텍스트 파일에 저장된다.

실행하면 git config구성 텍스트 파일이 조회,수정,추가 된다.

가장 기본적인 사용 사례는 git config 이름 으로 호출하는 것이다.

그러면 해당 이름에 설정된 값이 표시된다.

 

 

 

 

이렇게 .gitconfig 파일에 저장된

나의 구성값을 알수 있다.

조회 이회에 추가 수정 또한 가능하다.

이에 대한 정보는

 

https://git-scm.com/docs/git-config

Git - git-config Documentation

 

여기 공식문서를 통해 알 수 있다. 

 

들어가보면 알겠지만 정말 많은 git config 명령어가 존재하고 

이러한 명령어들을 다음과 같이 단축 명령어를 설정할 수 있다.

 

단축 명령어 설정

별칭(alias) 설정

보통 어느 저장소에 있느냐와
무방하게 동일한 명령어를 사용하고 싶을 것이므로
다음과 같은 방식으로 전역에서 설정을 해준다.

git config --global alias.<단축 명령어> <실제 명령어>

 

예를 들어, git status를 git st로 줄이기

git status는 자주 쓰이는 문법이니 참고하고 잘 쓰도록하자.

$ git config --global alias.st status

 

다음과 같이 가장 자주쓰는 git 명령어인
commit, checkout,branch 또한 축약가능하다.

$ git config --global alias.ci commit
$ git config --global alias.co checkout 
$ git config --global alias.br branch

 

 

Local config VS Global config

 

 

 

git은 Local 과 Global Config 설정을 할 수 있다고한다.

Local 과 같은 경우에는 하나의 Repository 즉 지금 현재 저장소에서만

사용할 설정을 하는것이고

Global Config와 같은 경우에는 나의 모든 Git Repository에 해당하는 설정을

할 수 있다고한다.

 

나는 협업시 헷갈림을 줄이기 위해서 Alias와 같은 별칭을 설정해보는것을

좀더 고려할 생각이다. 

 

Global과 Local  Config는 적용 범위에 있어서 차이가 난다.

 

 

 

Working VS Git Directory

 

 

 

디렉토리는 하나의 폴더라고 생각하면 된다. 어떠한 프로젝트를 진행

하더라도 폴더없이 진행하기에는 너무 지저분하니까. 폴더가 있다고 생각할 때

두가지 디렉토리에 대해서 차이점과 존재이유에 대해서

알아보자.

 

 

 

 

 

작업 디렉토리(Working Directory)

 작업 디렉토리는 개발자가 파일을 직접 편집, 추가, 삭제할 수 있는 로컬 환경이다. 이 디렉토리는 프로젝트의 파일들이 실제로 저장되고 수정되는 장소로, 현재 소스 코드의 가장 최근 상태를 반영하고 있다. 작업 디렉토리는 파일 시스템에서 쉽게 접근할 수 있는 구조로 되어 있어, 일반적으로 개발자가 사용하는 편집기나 IDE를 통해 파일을 자유롭게 변경할 수 있다. 작업 디렉토리의 변경 사항은 Git 데이터베이스에 자동으로 저장되지 않는다. 만약 된다면 끔찍하다. 생각하고 싶지도 않다. 대신, 개발자가 명시적으로 Git에게 어떤 파일을 추적할지 지정해야 한다.

 

 

 

스테이징 영역(Staging Area)

 스테이징 영역, 또는 인덱스라고도 불리는 이 영역은 작업 디렉토리에서 변경된 파일들 중에서 실제로 커밋할 준비가 된 파일들을 저장하는 장소다. 이 영역은 작업 디렉토리와 저장소(Repository) 사이의 중간 단계로 스테이징 영역은 개발자가 커밋할 파일들을 선별하고 최종적으로 커밋하기 전에 이 파일들을 검토하는 데 사용된다. 이때 git status 명령어를 통해 현재 staging area에 무엇이 들어있는지 알 수 있다. 이 과정을 통해 개발자는 불필요한 파일이 커밋되지 않도록 제어할 수 있으며, 더 깔끔하고 체계적인 커밋을 만들 수 있다.

 

 

왜 이 두 가지 개념이 필요한가?

1. 변경 관리의 효율성: 작업 디렉토리와 스테이징 영역의 분리는 파일 변경 사항을 보다 체계적으로 관리할 수 있게 해 줍니다. 개발자는 작업 디렉토리에서 자유롭게 실험하고 코드를 변경할 수 있으며, 스테이징 영역을 통해 어떤 변경 사항을 다음 커밋에 포함할지 명확히 선택할 수 있다. 그러므로써 올리기 싫었던 변경사항까지 git 저장소에 올라가는 문제를 예방 할 수 있다.
2. 코드 검토 및 테스트: 스테이징 영역은 코드 변경 사항을 커밋 전에 검토하고 테스트하는 데 유용합니다. 이를 통해 버그나 문제가 발견되면 커밋을 취소하고 수정할 수 있으며, 이는 코드 품질을 향상시키는 데 큰 도움이 된다.
3. 목표 지향적 커밋: 스테이징 영역을 사용하면 변경 사항을 작은 단위로 나누어 커밋할 수 있다. 왜? 한꺼번에 하지않는가?  한꺼번에 하게되면 내가 과거 어떤 수정을 했었는지 까먹게 되고 그 수정사항이 어떤 commit 으로 변경되었었는지 알기 힘들다. 내가 어떠한 버그를 개선하고, 기능을 여러개 추가하고, git commit을 하게될때는 최대한 작은 단위로 나누어 커밋하여 나중의 commit 히스토리를 통해 어떠한 작업들을 하였는지 이해하기 쉽게 하는것이 좋다. 이는 프로젝트의 히스토리를 명확하게 유지하는 데 도움을 주며, 필요할 때 특정 변경 사항을 쉽게 찾아보고 롤백할 수 있게 한다.

 

git commit

 

 

 

1: 작업 디렉토리에서 변경 사항 발생

개발자가 프로젝트 파일에 변동사항을 적용(수정, 추가, 삭제 등)하면

이는 먼저 작업 디렉토리에서 발생한다. 이 시점에서 변경 사항은 Git의 추적 범위 바깥에 있다.

2: 변경 사항을 스테이징 영역으로 이동

변경된 파일들 중 커밋하고자 하는 파일을 선택하여 스테이징 영역(인덱스)에 추가합니다.

git add 명령어를 입력하면 된다. 스테이징 영역에 파일을 추가한다는 건
Git에게 "이 파일들을 다음 커밋에 포함시켜라"라고 지시하는 것이다.

3: 커밋 생성

스테이징 영역에 준비된 변경 사항을 기반으로 git commit 명령으로 커밋을 생성한다.
이때 커밋 메시지를 함께 작성하여 변경 사항에 대한 설명을 추가한다.
커밋 메시지는 향후 프로젝트의 변경 이력을 검토할 때 매우 편리하고 또
중요하다. git commit -m "커밋메시지" 와 같은 형식으로 진행된다.

4: 커밋 로그에 변경 사항 기록

커밋이 성공적으로 생성되면, Git은 그 커밋을 현재 브랜치의 최상단에 추가한다.
각 커밋은 고유한 식별자(해시)를 가지고 있고, 이전 커밋을 참조하는 부모 링크가 포함되어 있어
프로젝트의 전체 이력을 형성한다.

5: 저장소의 업데이트

커밋을 통해 변경 사항이 저장소에 안전하게 저장되고,
이 커밋에 대한 정보는 로컬 저장소의 브랜치에 기록된다.
필요한 경우 이 커밋을 원격 저장소로 푸시하여
다른 개발자와 공유할 수 있다.

 

 

.gitignore

 

 

 

gitignore 파일을 사용하여 Git이 추적하지 않아야 할 파일이나
디렉토리를 지정할 수 있다. 이렇게 함으로써 불필요한 파일들이
저장소에 커밋되거나 저장되는 것을 방지할 수 있다.

 

 

 

 

 

.gitignore 파일의 기능

• 버전 관리 제외: .gitignore 파일에 명시된 파일이나 디렉토리는 Git에 의해 무시된다. 이는 로컬 환경에서는 필요하지만, 다른 개발자와 공유할 필요가 없거나, 프로젝트의 실행에 중요하지 않은 파일들에 대해 사용된다.
• 클린한 저장소 유지: 로그 파일, 컴파일된 파일(.obj, .exe 등), 설정 파일과 같이 자주 변경되거나 개인적인 정보를 포함할 수 있는 파일들을 저장소에 추가하는 것을 방지한다.
• 효율적인 협업: 모든 팀 멤버가 동일한 .gitignore 설정을 사용함으로써, 불필요한 파일들이 커밋되지 않도록 함으로써 저장소를 깔끔하고 관리하기 쉽게 유지할 수 있다.

 

 

 

.gitignore 파일 작성 방법

.gitignore 파일은 텍스트 편집기로 작성할 수 있고, 프로젝트의 루트 디렉토리에 존재한다. 파일 내에서는 각 줄에 하나의 패턴을 지정하여 무시할 파일이나 디렉토리를 명시한다. 몇 가지 일반적인 패턴은 다음과 같다.

• *.log : 확장자가 .log인 모든 파일 무시
• temp/ : temp 디렉토리와 그 안의 모든 내용 무시
• !important.log : important.log 파일은 무시하지 않음 (다른 .log 파일은 무시)
• build/ : build 디렉토리와 그 안의 모든 내용 무시
• *.pyc : 확장자가 .pyc인 모든 파이썬 컴파일 파일 무시

 

또, .gitignore 파일은 이전에 배웠던 Global Config로도 관리할 수 있다.
Global .gitignore 파일은 특정 사용자에게만 적용되며,
사용자의 홈 디렉토리에 위치합니다. 이를 설정하려면
git config --global core.excludesfile [file path] 명령을 사용할 수 있다.

.gitignore 파일을 사용함으로써, 프로젝트를 깨끗하고 체계적으로 유지할 수 있고,
불필요한 파일로 인한 혼란을 방지할 수 있다.
따라서 프로젝트 초기 단계에서 적절한 .gitignore 파일을 설정하는 것은 매우 중요하다.