![[Git] 시작하기](/images/git_logo.png){kind=logo}
Table of Contents
Git 소개
깃은 리눅스(Linux)의 아버지 리누스 토발즈(Linus Torvalds)라는 사람이 만들었습니다. 리누스 토발즈는 리눅스를 만든 이후에 리눅스의 버전을 관리하기 위해 BitKeeper라고 하는 툴을 이용하고 있었는데요. 그러다 리눅스 개발자 중 한 명이 BitKeeper의 내부 동작원리를 분석하려고 했다가 리눅스 커뮤니티와 BitKeeper 사이가 안좋아지게 되었습니다. 이 때문에 BitKeeper는 리눅스에게 서비스를 유료화 시켰고 리누스 토발즈는 결국 버전 관리 프로그램을 직접 만들어버렸습니다. 이렇게 만들어진 것이 바로 깃입니다.
Github는
- 깃 허브는 깃을 통해 생성한 파일의 여러 버전들을 원격 저장소에 저장하도록 해주는 웹 서비스입니다.
- 깃 허브를 이용하면 버전관리 뿐만 아니라 전세계 개발자들과 함께 코드를 공유하며 협업할 수 있게 됩니다.
Git 초기 설정하기
# 사용자 정보 설정
git config --global user.name "(본인 이름)"
git config --global user.email "(본인 이메일)"
# 설정값 확인하기
git config --global user.name
git config --global user.email
# defaultBranch명 main으로 설정하기
git config --global init.defaultBranch main
Git 시작하기
git init
# Git으로 관리하고 싶은 폴더
git init
.git이라는 숨겨진 폴더가 생성되고 Git이 관리하는 모든 버전들이 이 폴더 안에 저장되게 된다.
yalco라는 폴더를 Git으로 버전관리 하려고 한다. git init 명령어를 치고나면 Git repository가 .git 폴더에서 초기화 되었다고 말해준다.
.git 폴더의 역할
aaa
우선 간단하게 yaml 파일 2개를 만들어보았다.
git status
Git 상태를 확인해 보자.
git status
보면 Untracked files에 방금 생성한 두 파일이 보인다. Untracked라는 말은 Git이 한 번도 관리해본 적 없는 파일이라는 말이다. 위의 두 yaml 파일을 이제 Git에게 맡겨보도록 하자.
git add
- git add는 Working directory(로컬 디렉토리)의 변경사항을 Staging Area(스냅샷을 찍기위한 무대)로 올림
- 나는 이러이러한 변경사항을 무대로 올리고(add), 스냅샷으로 찍어서 저장(commit)해둘거야
- 참고로 매번 git add 명령어의 대상이된 파일만 커밋되는 것은 아님 (tracked된 파일들은 git add 안하더라도 가장 최근에 커밋된 상태로 계속 커밋의 대상이됨. 이 내용은 아래의 카카오 프렌즈를 이용한 그림 참고) (이를 스냅샷 방식이라고 함 <-> 델타 방식과 대비)
# 특정 파일만 맡기려는 경우
git add "파일명"
# 생성/삭제/변경된 모든 파일을 맡기려는 경우
git add .
new file 이라는 표시가 뜬다. Git 입장에서 이 두 파일은 새로 생성되었기 때문이다.
이 상태에서 lions.yaml 파일의 manager를 Conan으로 변경해보자.
그리고 다시 Git 상태를 보면
Changes not staged for commit 라는 항목에 lions.yaml이 modified 되었다고 뜬다.
변경되었지만 아직 Staging Area에 올라가지 않은 경우이다.
Untracked files: 한 번도 Git이 관리한 적 없는 파일들
Changes to be committed: git add한 파일들
Changes not staged for commit: 수정하고 저장만 된 파일들
Git의 3가지 작업 영역
git add 되지 않은 파일들은 not staged 라고 한다. Git은 이렇게 어떤 파일이 최종적으로 하나의 버전으로 남기까지 3가지 영역을 오간다. 그림으로 보자.
아래 그림은 명령어를 통해 파일들이 오고가는 영역을 나타낸 것이다. Github를 포함하면 remote repository라는 영역도 추가된다.
다시 돌아가 보면 지금 우리의 파일 상태는 다음과 같았다.
여기서 이제 커밋을 해보자.
git commit
커멋이 되었다고 한다. 커밋이 되면 Local Repository에 하나의 버전으로 남게된다.
Local Repository는 git log 명령으로 확인할 수 있다.
git log
‘Create two files’라는 메시지로 잘 커밋이 되었다. 커밋된 버전은 f0c374e…이라는 식별자를 가지게 된다. 이 식별자를 이용해 나중에 버전을 되돌리거나 하는 등의 작업을 할 수 있다.
Git Graph Extention을 이용하면 Git log를 시각화 할 수 있다
위의 Uncommitted Changes는 무엇인지 보자.
Conan으로 변경하고 커밋에는 포함하지 않았었음 -> 가장 최근 커밋된 모습(현재 Staging Area의 모습)과의 diff를 보여준다
이 변경사항도 하나의 버전으로 만들어 보자.
.gitignore
비밀번호와 같은 민감한 정보는 Git에 의해 관리되지 않는 것이 낫다.
나중에 Github(Remote Repository)에 커밋을 저장(push)하면 다른 사람들에게 내 비밀번호가 공개될 수 있다.
이러한 경우 .gitignore라는 파일을 이용해 관리하고 싶지 않은 파일들을 표기해주면 된다.
git 명령어 정리
하나의 브랜치에서 사용하는 명령어
여러 브랜치 & 협업시 사용하는 명령어
다음 포스트에서는
지금까지는 계속 새로운 버전을 만들면서 앞으로 가는 방법만 배웠다.
다음 포스트에서는 과거로 돌아가거나(reset), 과거의 특정 버전에서 했던 행동을 돌이키는 방법(revert)을 알아보자.