Slow but steady wins the race

-Open UP에서 공개SW 실습교육 2일차-

1. Fork 저장소와 오픈소스 GitHub 저장소 설정

**upstream으로 등록 <팀프로젝트 깃허브 저장소>**

git remote add upstream (오픈소스 github 프로젝트 URL)

upstream을 fork한 저장소의 url을 넣지 않도로 주의*

현재 등록된 저장소 확인

git remote -v

2. Rebase가 필요한 상황

팀프로젝트 498commits (를 가져온 내용) => base commits 

base commits위에 다른 499,500번째 commit을 만들어내고, 이 달라진 부분을 제출할 수 있음

Q. base는 항상 똑같은가?

A. No. 팀프로젝트가 혼자 하는 것이 아니기 때문에, 계속 바뀌게 된다. 

Rebase란?

- base를 교체하는 방식

<git rebase vs merge>

기능에 집착하면 이 둘의 차이를 이해하기 어렵다.. 

"rebase이 왜 필요한지", "협업 과정"에 중점을 두고 이해할 것

혼자 local branch 상에서 rebase는 잘 쓰지 않음(거의 없음)

아래와 같은 사고 과정을 통해 이해해보면,, 

같은 파일 내에서 다른 사람 것이 먼저 Merge가 되는 경우, 다른 사람의 commit 과 나의 commit이 충돌이 될 수 있음!

Q. 왜 충돌이 발생할까?

A. 같은 file을 건드렸기 때문에

Q. 충돌이 발생하지 않는다면, 왜 발생하지 않을까?

A. 다른 File을 건드려서 

Q. 충돌이 발생할 확률이 높을까?

A. 발생할 확률이 낮음. 같이 협업을 하기 위해 폴더나 파일을 잘 나눈다는 등, 이미 설계가 잘 되어 있음. (이미 설계적으로 방지가 되어있음) 하나의 파일을 몇천명의 사람들이 수정해서  충돌이 발생하는 경우는 rebase의 할아버지가 나타나도 해결할수없음ㅋㅋ 잘 된 분업화, 모듈화, 등등 잘 쪼개놨기 때문에 충돌이 발생할 확률이 낮음

Q. 충돌이 발생하는 상황

A. Rebase 요청 -> 최신 역사로 베이스를 업데이트 

<Rebase를 수행하는 과정> 

fetch는 upstream에 있는 최신 commit들을 가져오는 것! 같이 협업하기 때문에, 다른 사람들의 작업을 가져오는 것은 항상 있는 일

즉, fetch는 rebase와 관련 X, 단순히 가져오는 역할!

1. pull = fetch +merge

(.git 폴더 히스토리 창고에다 넣어둔다)

2. git fetch upstream master 

(내부 브랜치가 자동 생성됨 -> "upstream/master" ) 

3. git rebase upstream/master

Q. 이 명령어에서 문제가 생길 수 있을까?

A. "File이 같은지"가 중요!! 아래 빨간색과 보라색이 파일이 같을 경우, 충돌이 발생함

** base가 바뀌는 부분과 commit간의 충돌이 나는 부분을 구분해야함! 

4. git push origin (branch 명) --f

Fork 부분을 갱신하는 작업

-f : force 옵션

force는 쓰지 말라는데, 왜 쓰면 안 되는 지가 중요!

공식 오픈소스 프로젝트에서는 base를 갱신한다던지, 중간 commit을 빼버린다던지, 등등 문제가 발생할 수 있기 때문에 "Force Push"를 잘 사용하지 않음

하지만, Fork한 프로젝트에서는 "Force Push" 사용 가능, Force Push는 달라진 점만 push하기 때문에 자주 사용

fork 프로젝트 (commit 1, commit 2)

local 프로젝트 (commit 1, commit 2, commit 3)

이렇게 commit이 새롭게 추가된 경우에는 push가 가능하지만,,

fork 프로젝트 (commit 1, commit 2)

local 프로젝트 (commit 1, commit 2-1, commit 3)

이렇게 중간에 commit이 수정된 경우에는 force push가 필요함!

※ Stash vs Checkout

★ Stash 

- 수정내용 임시 저장, 복구 가능

- keeping 느낌

- 버그 수정 (before/after 비교 가능) 

★ Checkout 

- git checkout -- 파일명

파일 원상 복구(수정 내용 완전히 날림)

- git checkout -- 브랜치명"

도서관(.git 히스토리 창고)에서 책을 대출받다" 이런 느낌 

<Stash : 수정 내용 임시 저장>

1. git diff(수정내용 확인)

2. 임시저장

git stash

3. 임시저장 복구

git stash pop

<Checkout : 수정 파일 복구하기>

1. git diff (수정 내용 확인)

2. 수정 전 상태로 복구

git checkout -- (파일이름)

- 완전히 원상복구

<Branch란?>

" 같은 폴더 다른 세상" 

- branch에서 뭘하든 master에는 적용이 되지 않음

- 분할된 작업을 진행할 수 있음! 

- 즉, Git을 쓰는 이유가 됨

1. Branch 생성

git checkout -b (branch 이름)
# git checkout -b fix-mnist

- 작업의 명칭으로 branch 생성해주는 것이 좋음

2. 폴더 생성 및 수정작업

hello.txt를 만들고 commit 해보면.. 

3. 브랜치를 master branch로 변경하고 확인해보면

- hello.txt는 없는 것을 확인할 수 있음

4. 브랜치 삭제 

- master 브랜치에서 진행

git branch -D fix-mnist

< Branch에서 소스파일 수정하고 확인하기 >

1. 브랜치 생성

2. 수정할 파일 확인 

3. 원하는 편집기(vim, emacs, nano, 등으로 파일 수정하기

- nano로 실습

nano mnist/main.py

- 수정

- mac에서 nano 편집기 사용법

(1) 저장하기 : control + o

(2) 나가기 : control + x

4. 소스 파일 수정한 내용 확인하기 

git diff

5. commit 할 준비

(1) git status 명령어를 통해 "not staged" 확인

(2) git add 명령어 실행 

git add mnist/main.py

(참고) add 취소

git reset

6. commit하기 

git commit -m "수정한 내용"

7. git show 명령어를 통해 commit이 잘 되었는지 확인 

8. git status 명령어를 통해 현재 소스파일 상태 확인하기

- "nothing to commit, working tree clean" 확인

    == 현재 변화분도 없고 commit할 것이 없음 

(참고) 서명과 함께 commit

git commit -sm "커밋 메시지"

- "-s"를 함께 넣어 명령 실행

- git show를 실행하면 아래와 같이 "Signed-off-by :~~"가 표시됨

- Why 사용?  license에 관련하여 인식하였음을 표시

- 실제로는 "Contributor License Agreements" 많이 사용 

   (https://opensource.google/documentation/reference/cla) (https://cla.developers.google.com/clas) 

(참고) commit 수정하기

- 가장 최신 commit만 수정 가능

- 변경분을 추가하지않고 메시지만 추가할 수 있고, 수정하는 순간 commit ID 도 변경됨

git commit --amend

(참고) commit 삭제하기

- 최상위 commit부터 지울 수 있음(중간 X) 

# 생성한 commit 정보 확인하기
$ git log --oneline -3

# 최상위 commit부터 첫번째(1) 내용 삭제하기
$ git reset --hard HEAD~1

< Pull-Requset 하는 과정>

1. git branch 명령어를 통해 branch 확인하기

2. Fork 저장소에 업로드에서 commit 제출(pull-request) 준비하기 (push 하기)

git push origin (branch명)

token 만들어서 username, password 에 토큰 붙여넣기

3. Fork저장소(Github)에서 commit 제출하기

- 해당 branch에서 "Open pull request" 누르기

--> 현재까지의 과정은 아래와 같다

< 개발자 별 commit 순위 확인 >

git shortlog -sn | nl

- s 옵션 : 개발자별 commit 개수 요약

- n 옵션 : 개발자별 commit 개수 순위 정리 

- nl 명령 : line number 명시 (순위 표시 용으로 사용) 

- 해당 부분은 gui 로 확인 가능 ( Github 해당 프로젝트 -> Insights -> Contributors) 

Q. 왜 GUI로 보지않고 CLI 로 보는가? 

A. 전체의 history보다 최근의 history,  특정 폴더에 집중적으로, 등등 확인하기 위해 

이렇게 세부적인 사항은 GUI로 확인할 수 없음 

즉, 세부적인 경향 파악을 위해 GUI가 아닌 CLI를 사용

(1) 특정 폴더에 집중적으로 순위 확인 

git shortlog -sn -- (디렉토리명)

(2) 특정 폴더 + 특정날짜 이후(최근) 순위 확인 

git shortlog -sn --after=2019-01-01 -- mnist

(3) merge commit 제거한 순위 확인

git shortlog -sn --no-merges

* commit : 소스 변경 히스토리 단위

* merge commit : "병합이 되었음을 나타내는 빈 commit" 

< 전체 소스파일 수정내역 개수 (commit 개수) 확인 >

git log --oneline | wc -l

- wc -l 명령 : (파일) 라인 수 개수 측정

- GUI로도 확인 가능 -> "숫자"commits

- 팀 프로젝트의 commit 전체 개수 == base commit이라고 부름 

Q. base commit 은 계속 똑같은가? 

A. No. 당연히 변경됨. **우리는 base commit 위에 작업을 함**

(1) 전체 소스파일 수정내역 리스트 확인

git log --oneline

- 실행시 나오는 노란색글씨 : 소스파일 수정내역 고유한 ID (SHA1 해시값)

(2)전체 소스파일 수정내역(commit) 자세히 확인

git log -p

(3) 특정 날짜 기준 수정내역(commit) 확인 

git log --oneline --after=2020-01-01 --before=2020-06-30

(4) 특정 날짜 기준 수정내역(commit) 개수 확인

git log --oneline --after=2020-06-01 --before=2020-06-30 | wc

(5) 특정 날짜+파일/폴더 기준 수정내역(commit) 개수 확인

git log --oneline --after=2020-06-01 --before=2020-06-30 -- mnist/

- 협업 시 특정파일에 집중해서 개발하므로, 필요! 

(6) 최근이 아닌 옛날 것부터 소스파일 수정내역(commit) 확인

git log --oneline --reverse

* reverse 사용 시 주의 

- 첫번째꺼는 옛날꺼부터 3개

- 두번째 명령은 최신꺼 3개 중 거꾸로! 

< 특정 ID의 소스파일 수정 내역(commit) 내용 확인 >

git show (ID)

- commit 단위로 어떤 것을 수정했는지 확인할 수 있음

(1) 특정 ID의 소스파일 수정 파일 확인

git show 6c8e2ba | grep "diff --git"

(2) 특정 ID의 소스파일 수정 파일 개수 확인

git show 6c8e2ba | grep "diff --git" | wc -l

(3)전체 소스파일 수정내역(commit) 리스트에서, Merge commit 수정내역 확인

-Open UP에서 공개SW 실습교육 1일차-

<협업과정>

1. 참여할 프로젝트 Fork 복사

2. Fork한 프로젝트를 다운로드(Clone)

3. 프로젝트 분석(개발 경향 파악) : https://bskwak.tistory.com/243 참고 

4. config 설정 (저자(author) 정보) 

<5~7 branch 에서 작업 -> https://bskwak.tistory.com/244 참고>

5. commit 설정( 소스코드 수정분)

6. Fork한 프로젝트에 commit 업로드 ( == Push) 

7. 참여할 프로젝트에 commit 제출 ( == Pull-Request : PR) 

※ Commit 이란?

1. log message(수정한 이유) 

- ⭐️협업 시 중요⭐️

2. patch/ diff (코드 수정: 변화분) 

- ⭐️+(초록)/-(빨강) 코드를 볼 줄 알아야 함

※ Fork

- 공식 오픈소스 프로젝트의 내용들을 복사하는 것 (Github 안에서)

※ Clone

- history와 함께 소스코드를 다운받는 것 

- zip 다운과는 다름! (zip : commit history은 다운 X)

< CLI(명령어 기반 인터페이스) vs GUI(그래픽 유저 인터페이스) >

※ CLI 

- 사진파일 1만개를 폴더 분류할 때 유리 (쉽게 말해, 드래그 하는 것보다 명령어를 사용하는 것이 편리) 

- 장점 : 세부기능 활용, 자동화(스크립트) 

※ GUI 

- 포토샵, 영상편집, 등에 유리

- 장점 : 쓰기 좋음 

- 단점 : 세부기능 활용, 자동화가 어려움

< 기본 명령어>

★ pwd

- print working directory

- 현재 디렉토리 출력

★ ls

- 현재 디렉토리 내부내용(내부에 존재하는 파일들) 출력

★ cd

- change directory

- 현재 폴더 경로 변경 

- cd .. : 상위 디렉토리로 이동 

★ mv

- 파일명/디렉토리명 변경 or 파일  경로 이동

★ rm

- rm 파일명 :파일 삭제

- rm -r 디렉토리명 : 디렉토리 삭제

★ touch

- 빈 파일 생성

★ clear

- 터미널 화면 정리

"command not found" 에러는 오타!

** 협업 프로세스 ** 

1,2 과정

master 표시 : git으로 관리되는 폴더이다! 라는 의미 

"No such file or directory"  에러 

- 해당 파일/폴더가 없는 경우에 발생 

- 이미 그 폴더에 들어와 있는 경우에도 발생

1. pwd 를 통해 어느 폴더에 있는지 확인 -> 이미 그 폴더인지 확인가능

2. ls 를 통해 현재 폴더 안에 무엇이 있는지 확인 -> 이동할지, 등등 결정 

* config 설정

git config -l

- config 설치 확인

* upstream vs origin

upstream : 공식 오픈소스에 push

origin : fork한 프로젝트/본인 프로젝트에 push

지역 저장소 (local repository): 자신의 컴퓨터에서 작업 한 뒤 그 컴퓨터 안에 커밋 저장한 저장소

 - 단점) 실수로 지역 저장소를 삭제한다면 이때까지 작업했던 내용 증발(안전성 下)

원격 저장소 (remote repository): 지역 저장소의 단점을 보완, 지역 저장소가 아닌 컴퓨터나 서버에 만든 저장소

- 깃 : 지역 저장소와 원격저장소를 연결해서 버전 관리하는 파일들을 쉽게 백업가능

- "백업" & "협업"

- 깃허브 多 사용 

깃허브(깃 사용을 위한 원격 저장소를 제공하는 서비스)

1. 따로 깃 설치를 하지 않고도 깃의 버전 관리 기능 사용 가능

2. 지역 저장소 백업 가능

3. 협업 프로젝트에 사용 가능

4. 자신의 개발 이력을 남길 수 있음

- 날짜별로 모두 기록이 남음 

- 어떤 주제, 어떤것들을 개발 했는지, 개발중인지 확인 가능

5. 다른 사람의 소스를 살펴볼 수 있고, 오픈소스에 참여 가능

- 개발 실력을 높이는 방법 중 하나 : 다른 사람의 소스를 읽어보고 분석하면서 나름대로 소스 수정 및 작성해보는것

깃허브 

www.github.com  

가입후 Create repository (오른쪽 위에있는 +버튼을 누르고 [New repository] 선택)

HTTPS 접속 주소 형태

: https://github.com/아이디/저장소명 

지역저장소를 원격 저장소에 연결하기 

커맨드 라인에서 기존 저장소를 푸시하기 (...push an exisiting repository from the command line)

(1) 만든 깃허브 저장소에 접속 후 주소 복사

(2) 터미널 창에서 연결할 저장소로 이동

(3) $ git remote add origin 복사한주소

     - 원격 저장소(remote)에 origin(깃허브 저장소 주소)을 추가(add)하겠다고 깃에게 알려주는 것

     - 지역 저장소를 특정 원격 저장소에 연결하는 것은 한번만 하면됨!

(4) 원격 저장소에 제대로 연결되었는지 확인

     $ git remote -v 

push - 지역저장소에서 원격저장소로 올리는 것

pull - 원격저장소에서 지역 저장소로 내려받는 것

원격저장소에 파일 올리기 - git push

1. $ git push -u origin master

   - 지역저장소의 브랜치를 origin(원격 저장소의 master 브랜치)로 푸시하라는 명령

   - -u : 지역 저장소의 브랜치를 원격 저장소의 master 브랜치에 연결하기 위한 것 (한번만 하면됨)

2. 이후에 파일 올릴 때는 

$ git push  만 입력하면 됨

원격 저장소에서 파일 내려받기 - git pull

$ git pull origin master 

   - origin(원격 저장소)의 내용을 master 브랜치로 가져온다는 뜻

깃허브에 SSH 원격 접속하기

SSH (Secure Shell) : 보안이 강화된 안전한 방법으로 정보를 교환하는 방식

- 기본적으로 private key 와 public key를 한 쌍으로 묶어서 컴퓨터를 인증함

- public key : 외부에 공개되는 키, private key : 아무도 알 수 없게 사용자 컴퓨터에 저장되는 키

(사용자의 컴퓨터에서 SSH 키 생성기를 실행 -> private key, public key 만들어짐)

-> 개인 노트북을 깃허브에 등록해 두면 언제 어디서든 터미널창을 통해 깃허브에 접속 가능

-> 터미널 창에서 깃허브 사용시 (SSH원격 접속을 사용하면 ) 자동로그인 기능을 사용

SSH 키 생성하기

1. $ ssh-keygen 입력

 - 파일이름 입력하라는 메시지가 뜨는데 무시하고 enter를 치면  화면에 SSH를 통해서 다른 컴퓨터에 접속할 수 있는 비밀번호가 생성됨 

 - 이 때, Your identification has been saved in ~/id_rsa 부분이 프라이빗 키 경로(id_rsa파일 : 프라이빗키)

 - Your public key has been saved in ~/id_rsa.pub 부분이 퍼블릭 키 경로 (id_rsa.pub파일 : 퍼블릭키)

2. 이 키들이 .ssh디렉터리에 저장되었는지 확인해보기

$ cd ~/.ssh

$ ls -la

깃허브에 퍼블릭 키 전송하기

SSH방식으로 접근:  먼저 사용자 컴퓨터에 만들어져 있는 퍼블릭 키를 깃허브 서버로 전송한 다음 저장

1. SSH키 생성 

2. .ssh 디렉터리로 이동

$ cd ~/.ssh 

3. 파일 열어보기

$ cat id_rsa.pub

4. 몇 줄에 걸친 문자열(public 키에 담긴 내용)이 나오는 데 이 문자열 복사

5. 깃허브 접속 후 사용자 아이콘을 누른 후 [Settings]선택

6. [SSH and GPG keys]를 누른후 화면 오른쪽에 나타난 [New SSH key] 선택

7. key 부분에 앞에서 복사한 퍼블릭 키 값 붙여넣기

8. [Add SSH key] 버튼 누르기

SSH 주소로 원격저장소 연결하기

1. 깃허브 사이트에서 repository를 만들면 HTTPS 주소가 나타나는데 [SSH]를 눌러서 SSH주소 복사

2. 홈디렉터리에 connect-ssh 저장소를 만든 후 해당 디렉터리로 이동

3. $ git remote add origin 복사한주소

Problem. 고객사에 따라 다른 제품, 사용 설명서

Solution 1. 처음에 작업했던 저장소 전체를 여러 개 복사해서 각 고객사의 이름을 붙인다음 저장소마다 버전관리를 따로 하는 방법 

 ex) 처음에 작업했던 저장소 : master 각 고객사 : ms, google, apple

but 비효율적!

(1) 자료중복

(2) 고객사마다 디렉터리 이름을 다르게 사용(버전 관리 시스템의 장좀 미이용)

(3) 한 디렉터리의 최신버전코드를 복사해 다른 디렉터리에 붙여 넣고 커밋하는 과정에서 에러가 발생 

Solution 2. 브랜치!

브랜치 기능작동 순서

1. 깃으로 버전관리를 시작하면 master라는 브랜치 생성

2. 사용자가 커밋할 때마다 master브랜치는 최신 커밋을 가리킴 ( 브랜치 = 커밋을 가리키는 포인터)

3. 새 브랜치 생성 시, 기존에 저장한 파일을 master브랜치에 그대로 유지하면서 기존 파일 내용 수정 및 새로운 기능을 구현할 파일 생성 가능 ("branch(분기)한다")

4. 새브랜치에 있던 파일을 master 브랜치에 합칠 수 있음 ("merge"(병합)한다")

깃에서 브랜치를 만들거나 확인하는 명령

새 브랜치 만들기

브랜치 사이 이동하기 ( 다른 브랜치로 이동하기)

한 줄에 한 커밋씩 확인

한 줄에 한 커밋 씩, 각 브랜치의 커밋 확인

한 줄에 한 커밋 씩, 각 브랜치의 커밋, 그래프 형태로 확인

브랜치 사이의 차이점 알아보기 (ex. A브랜치와 B브랜치 사이의 차이점)

A에는 없고 B에만 있는 커밋확인 (A를 기준으로 B비교)

B에는 없고 A에만 있는 커밋 확인 (B를 기준으로 A비교)

서로 다른 파일 병합하기 

1. 각 브랜치에 커밋만들기

2. master브랜치로 체크아웃

3. 병합하기

 cf) 편집기 창을 열지 않고 깃에서 지정하는 커밋 메시지를 그대로 사용하려면

 cf) 브랜치를 병합할 때 편집기 창이 나타나지 않도록 설정한 경우, 커밋 메시지를 추가 및 수정하려면

같은 문서의 다른 위치를 수정했을 때 병합하기

-> 문서를 확인 해 보면 수정한 내용들이 합쳐져 있음

같은 문서의 같은 위치를 수정했을 때 병합하기

-> git merge 명령을 사용하면 "conflick"메시지가 나타남

-> 문서를 열어 수정해야함 

-> 커밋

이 과정에서 나는 commit을 하지 않아

error: Merging is not possible because you have unmerged files.

hint: Fix them up in the work tree, and then use 'git add/rm <file>'
hint: as appropriate to mark resolution and make a commit.
fatal: Exiting because of an unresolved conflict.

라는 에러 메시지가 떴었다. 

병합이 끝난 브랜치 삭제하기 (완전히 저장소에서 없애는 것이 아닌 깃의 흐름 속에서 감추는 것)

(같은 이름으로 브랜치를 만들면 예전에 작업했던 내용이 그대로 나타남)

1. master로 checkout하기

2. 병합이 끝난 브랜치 삭제

위에서 commit을 하지 않은 채로 브랜치를 삭제하려고 시도하니 다음과 같은 에러메시지가 떴다.

error: The branch '삭제할브랜치이름' is not fully merged.
If you are sure you want to delete it, run 'git branch -D 삭제할브랜치이름'.

이때 두가지 해결 방안이 있다. 하나는 해당 파일을 commit하기 나머지 하나는 (git branch -D 삭제할브랜치이름) 입력하기

02-1 깃 저장소 만들기

저장소를 만들고 싶은 디렉터리로 이동해서 깃을 초기화 -> 해당 디렉터리에 있는 파일들을 버전관리 O

깃 초기화 하기 - git init

1. 깃 저장소를 만들 디렉터리 생성

홈 디렉터리에 hello-git이라는 디렉터리를 만들고 cd명령을 사용해 해당 디렉터리로 이동

2. 깃을 사용할 수 있도록 디렉터리 초기화

"Initialized empty Git repository ..."  -> 해당 디렉터리에서 깃 사용 가능

디렉터리 안의 내용을 확인해 보면, '.git'라는 디렉터리가 생성되어있음  ($ ls -la 이용)

'.git' : 깃을 사용하면서 버전이 저장될 저장소(repository)

      cf) .git 디렉터리는 감춰져 있음 (hello-git 디렉터리를 열었을 때 나타나지 않음)

          - 윈도우에서는 [보기]탭에서 '숨긴 항목'을 체크하면 확인 가능

02-2 버전만들기

버전 - 프로그램 개발에서 수정내용이 쌓이면 새로 번호를 붙여서 이전 상태와 구별하는 것

깃에서 버전이란

- 문서를 수정하고 저장할 때 마다 생기는 것

버전관리 시스템(ex 깃) : 만든 시간과 수정내용까지 기록할 수 있음, 변경 시점마다 저장가능

스테이징와 커밋 이해하기

작업트리(Working tree = Working directory)

- 파일 수정, 저장 등의 작업을 하는 디렉터리 (우리 눈에 보이는 디렉터리)

스테이지 (Stage = staging area)

- 버전으로 만들 파일이 대기하는 곳

- 작업트리에서 수정한 파일 중 버전으로 만들 파일만 스테이지로 넘겨주기

저장소 (Repository)

- 스테이지에서 대기하고 있던 파일들을 버전으로 만들어 저장하는 곳

작업 트리에서 빔으로 문서 수정하기

1. hello-git 디렉터리까지 이동후 깃 상태 확인

$ git status(깃 상태 확인)을 하면 위 그림처럼 3메시지가 나타난다. 

 (1) On branch master : 현재 master branch에 있음 

 (2) No commits yet : 아직 커밋한 파일이 없음

 (3) nothing to commit : 현재 커밋할 파일이 없음

2. hello-git 디렉터리에 새로운 파일 만들기

3. vim 화면이 나타나면 1강에서 배운대로 입력 후 종료

4. 깃 상태를 확인해보면 hello.txt라는 untracked files가 있다는 메시지가 나타난다. 

 - untracked files: 한번도 버전관리하지 않은 파일

수정한 파일을 스테이징하기 - git add

1. 스테이징(staging) : 스테이지에 작업트리에서 만들거나 수정한 파일 추가

2. 깃상태를 확인하면 untracked files: 라는 문구가 changes to be committed 로 바뀜 그리고 new file:이라는 수식어가 추가로 나타나는데 이는 "새 파일 hello.txt를 앞으로 커밋할 것이다"라는 뜻

스테이지에 올라온 파일 커밋하기 - git commit

1. 커밋(commit) : 버전을 만듦

커밋과 함께 저장할 메시지를 적을 수 있는데 메시지에는 그 버전에 어떤 변경 사항이 있었는지 확인하는 용도

2. 버전이 제대로 만들어졋는지 확인

방금 커밋한 버전에 대한 설명(커밋을 만든 사람, 만든 시간, 커밋메시지) 이 나타난다. 

스테이징과 커밋 한꺼번에 처리하기 - git commit -am

1. vim에서 아까 작성한 hello.txt파일을 열어 파일의 안의 내용을 수정

2. 스테이징과 커밋 한꺼번에 처리

단, 한번 커밋한 파일이어야 한다. 

02-3 커밋 내용 확인하기

커밋 기록 자세히 살펴보기 - git log

지금까지 만든 버전이 화면에 나타나고, 각 버전마다 설명도 함께 나타남

변경 사항 확인하기 -git diff

- 최신버전의 파일과 수정한 파일이 어떻게 다른지 확인

02-4 버전 만드는 단계마다 파일 상태 알아보기

tracked file 과 untracked file

 cf) 커밋에 관련된 파일 까지 살펴보려면 $git log --stat 입력

unmodified, modified, staged 상태

  cf) 방금 커밋한 메시지 수정하기 : $git commit --amend 를 입력하기 -> vim이 켜지면 수정후 저장하면서 종료

02-5 작업 되돌리기

작업트리에서 수정한 파일 되돌리기 - git checkout

-파일을 수정한 뒤 소스가 정상적으로 동작하지 않는 등의 이유로 수정한 내용을 취소하고 가장 최신 버전 상태로 되돌리기

스테이징 되돌리기 - git reset HEAD 파일이름

-수정된 파일을 스테이징 햇을때, 스테이징 취소

최신 커밋 되돌리기 - git reset HEAD^

-수정된 파일을 스테이징하고 커밋까지 햇을 때, 가장 마지막에 한 커밋 취소

- 커밋에 취소되고 스테이지에서도 내려감

특정 커밋으로 되돌리기 -git reset 커밋해시

- 특정 버전으로 되돌린 다음 그 이후 버전을 삭제

- git reset A 일때, A커밋을 삭제하는 것이 아니라 A 커밋 이후에 만들었던 커밋을 삭제하고 A 커밋으로 이동 

- git log 를 이용해 커밋해시 복사

커밋 삭제하지 않고 되돌리기 - git revert

-나중에 사용할 것을 대비해 커밋을 되돌리더라도 취소한 커밋을 남겨두어야 할때