1. git & github란?

Version Control System(VCS). 최신 코드에 문제가 있어 이전 코드로 돌리거나, 팀 단위 개발에서 여러 수정 사항을 반영하여 하나의 버전으로 관리하게 해주는 시스템이다.

🌈 VCS의 기능

• 코드 변경 history 기록 및 관리
• 필요시 이전 상태로 rollback
• 팀단위 개발시 체계적이고 효과적인 협업

Git - 분산 버전 관리 툴. 소스 코드의 변경 history를 관리할 수 있다. 여기서 version은 소스 코드(코드 파일, server.js 같은)의 버전을 뜻한다.

Github - git을 사용하는 프로젝트를 지원하는 웹호스팅 서비스. 로컬에 버전 관리를 위한 데이터베이스 서버를 만들 필요 없이, github로 필요한 소스 코드만 다운 받는다. github는 중앙 서버 외에도 코드 리뷰, 문서 생성 및 관리, 프로젝트 운영 등 여러 기능을 제공한다.

- VCS server

Version database를 관리하는 서버. 중앙에서 저장하는지, 분산해서 저장하는지에 다르다.

중앙 버전관리 시스템(central VCS)

중앙 서버에 수정된 내용을 올려 팀원과 정보를 공유하는 것을 가능하게 한다. 날짜 등 메타 정보는 모두 서버에서 관리하고, 최신 버전의 코드들만 중앙 서버에서 다운로드해 작업하는 형식이다.

분산 버전관리 시스템(Distributed VCS)

Central VCS는 서버가 다운되면 매우 큰일난다. Distributed VCS를 쓰게 되면 각 개발자의 컴퓨터도 모든 메타 정보를 가지고 있어 중앙 서버에 문제가 생겨도 개발자 컴퓨터를 통해 복구가 가능하게 된다.

2. repository

간단하게 말하면 저장소이다. 로컬과 원격으로 구분된다. 보통 로컬 리포에서 작업을 하다 내 소스 코드를 공개할때 원격 리포에 업로드(push)하게 된다

2.1 local & remote

local repo

내 컴퓨터에 저장되는 개인 전용 저장소이다. 혼자서 작업하는 경우 원격 저장소를 사용하는 경우가 많지 않다. git이 관리하는 세 그루의 나무로 구성되어 있다.

• working directory: 실제 파일로 이루어져 있다.
• index(stage): 준비영역의 역할을 한다. 저장소에 업로드하기 전에 저장하고 원하는 파일만 업로드하고 싶을 때 쓴다 - 이를 staging이라고 한다.
• head: 최종 확정본(commit)을 나타낸다.

remote repo

여러 사람이 공유하기 위한 저장소로, 클라우드와 비슷한 개념이다. 원격저장소는 소스 코드를 백업하고 다른사람과 협업하기 위해 사용한다.

2.2 명령어

- git init

프로젝트를 git repository로 만들기 위해서 사용하는 명령어. 여기서 프로젝트(project)라 함은 개발하고자 하는 소스코드들이 있는 디렉토리를 말한다. git init을 해서 git repo로 만들어야 git으로 버전 관리가 시작된다.

/dir $ git init

- git remote add origin (link)

원격 저장소를 로컬 저장소에 저장하는 명령어

❯ git remote add origin https://github.com/yenilee/first.git

- git remote -v

현재 원격 저장소의 상태를 확인

❯ git remote -v
origin	https://github.com/wecode-bootcamp-korea/git4.git (fetch)
origin	https://github.com/wecode-bootcamp-korea/git4.git (push)

2.3 clone & pull

- git pull

다른 사람들이 추가한 코드가 반영된 가장 최신버전의 코드를 가져오는 것 (= git fetch + git merged). fetch는 프로젝트의 메타 정보를 가져오는 것이고, pull을 해야 최신으로 업데이트 된 코드 정보를 가져올 수 있다.

원하는 branch를 가져오기 위해서는 branch name을 지정해서 주어야 한다.

#master branch pull 해오기 
git pull origin master 

- git clone

remote repo에서 local repo로 소스 코드를 복사해서 가져오는 것. 같이 작업해서 합치는 기능보다는 코드를 복사하는 용도에 가까운 것 같다. github의 url을 통해 복사하는 방법은 다음과 같다.

git clone (github에서 복사한 원격 저장소의 링크)

- git fork

remote repo에서 github 계정으로 소스 코드를 복사하는 것

3. branch

버전 관리를 할 때, git은 바뀐 부분만(diff) 저장하는게 아니라 파일의 스냅샷(snapshot)을 시간순으로 저장한다. 그래서 현재의 스냅샷과 이전 스냅샷을 비교하며 변경 사항을 보는 것이다. 개발자가 중앙 서버에서 리포를 체크아웃하면 해당 리포의 특정한 시점의 스냅샷을 받게된다.

🌈 branch에서 일어나는 일들을 미리 요약해보면

• 기준이 되는 마스터 브랜치에 체크아웃checkout하고
• 내 브랜치feature branch를 만든 다음
• 내용을 수정하고 add, commit, push하고
• pull request가 수락되면 마스터 브랜치 반영merge !

3.1 명령어

- 생성

git branch feature/yeni # 만들기만 하고 이동하지 않음
git checkout -b newfeature # 새로 만든 다음 바로 이동 

- 이동

git checkout master
git checkout feature/yeni

- 확인

내가 어떤 브랜치에 있는지 확인하는 것. master branch에서 작업하면 안 되고 branch에서 작업한 뒤에 Merge하는 단계를 거쳐야 한다.

git branch -v 

- 제거

git branch -d new_feature 

4. git flow

4.1 modified

코드가 수정되었지만 아직 저장되지(commited) 않은 상태를 말한다. 코드를 수정하고 상태를 확인하면 modified: 수정된 파일이라고 붉은 글씨가 뜬다. 변경 사항이 stage되지 않았다고 나온다.

❯ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   README.md

4.2 staged

위 상태에서 staged 되면 modified 파일의 글씨가 초록색으로 변하고, 내가 수정한 것이 commit 될 것이라고 mark한 상태로변한다.

❯ git add README.md
❯ git status
On branch feature/yeni
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   README.md

- git add(=staging)

수정한 파일을 staged 상태로 옮기고자 할때 사용하는 명령어. 또 git repo에 새로이 추가된 파일들을 staged 상태로 옮길때도 사용된다. 새로이 추가된 파일들은 "untracked" 파일 이라고 하는데, git에서는 이들도 수정 사항으로 본다.

$ git add newfile #  newfile을 index에 등록하기
$ git add . # 모든 파일을 index에 등록하기

- git restore --staged

unstage 해서 다시 수정하고 싶을 때 사용하는 명령어. 계속 말하지만 commit 하면 되돌리는게 번거롭기 때문에 확정이 아니라면 stage - unstage 하면서 계속 수정해야 한다!

4.3 commited

수정 사항들이 메시지와 함께 local git에 저장된 상태. commit하게 되면 히스토리에 남고, 추가 수정사항이 있을 때 되돌리는게 까다로울 수 있어(로그를 확인해서 시간 여행을 해야 하는...) staged 단계가 필요한 것이다.

❯ git commit -m "problem solved"
[feature/yeni a17c25c] problem solved

- git commit -m 'message'

수정사항을 local에 메시지와 함께 저장한다. remote repo에 있는 마스터에 merge하기 전 상태.

- git push origin branch

merge하기 위해 branch를 remote repo에 등록한 상태. github에 가보면 나의 branch에서 저장된 변경 사항을 확인할 수 있고, master에 적용시키기 위해서는 pull request를 해야 한다.

❯ git push origin feature/yeni
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 281 bytes | 281.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To https://github.com/wecode-bootcamp-korea/git4.git
   90d9e7c..119bb30  feature/yeni -> feature/yeni

위 git push origin feature/yeni 에서 origin은 remote에서 설정한 저장소로 이동하게 한다. feature는 보통 master에서 branch를 만들 때 사용하는 이름이다.

4.4 conflict

협업자끼리 같은 코드를 다르게 고쳤을 경우 발생한다. 선 Merge 후 pull-request를 하게 되면, 합쳤을 때 conflict가 발생하는 것을 사전에 알 수 있어 어떤 코드를 남길지 정하고 남길 코드를 정해 commit하면 된다.

만약 내가 올린 pull request가 conflict 되는 상황이면, branch를 pull하려고 했을 때 아래와 같이 merge가 fail했다고 뜬다.

❯ git checkout feature/yeni
❯ git pull origin master
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (1/1), done.
From https://github.com/wecode-bootcamp-korea/git4
 * branch            master     -> FETCH_HEAD
   6dc29c7..bf5008d  master     -> origin/master
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.