Git Workflow의 이해

git 과 git -hub라는 것에 대해 알아보았으니 이제 Git의 명령어를 이해하기 전에 Git이 버전관리를 하는 flow에 대해 간단하게 알아보도록 하자. 흔히 3가지 영역 working direcotry , staging area, repository(local repo)이렇게들 많이 여역을 나누어 설명하는데 이것에 대해 자세햐게 알아보자.

Git status(git의 상태) : Commieted, Modified, Staged

Gitd에서 관리하는 파일은 modified, staged, commited 이 3가지 상태를 가지며, 우리가 터미널에서 git status로 상태를 조회 해볼때마다 매번 현지 이 상황의 상태에 대해 알려준다.

Git은 파일을 Commited, Modified, Staged 세가지 상태로 관리한다.
- commited : 데이터가 로컬 저장소에 안전하게 저장됐다는 것을 의미한다.
- modified : 수정한 파일을 아직 로컬 저장소에 commit하지 않은 것을 의미한다.
- staged : 현재 수정한 파일을 곧 Commit할 것이라고 표시한 상태를 의미한다.

Working Directory

지난 시간에 우리는 Git에서 버전이 저장되는 곳이 repository라고 하고 .git 이라고 하는 곳이다. (.git : repository)

우리가 파일을 만들고 버전을 우리가 만들다고 할때, 우리가 버전으로 만들어지기 전 단계라고 생각하면 된다.

즉, 현재 여러분의 컴퓨터(local computer)에 에 우리가 버전을 관리하겠다고 git을 만들어 놓은 폴더에서 우리가 작업하고 있는 현재 폴더로 수정할 파일들이 있는 디렉토리라 할 수 있다.

Working Directory의 모든 파일은 Tracked와 Untracked로 나뉜다.
- Tracked 파일은 이미 Snapshot에 포함돼 있던 파일이며, Unmodified, Modified, Staged 상태중 하나의 상태를 갖는다.
- Tracked 파일이 아닌 모든 파일은 Untracked 파일이다.

쉽게 말하면, 우리가 git에게 파일을 버전 관리해라고 우리가 시키야 하는데 그렇게 되지 않은 파일들을 untracked file이라고 하고 이미 관리가 되고 있는 것은 Tracked field인 것이다.

Staging Area(Index)

Index라고도 부르며 , 버전을 만들려고 준비중인 파일들의 스냅샷의 데이터가 저장된 곳이라고 생각하면 된다.

즉, working director(working tree)와 저장소 사이에 존재하는 가상의 준비 영역(staging Area)f라고 생각하면 된다.

Local repository

Git directory가 있는 곳을 말한다. Git이 프로젝트의 메타 데이터와 객체 오브젝트를 저장하는 곳을 말한다 ( .git 파일이 있는 곳) 쉽게 생각하면, staging Area를 거쳐 만들어진 버전들이 저장된 곳 이라고 생각하면 된다.

Git 명령어 수행시 과정

1. working directory(working tree라고도 부름)에서 파일을 수정한다.
2. git add 명령어를 통해 staging area로 보내어 깃이 관리하게 한다.
3. Staging Area에 파일을 Stage 해서 commit(커밋)할 냅샷을 만든다. 모든 파일을 추가할 수도 있고 선택하여 추가할 수도 있다.(모든 파일 추가시 git commit -a)
4. Staging Area에 있는 파일들을 커밋해서 Git 디렉토리에 영구적인 스냅샷으로 저장한다.

Git 기초 명령어

지금쯤이면 git의 working flow를 이해했을 테니 간단하게 자주쓰이는 명령어들만 정리해보도록 하자.

Git add

Git add file_name 으로 사용하며, working tree에서 staging area로 넘겨서 깃에게 관리를 맡기고 싶을 때 사용.

git add file.txt  << file.txt 라는 파일을 working tree에서 staging area로 넘김
git add . <== . 을 입력할 시 그 디렉토리 안에 있는 모든 파일들을 관리하도록 staging area로 넘김
git add -all <= git add .과 같은 역활( 작업파일의 모든 수정된 파일을 준비 영역으로 보냄)
git add -u <== u 옵션을 줄 경우 이전에 커밋한적 있는 파일(tracked file)만을 모두 staging area에 등록
git add --update <-- 기존(Tracked files)들을 준비영역으로 이동시킴

Git commit

Git commit -m " " 으로 사용하며, staging area(index)에서 저장소로 넘겨서 깃에게 넘길때 사용한다. -m 옵션은 message줄임말로 커밋한 내역에 대해 코멘트를 하게끔 해주는 옵션이다.

일반적으로 한줄은 -m을 사용하며 커밋에 대한 상세 내용이 길어질때는, git commit 후 엔터를 치면 기본 에디터 (vim or nano)로 연결되어 상세 메세지를 쓸수 있게 해준다.

git commit  <== untracked file과 tracked file 을 vim으로 보여줌
git commit -m "커밋 메세지"
git commit --amend <== 완료한 커밋내역을 수정하고 싶을 때 에디터에서 수정 후 저장
git commit -a -m "커밋 메세지" <== Tracked file 모두를 stage영역에 add한다. (git add를 안하더라도 모든 파일을 할 예정이라면 이 옵션을 사용하면 자동적으로 올려줌)

Git Status

Git status 으로 사용하며, working tree의 status를 보여준다. 한 100번도 넘게 사용할 명령어니 기억해둘 것.

git status

Git Push

Git push <저장소명> <브랜치명>으로 사용하며, 로컬 저장소에 저장된 코드 변경이력들을 원격 저장소로 날리는 작업시 사용.

git push orgin master <-- master브랜치에 origin이라는 원격 저장소에 올린다.(주로 홀로 작업시 사용)
git push origin feature/sign-up <-- feature/sign-up의 브랜치에 남겨놓은 코드 변경 이력을 origin이라는 원격저장소에 올린다. (우리가 주로 쓸 명령어)
git push -u origin feature/sing-up <-- u옵션 사용시 최초 한번만 저장소 브랜치명 입력후 이후 push는 모든 인자 생력 가능

Git remote

등록된 리모트 저장소 이름을 보여준다. git clone하면 주로 origin 으로 설정되지만 그래도 확인이 필요하면 사용 할 수도 있음.

git remote [-v] // 원격 저장소 정보 확인
git remote show <remote명> //리모트 저장소 살펴보기

git remote add [원하는 저장소 이름][url] // 원격 저장소와 연결해줌( git remote add origin master 생각해보면 이해됨)

git remote rename <existed_name> <new_name> //remote repository 이름 변경

git remote remove < remote-name> //remote repository 삭제

git remote  ->> origin
git remote remove origin <== origin이라는 이름의 원격저장소를 지우고 싶을때 

Git clone

말 그대로 복제해오는 것으로, 원격 저장소를 복제하는 것으로 git hub의 원격저장소를 복제해올때 최초 한번 사용한다. git clone < git_path> 이렇게 사용.

git clone하면 주로 origin 으로 설정되지만 그래도 확인이 필요하면 git remote로 확인사살 가능

git clone <path>

Git Pull

Git에서 최신 업데이트 상황을 반영하고 싶을 때 사용하며 원격 저장소에서 로컬 저장소로 업데이트 할 때 사용한다. 원격 저장소에서 최신 업데이트 상황을 가져와서 자동으로 merge해주는 기능으로

Git pull = git fetch + giet merge FETCH_HEAD로 이해하면 된다.

협업 과정에서 프로젝트의 최신 코드를 local로 가져오는 역활로 많이 사용하며, 자신이 같이 협업 중이라면 꼭 pull 이나 fetch를 먼저하는 습관을 들이도록 하자.

git pull <원격 저장소명> <브랜치명>
ex ==> git pull origin master 

Git fetch

Git에서 최신 업데이트 상황을 반영하고 싶을 때 사용하며 원격 저장소에서 로컬 저장소로 업데이트 할 때 사용하며 pull과 다르게 자동 merge는 아님.

git fetch <원하는 저장소 이름> 으로 사용.

git fetch origin

이미지 출처:

https://dimdim.tistory.com/entry/GIT

https://dev.to/mollynem/git-github--workflow-fundamentals-5496
https://honeystone.com/blog/what-combining-gitflow-and-phabricator-means-honeystone