로컬 Git 저장소 생성

Step 1. git init

현재 작업중인 working directory를 git 영역으로 초기화

git init

git에서 어떤 폴더 안에 있는 파일들에 대해 이력을 관리하기 위해서는 init 명령어를 통해 해당 폴더를 초기화해줘야 한다.

git init 명령어를 입력하여 초기화를 하면 '.git'이라는 숨김 폴더가 생성되고, 해당 디렉토리에 대한 깃에 관한 모든 데이터가 '.git'에 저장됨 (소스 이력 등)

내가 지금 쓰고 있는 컴퓨터의 폴더를 git 저장소로 변환하는 것. git 저장소가 되면 해당 폴더의 버전 관리가 가능해짐

*주의: git init 명령어를 쓰기 전에, 지금 깃을 초기화하려는 경로가 내 프로젝트가 위치한 곳이 맞는 지 확인해야 함. 

위치가 맞지 않다면 불필요하거나 보안에 민감한 파일들이 깃의 관리 영역에 포함될 수도 있음. 이 파일들이 원격 저장소에 public(공개된) 상태로 push 된다면 보안 사고가 발생할 수 있음.

Step 2. '.gitignore' 파일 추가

'.gitignore' 파일은, 특정 파일을 git이 관리하지 못하게 막는 역할

개발 중 외부의 라이브러리를 활용하거나 데이터베이스에 접근하기 위한 계정 정보, 클라우드 서비스 시크릿 키 등을 필요로 하는 경우가 있는데, 이러한 각종 민감 정보를 원격 저장소에 반영해서는 안된다!

git init을 통해 깃으로 초기화된 폴더에 '.gitignore'라는 파일을 만들고, git에서 무시할 파일의 이름을 작성하면 이 폴더 내의 해당 파일은 더이상 깃에 의해 탐지되지 않음

.gitignore파일 내에

abc.txt

이런 식으로 파일 이름을 입력해놓으면, 이 '.gitignore' 파일과 같은 위치에 있는 'abc.txt'는 git에서 무시됨

 

깃에서 일반적으로 무시하는 파일들로는, 보안상 민감 정보, 각종 설정 파일, 컴파일 언어들의 빌드 산출물, 개발용 데이터베이스 등이 있는데, 

https://github.com/github/gitignore

GitHub - github/gitignore: A collection of useful .gitignore templates

위 링크에 들어가면 깃에서 gitignore파일에 대해 언어별, 프레임워크 별 템플릿을 제공해주고 있음. 개발에 이용하면 좋음

 

Step 3. git status

현재 어떤 파일들이 추적되고 있고, 예비 저장소인 staging area에 어떤 파일이 들어있는 지를 확인하는 명령어

 

Step 4. git add

로컬 환경 내의 working directory에서 add 명령어를 수행한 파일들이 staging area에 반영됨

git add .

현재 위치의 모든 파일을 add

이렇게 전체를 반영할 때는 커밋이 되면 안되는 파일들이 있는 지를 반드시 확인할 것

git add 파일명

특정 파일만 add

 

add는, 나의 프로젝트 파일 중 버전 관리에 반영할 파일을 지정하는 것

버전을 찍어 스냅샷으로 관리할 파일을 지정하는 것

이 버전 관리에 반영된 파일의 영역이 staging area인거고

 

add 명령어를 잘못 수행해서 원치 않는 파일이 예비 저장소인 staging area에 들어가게 되었다면, rm/reset 명령어로 이를 되돌릴 수 있음

git rm 파일명 // 원격 저장소와 로컬 저장소 파일을 삭제
git rm --cached 파일명 // 원격 저장소에 있는 파일만 삭제, 로컬 저장소에 있는 파일은 삭제하지 않음
git rm -r --cached 폴더명 //-r 옵션으로, 폴더와 하위 모든 파일 삭제 가능

 

Step 5. git commit -m "<message>"

Staging Area에 있는 것들을 실제 저장소에 하나의 버전으로서 관리할 수 있게 해주는 커밋 작업

일종의 버전을 생성하는 과정이기 때문에, 이에 대한 메세지를 -m을 통해 남겨야 함

메세지를 입력하지 않으면 에러가 발생하고, 커밋은 이루어지지 않음

협업 개발의 경우 작업에 대해 상세하게 메세지를 잘 작성하는 것이 중요

큰 개발 조직의 경우 메세지에 대한 엄격한 규칙을 적용하기도 함

Staging Area (반영하기 위한, 버전으로 관리하기 위한 파일들의 예비 저장소)에서 실제 로컬의 저장소로 커밋되어 버전이 찍히게 됨

(Staging Area --commit--> Local Repository)

 

로컬 저장소에 반영된 소스들은 아직 내 컴퓨터 (로컬 환경)에만 존재. 이 소스를 다른 이들과 공유하거나 인터넷에 올리고 싶다면 깃허브에 반영해야 함

 

즉, 우리는 로컬 저장소에 변동 기록(버전)을 남기기 위해 commit을 실행하는 것

commit을 통해 새로운 버전을 git에 등록하는 것

message를 남기는 이유는 commit에 대한 정보를 기록하기 위함

 

버전을 등록하는 과정에서 메세지를 잘 남겨줘야 함. 커밋에 대한 정보 기록이 잘 남아 있어야 이 프로젝트, 수정 사항에 대해 문제 발생 시 빠르게 대응할 수 있음.

 

Step 6. git branch -M main

옵션 사항: 과거에는 master였던 기본 브랜치 이름을 main으로 바꿔주는 과정

master 브랜치와 main 브랜치 사이에 기능적인 차이는 없음. "master"와 같은 인종차별, 주종관계를 나타내는 용어를 수정하고자 하는 문화의 일환으로 Git에서 이를 "main"으로 변경한 것

 

branch란?

동일한 저장소 내의 소스에 대해서 서로 영향을 받지 않는 독립적인 공간

사진 삽입

 

이런 독립적인 공간을 두는 이유?

이 독립적인 환경에서 서로 다른 개발자들이 소스가 덮어써지거나 삭제될 염려 없이 멀티버스 같은 환경 속에서 작업이 가능

git branch -M main

현재 바라보고 있는 brahcn의 이름을 main으로 변경

main이 기본값으로 사용되고 있기 때문에 현재 바라보고 있는 branch의 이름을 main으로 변경하는 옵션 과정

대부분의 최근 설치된느 깃 버전에서는 init을 하면 main이 생성되기 때문에 꼭 필요한 작업은 아닐 수 있음. 다만 master라고 뜬다면 다른 프로젝트와의 충돌, 혼선을 막기 위해 해당 명령어를 수행

 

크게 세 가지 혹은 그 이상의 많은 브랜치로 실제 프로젝트들이 관리됨

main/master

git에서 최초로 init 명령어를 통해 초기화했을 때 생성되는 기본 branch명

즉시 운영 배포할 수 있는 버전

사용자가 지금 이용중인 어플리케이션의 코드

main은 모든 작업 사항이 합쳐지는 곳이기 때문에 main에서 작업하는 것은 위험할 수 있음

staging

상용에 반영하기 전 테스트 버전

실제 브랜치 명은 다르게 표현될 수도 있음

feature

새로운 기능을 추가 개발하는 브랜치 (병렬 작업)

feature가 많을 수 있음. 이 feature가 서로 꼬이지 않고 개발이 가능하도록 병렬 작업을 가능하도록 한 게 branch 구조의 특징

 

main 브랜치에서 모든 개발을 진행한다면 협업도, 1인 작업도 효율적으로 하기 어려움

소스 커밋과 버전이 엉켜 버그 발생 시 해결이 어려움.

A, B, C라는 각기 다른 기능을 위한 각각의 브랜치를 두어, 나중에 소스 작성이 완료되고 테스트까지 끝나면 메인 브랜치로 병합

->브랜치를 통해 서로 영향을 주지 않으면서도 효율적인 작업이 가능해 짐

 

다음 포스팅에서 실습을 해보겠다.