Git은 Commit 할 때, 총 3가지 영역을 바탕으로 작동합니다.
- Working Directory : 내가 작업하고 있는 프로젝트의 디렉토리
- Staging Area : 커밋을 하기 위해 $ git add 명령어로 추가한 파일들이 모여있는 공간
- Repository : 커밋들이 모여있는 저장소
열심히 코드를 작성하다가 커밋을 해야하는 순간이 오면 git add .를 통해 커밋할 파일들을 추가합니다.
이 파일은 바로 Repository에 올라가지 않고, Staging Area에 올라가게 됩니다.
Staging Area에 추가한 파일들을 Commit을 한다면 최종적으로 저장소(Repository)로 저장되게 됩니다.
Git 에서 세 가지 영역
Git 프로젝트는 Git 디렉터리, 워킹 디렉터리, Staging Area 라는 세 가지 영역을 갖게 됩니다.
Git 프로젝트에서 파일들은 아래 세 가지 영역별로 다양한 상태를 가지게 됩니다.
워킹 디렉터리(워킹 트리)
워킹 디렉터리는 Git 디렉터리에서 특정 버전을 Checkout 해온 것입니다.
또한 우리는 이곳에서 프로젝트 작업(개발 및 수정)을 진행하게 됩니다.
쉽게 말하면 내가 작업하고 있는 프로젝트의 디렉터리를 뜻합니다. Git Directory는 지금 작업하는 디스크에 있고 그 디렉터리 안에 압축된 데이터베이스에서 파일을 가져와 Working Directory를 만듭니다.
git clone 'github repo https 주소'
Staging Area
또 다른 하나는 Stating Area이며, 실제로는 Git 디렉터리에 파일로 존재합니다. Index 영역이라고도 하지만 Staging Area가 표준 명칭으로 자리 잡힌 상태입니다.
Staing Area는 워킹트리에서 작업한 내용이 Git 디렉터리에 Commit 되기 전에 거쳐가는 공간이지만, 이곳을 거치지 않고 바로 Commit 될 수 있습니다.
스테이징 영역은 작업 디렉토리와 Git 저장소의 변경 이력 사이에 징검다리 역할을 하는데요.
작업 디렉토리는 아직 커밋할 준비가 안된 변경 내용을 자유롭게 수정할 수 있는 공간인 반면에,
스테이징 영역은 커밋할 준비가 된 변경 내용이 Git 저장소에 기록되기 전에 대기하는 장소라고 생각할 수 있습니다.
git add 명령어를 사용하면 현재 작업 디렉토리에 있는 모든 또는 일부 변경 내용을 스테이징 영역으로 이동시킬 수 있습니다.
1. git add . (현재 디렉터리에 있는 모든 디렉터리 및 파일을 staging area로 보냄)
2. git add /경로/추가할 파일만 지정 가능)
3. git status (staging area에 잘 들어갔는지 확인)
git status는 크게 3개의 영역으로 구성 되어 있습니다.
- Changes to be committed: 이 영역은 스테이징 영역에 넘어가 있는 변경 내용을 보여줍니다.
- Changes not staged for commit: 이 영역은 아직 워킹 디렉토리에 있는 변경 내용을 보여줍니다.
- Untracked files: 이 영역도 아직 워킹 디렉토리에 있는 아직 한 번도 해당 Git 저장소가 관리한 적이 없는 새로운 파일을 보여줍니다.
Git 디렉터리(.git 디렉터리, 깃 저장소)
Git 디렉터리는 최초에 git init 명령으로 프로젝트가 Git 프로젝트로 만들어질 때 .git이라는 이름으로 생성되며, Git 프로젝트의 모든 메타데이터와 객체 데이터베이스가 이곳에 저장됩니다. 따라서 가장 중요한 공간이며, Git의 핵심이라고 할 수 있습니다. 또한 Clone으로 원격 저장소를 복사해서 가져올 때 이 .git 디렉터리를 만들고 원격 저장소의 모든 데이터를 복사하여 가져옵니다.
Git으로 하는 작업
Git으로 하는 작업은 기본적으로 다음과 같습니다.
1. 워킹 디렉터리에서 파일을 수정합니다.
2. Staing Area에 파일을 Stage 하여 커밋할 스냅샷(버전)을 만듭니다.
3. Staing Area에 있는 파일들을 Commit 하여 Git 저장소에 영구적으로 스냅샷을 저장합니다.
영역별 상태
영역별 상태는 단순히 세 영역을 구분지어 설명하자면 다음과 같으며, 세밀하게 들어가면 더욱 복합적인 상태들이 존재합니다. 다음은 파일들의 상태가 영역별로 어떤 상태로 존재하는지를 나타냅니다.
1. Git 디렉터리에 존재하는 파일들은 Committed 상태입니다.
2. Git 디렉터리로부터 워킹 트리에 Checkout 하고 파일을 수정하고 Staging Area에 추가했다면 Staged 상태입니다.
3. Git 디렉터리로부터 워킹 트리에 Checkout 하고 파일을 수정했지만 아직 Staging Area에 추가하지 않은 경우 Modified 상태입니다.
Git의 Staging Area는 어떤 점이 유용한가
Git에는 Staging Area라는 공간이 있다.
어떤 변경사항이 저장소에 커밋되기 전에, 반드시 거쳐야만 하는 중간단계이다.
다른 버전관리 도구에는 이에 정확히 대응하는 것은 없다.
저장소가 추적하는(관심의 대상이 되는) 파일들의 목록을 유지하고, 그 파일들에 대한 메타데이터를 관리하는 것은 다른 저장소들도 하는 일이지만, Git 처럼 커밋될 예정인 파일의 내용들까지 기억하지는 않는다.
이 Staging Area의 존재는 처음 Git을 사용하는 입장에서는 그저 불편만 안겨주고 이해만 더디게 만들어주는 목적불명의 무언가에 지나지 않는다. 다른 SCM에선 파일을 고치고 바로 커밋하면 되었는데, Git은 반드시 그 전에 add를 해 줘야 한다. 이런 비용을 감수하면서까지 Git이 Staging Area라는 공간을 사용자들에게 노출시키고 있는 이유는 무엇일까. 어떤 상황에서 Staging Area가 유용한지 살펴보면서 이해해보자.
일부분만 커밋할 때
Working directory에서 코드를 고칠 때는 자유롭게 고치고 싶다.
하지만 커밋할때는 일부분만 하고 싶다. 이를 가능하게 하려면 커밋할 때 working directory 전체가 아니라 부분만 커밋하면 될 것이다.
staging area라는 것이 없다고 가정해보자. ‘커밋될 예정인 내용들’을 디스크에 저장해 둘 공간이 없으므로, 커밋할 때 어느 부분을 커밋할지 한번에 결정해야 한다.
한번에 어렵지 않게 결정할 수도 있지만 시간을 들여 생각해야 할 수도 있다.
시간을 들여 조금씩 커밋할 부분을 결정해 나간다고 하면, 그 시간동엔 나의 결정사항들은 메모리상에 존재해야 한다.
메모리에 올라와있는 정보는 디스크에 저장되어 있는 정보보다 다루기 까다롭다.
Staging Area에 저장되어있는 ‘곧 커밋될 예정인 내용’들은 쉽게 git diff --staged등의 명령으로 확인할 수 있겠지만, 이것이 메모리에 올라와있는 상태라면, 해당 메모리 영역을 사용하고 있는 프로세스를 찾아서 물어봐야 알 수 있다.
실수로 그 프로세스를 죽였다면 공들여 커밋을 준비하던 것이 허사가 된다.
(커밋을 깔끔하게 만드는데 과도하게 공을 들인다는 생각이 드는가? 하지만 이런 개발자들이 실제로 있다)
충돌을 해결할 때
충돌을 해결해야 하는 상황에서도 비슷한 문제가 있다.
5개의 파일을 merge(병합)했는데 그 중 2개에서 충돌이 발생했다고 해 보자.
3개의 파일은 그냥 커밋하면 되고 2개는 충돌을 해소(resolve)해줘야한다.
여기서도 위와 같은 문제가 생긴다.
큰 규모의 충돌이 발생한 경우 이를 해결하는 것은 상당히 시간이 들어가는 일이고, 이를 위한 작업 데이터를 메모리에만 올려놓는 것은 참으로 불안하다.
따라서 이 정보 역시 Staging Area와 같이 디스크의 어떤 공간에 저장해두는 것이 훨씬 좋을 것이다.
이것은 Staging Area가 없는 Subversion이라도 마찬가지다.
서브버전은 어떤 파일이 충돌했는지 ‘파일 상태’를 기억한다. 그러나 이보다는 Git의 방식이 더 낫다.
서브버전은 파일 단위로 충돌 여부를 기억하기 때문에, 파일의 일부분만 충돌을 해소한 후 커밋하는 것은 매우 어렵기 때문이다. Git이라면 간단하다.
충돌이 발생한 파일에서, 필요한 만큼만 충돌을 해소하고 그 부분만 add하여 커밋하면 된다.
커밋 다시하기
commit --amend 명령으로 커밋을 다시 할 때도 Staging Area의 존재는 빛을 발한다.
커밋을 다시 할 때 로그메시지만 고치는 것이 아니라 파일들도 좀 고치고 싶다면, commit --amend 전에 파일을 고쳐서 Staging Area에 add하기만 하면 된다. Staging Area가 없었다면 commit --amend시에 Git에게 다른 방법으로 패치를 전달해주었어야 했을 것이다.
요약
Staging Area는 단순하지만 유용한 저장공간이다.
많은 Git의 명령들이 Staging Area를 활용하여 Git을 더욱 생산적인 도구로 만들어준다.
물론 Staging Area라는 생소한 개념이 Git의 진입장벽을 더욱 높이는 것은 사실이지만, 그럼에도 불구하고
Git을 즐겨쓰는 많은 개발자들에게 Staging Area는 여전히 필수불가결한 존재이다.
누군가 이해하기 쉬우면서도 현 Staging Area에 대한 요구를 흡수할(혹은 불필요하게 만들) 수 있는 어떤 개념을 만들어낸다면 몰라도 그 전까지는 Git의 핵심 기능이자 특징으로서의 지위가 변하는 일은 없을 것이다.
Git 설치 방법 (CentOS 7 기준)
repo 설치에 필요한 명령어 복사하여, 터미널에 붙여넣거나 수기로 입력한 다음 Enter키를 눌러준다.
(인터넷이 된다면) yum install https://repo.ius.io/ius-release-el7.rpm https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
yum install -y git
1. Github 계정 생성
2. Github repository 생성
3. Git 설치 및 설정
1) 터미널에서 명령어 입력
git --version
git clone 'github repo https 주소'
2) git token
Github Settings - Developer settings - Personal access tockens(classic)
repo 권한 부여, 생성된 토큰은 잘 보관하기
git password를 요구할 경우 git token 사용
3) git 초기 설정
# User_name 설정
git config --global user.name "your_name"
# User_email 설정
git config --global user.email "your_email"
# 설정 확인
git config --list
4. Github에 처음 코드 업로드
1) 초기화(처음 업로드 할 때만 해주면 된다)
git init
2) 추가할 파일 add
1. git add . (현재 디렉터리 안에 있는 파일을 모두 추가)
2. git add /경로/추가할 파일 (파일 지정해서 추가)
3) 상태 확인(add가 잘 됐는지)
git status
4) commit(업로드명 설정)
# 같은 이름의 파일을 변경해서 업로드할 때 구분하기 힘들기 때문에
# github에 올릴 때 commit을 설정하는 것이다
ex) git commit -m "first commit"
5) github repository와 연결
# https://github.com/nkw/testproject.git 이 repository로
# 내 소스코드를 보낸다는 의미
git remote add origin https://github.com/nkw/testproject.git
6) 연결 확인
git remote -v
7) 업로드 하기
# git branch 확인
git branch
# git push
git push origin "branch 명"
ex) git push origin master
Username for 'namgungu': [깃허브 네임]
Password for '~~~~~~~': [이전에 만든 token 값]
5. github 새로고침
업로드한 파일이 github repository에 올라가있는걸 볼 수 있다.
6. 변경사항 적용 후 업로드
yml 파일 변경사항 적용 후 저장
git pull origin master(push전에는 push 해주기)
git add .
git status
git commit -m "second commit"
git push origin master