git.txt


[D2Coding 글꼴에 최적화]
------------------------------------------------------------------------------------------------------------------
최초의 깃 커밋 메세지 !!
- Initial revision of "git", the information manager from hell -
------------------------------------------------------------------------------------------------------------------
Github 내에 여러 파일 경로에서 github.com 대신에 github-history.netlify.com 을 입력하면 파일의 history변화를 멋진 UI로 보여줍니다.
------------------------------------------------------------------------------------------------------------------
Git의 저장 영역 정리 (feat.생활코딩)

1. Working Directory(작업영역)
실제 프로젝트 디렉토리, git 이력과 관련된 정보가 저장되어있는 .git을 제외한 모든 영역을 말함
실제 코드를 수정하고 추가하는 변경이 이루어지는 영역

2. Repository(저장소)
파일이나 폴더를 변경 이력별로 저장해 두는 곳
.git 디렉토리 내에 존재함
Local Repository : 내 PC에 파일이 저장되는 개인 저장소
Remote Repository : 파일이 원격 저장소 전용 서버에서 관리되며 여러 사람이 함께 공유하기 위한 저장소

3. Index
Working Directory 에서 Repository로 정보가 저장되기 전 준비 영역
파일 상태를 기록, 스테이징 한다고도 표현함, Staging Area로 불리기도함
.git/index 파일로 관리됨.
git add 명령어로 Working Directory 에서 Index 영역으로 정보가 저장됨
git commit 명령어로 Index 영역에서 Repository로 정보가 저장됨

4. Stash
일반적인 Working Directory > Index > Repository 로 이루어지는 영역과는 다른 별개의 임시영역
임시적으로 작업사항을 저장해놓고 나중에 꺼내올 수 있다.

------------------------------------------------------------------------------------------------------------------
Git command   ->  모든 명령어의 옵션이나 자세한 내용은 명령어 뒤에 --help 하면 나옵니다

·······························
············· init ············		(생성)
·······························

「이 명령은 .git이라는 하위 디렉토리를 만든다. 
  .git 디렉토리에는 저장소에 필요한 뼈대 파일(Skeleton)이 들어 있다」

  ↓	  ↓	  ↓	  ↓
	
git init
- .git 디렉토리를 생성하고 현재 디렉토리를 버전관리 한다



·······························
·············· rm ·············		(삭제)
·······························

「Git에서 파일을 제거하려면 git rm 명령으로 Tracked 상태의 파일을 삭제한 후에
  (정확하게는 Staging Area에서 삭제하는 것) 커밋해야 한다. 
  이 명령은 워킹 디렉토리에 있는 파일도 삭제하기 때문에 실제로 파일도 지워진다.
  Git 명령을 사용하지 않고 단순히 워킹 디렉터리에서 파일을 삭제하고 
  git status 명령으로 상태를 확인하면 Git은 현재 “Changes not staged for commit” 
  (즉, Unstaged 상태)라고 표시해준다.
  git rm 명령을 실행하면 삭제한 파일은 Staged 상태가 된다.」

  ↓	  ↓	  ↓	  ↓

git rm -r .git
- .git 폴더가 삭제되며 Git 로컬 저장소 지정을 해제한다

git rm [Filename]
- 원격 저장소와 로컬 저장소에 있는 파일을 삭제한다

git rm --cached [Filename]
- 하드디스크에 있는 파일은 그대로 두고 Git만 추적하지 않게 한다

git rm --cached .idea/modules.xml
- .idea/modules.xml 파일 삭제

git rm --cached -r .idea/ 
- .idea 폴더 하위의 모든 파일 삭제

$ git rm \*~
- ~ 로 끝나는 파일을 모두 삭제


·······························
··········· config ············		(설정)
·······························
「」
  ↓	  ↓	  ↓	  ↓

git config [--global] user.name "name"
git config [--global] user.email email
- 작업하는 개발자의 정보 명시
  --global 옵션 설정시 모든 프로젝트에 적용 된다.

「
	설정은 key=value 형식으로 이루어지는데, Git은 여파 설정 파일을 참조하므로 키가 중복으로 존재할 수 있습니다.
	이때 Git 나중의 값을 우선으로 사용합니다.

	윈도에서 개발하는 동료와 함께 일하면 줄 바꿈(New Line) 문자에 문제가 생긴다. 
	윈도는 줄 바꿈 문자로 CR(Carriage-Return)과 LF(Line Feed) 문자를 둘 다 사용하지만, 
	Mac과 Linux는 LF 문자만 사용한다. 
	아무것도 아닌 것 같지만, 크로스 플랫폼 프로젝트에서는 꽤 성가신 문제다.
	--- autocrlf ---
	true : Commit시점에 CRLF를 LF로 변환, 체크아웃 시점에 LF를 CRLF로 변환
	input : Commit시점에 CRLF를 LF로 변환, 체크아웃 시점에는 변환하지 않음(Windows플랫폼의 경우는 true와 동일)
	false : 변환하지 않음 

	git config <--global> core.autocrlf [true | input | false] //설정하기
	 
	git config <--global> --unset core.autocrlf //설정 해제하기
	--- safecrlf ---
	true  : 개행문자가 혼재할 경우 안전을 위해 이후의 처리를 중단함
	warn : 개행문자가 혼재할 경우 경고를 출력하고 처리는 계속 진행함
	false : core.autocrlf설정에 의해 변환 수행, 결과적으로 개행문자가 한쪽으로 통일되므로 의도한 경우라면 데이타 손실 가능성이 있음

	git config <--global> core.safecrlf [true | warn | false] //설정하기
 
	git config <--global> --unset core.safecrlf //해제하기
																	」
- core.whitespace -

「
	Git에는 공백 문자를 다루는 방법으로 네 가지가 미리 정의돼 있다. 두 가지는 기본적으로 켜져 있지만 끌 수 있고 나머지 두 가지는 꺼져 있지만 켤 수 있다.

	git config --global core.whitespace \
	    trailing-space,space-before-tab,indent-with-non-tab
	- core.whitespace 옵션으로 이 네 가지 방법을 켜고 끌 수 있다. 
	  설정에서 해당 옵션을 빼버리거나 이름이 -로 시작하면 기능이 꺼진다. 
	  예를 들어, 다른 건 다 켜고 cr-at-eol 옵션만 끈다

	  ※ 먼저 기본적으로 켜져 있는 것을 살펴보자. 
	    trailing-space는 각 줄 끝에 공백이 있는지 찾고 space-before-tab은 모든 줄 처음에 tab보다 공백이 먼저 나오는지 찾는다.
	    기본적으로 꺼져 있는 나머지 두 개는 indent-with-non-tab과 cr-at-eol이다. 
	    intent-with-non-tab은 tab이 아니라 공백 8자 이상으로 시작하는 줄이 있는지 찾고 cr-at-eol은 줄 끝에 CR 문자가 있어도 괜찮다고 Git에 알리는 것이다.

	git apply --whitespace=warn <patch>
	- git diff 명령을 실행하면 Git은 이 설정에 따라 검사해서 컬러로 표시해준다. 
	  그래서 좀 더 쉽게 검토해서 커밋할 수 있다. 

	git apply 명령으로 Patch를 적용할 때도 이 설정을 이용할 수 있다. 
	- 명령어를 실행하면 해당 Patch가 공백문자 정책에 들어맞는지 확인

	git apply --whitespace=fix <patch>
	- Git이 자동으로 고치도록 할 수 있다
	  이 옵션은 git rebase 명령에서도 사용할 수 있다. 
	  공백 문제가 있는 커밋을 서버로 Push하기 전에 --whitespace=fix 옵션을 주고 Rebase하면 Git은 다시 Patch를 적용하면서 공백을 설정한 대로 고친다.
																			」


git config [--global] core.autocrlf true
- 윈도우에서 warning: LF will be replaced by CRLF 오류 시
- 시스템 전체가 아닌 해당 프로젝트에만 적용할 때는 global 옵션을 빼준다

git config --global gui.encoding utf-8
- gitk 한글이 깨지는 경우

git config core.quotepath false
- 이 설정은 일반적이지 않은 문자를 탈출문자로 처리하는 기능수행
  그래서 한글 앞에 탈출 문자를 붙인 탓에 이런 문제가 발생

git config --list
- 설정한 모든것을 보여준다

·······························
········· .gitconfig ··········		(환경설정)
·······························

ex) .gitconfig
	[core]
		filemode = true
		editor = vim
	
	[user]
		name = musclebear
		email = musclebear@도메인
		
	[color]
		ui = auto
		
	[color "branch"]
		current = yellow bold
		local = green bold
		remote = cyan bold
		
	[alias]
		co = checkout
		br = branch
		ci = commit
		st = status
		glog = log --graph --oneline --decorate --date=relative --all
		dt = difftool
		d = diff
		
	[push]
		default = simple

이런식으로 config 커맨드로 설정이 가능하다
	git config --global user.name "Your Name"
	git config --global user.email you@yourdomain.example.com
	git config --global alias.ci "commit -a"
	git config --global alias.co checkout
	git config --global alias.st "status -a"
	git config --global alias.stat "status -a"
	git config --global alias.br branch
	git config --global alias.wdiff "diff --color-words"
	git config --global core.editor vim
	git config --global merge.summary true

참고 사이트
https://gamdekong.tistory.com/19
https://mirrors.edge.kernel.org/pub/software/scm/git/docs/git-config.html

·······························
··········· status ············		(상태)
·······························
「」
  ↓	  ↓	  ↓	  ↓

git status
- 변화 상태 확인 tracked, untracked, modified 등등

git status -s
- 간단하게 보여준다

·······························
············· add ·············		(추가)
·······························
「」
  ↓	  ↓	  ↓	  ↓

git add [filename]
- 해당 파일을 tracked 하는 명령
- 파일이 수정되어서 commit 하기 전에도 해야한다 (커밋 대기상태에 들어간다, 스테이징)

git add -p
- modified된 파일의 수정 부분을 단위별로 나누어서 추가할지 안할지 선택하게 한다
  · 변경사항 하나의 단위를 hunk라고 한다.
  · hunk 단위로 추가할지 말지 선택한다.
  · ?를 입력하면 각 명령어를 볼 수 있다
  · y 는 해당 hunk를 스테이징에 추가하고, n 은 추가하지 않고 다음 hunk를 보여준다.
  · q 를 입력하면 add 과정을 종료한다.

git add -A
- add changes from all tracked and untracked files

git reset HEAD [file]
- git add한 파일 취소
  뒤에 파일명이 없으면 add한 파일 전체를 취소

·······························
··········· commit ············		(커밋)
·······························
「」
  ↓	  ↓	  ↓	  ↓

git commit 
- 커밋 메세지를 입력하는 창으로  

git commit -v
- 커밋하는 변경사항을 한번 더 보여준다
- 커밋 메세지를 입력하는 화면 아래 코드 diff

git commit -a
- 스테이징된 모든 파일을 커밋

git commit -m "comment"
- 커밋 메세지를 인라인에서 작성

git commit --amend
- 가장 최근 커밋을 수정
  파일을 추가적으로 수정 및 추가 하고 git add 명령어 이후 
  git commit --amend 명령어를 입력하면 커밋 메세지 또한 수정 됩니다.
  이미 해당 커밋을 push 하였다면 에러 발생
  git push --force 옵션으로 푸시 가능
  하지만 이미 push한 커밋을 수정하여 강제로 push하는 것은 코드를 공유해 작업하는 동료들에게 오류를 일으킬 수 있다

git reset [--soft][--mixed][--hard]HEAD^
- 커밋 취소(3가지 옵션)

·······························
············ log ··············		(로그)
·······························
「」
  ↓	  ↓	  ↓	  ↓

git log
- 커밋의 역사 확인
- 나갈 때는 q

git log -p
- 각각의 커밋과 커밋 사이에 소스상의 차이점 확인
※ 왜 깃은 add 과정을 거치게 하는지
- 작업한 내용중 commit을 할 것들만 추려서 선택적 커밋 가능
※ stage area -> 커밋 대기상태, 스테이지 위에 있는 파일들이 버전이 된다
※ repository 저장소

git log [비교브랜치1]..[비교브랜치2]
- 2에는 없고 1에 있는 커밋을 보여줌

git log --branch --graph --decorate --oneline
- 로그에 모든 브랜치를 표시하고, 그래프로 표현하고, 브랜치 명을 표시하고, 한줄로 표시
- 쓰고싶은 것만 골라서 쓸 수 있음



·······························
············· diff ············		(비교)
·······························

「외부 도구로 비교하기 !!
  즐겨 쓰거나 결과를 아름답게 보여주는 Diff 도구가 있으면 사용할 수 있다. 
  git diff 대신 git difftool 명령을 사용해서 emerge, vimdiff 같은 도구로 비교할 수 있다. 
  상용 제품도 사용할 수 있다. 
  git difftool --tool-help 라는 명령은 사용가능한 도구를 보여준다.」

  ↓	  ↓	  ↓	  ↓

git diff
- 수정했지만 아직 staged 상태가 아닌 파일을 비교
  (Working Directory와 Index영역 사이의 변경사항을 표시)

git diff --cached
- Index영역과 Repository 영역을 비교하여 변경사항을 표시
  staged된 상태(Add가 된 상태)에서 변경점이 확인
  commit 된 상태라면 아무것도 표시하지 않는다

git diff [branch-name1] [branch-name2]
- 로컬의 브랜치간 코드 비교

git diff [branch-name] [origin/branch-name]
- 로컬 브랜치와 원격 브랜치간의 비교

git diff [커밋 해시아이디] [커밋해시아이디]
- 커밋끼리 비교

git diff [비교대상1]..[비교대상2]
- 1과 2의 차이점 비교 ..이 들어간다

git diff --staged
- 커밋하려고 Staging Area에 넣은 파일의 변경 부분을 보고 싶을때
  저장소에 커밋한 것과 Staging Area에 있는 것을 비교


·······························
··········· branch ············		(브랜치)
·······························
「」
  ↓	  ↓	  ↓	  ↓

git branch
- 로컬 브랜치의 목록 확인

git branch [branch-name]
- 로컬 브랜치 생성

git branch -d [branch-name]
- 브랜치 삭제

git branch --delete [branch-name]
- 브랜치 삭제

git branch -D [branch-name]
- 병합하지 않은 브랜치를 강제 삭제

git branch -a 
- 현재 생성된 모든 local branch와 remote branch 확인

git branch --set-upstream-to origin/feature-01
- branch 연동
·······························
··········· checkout ··········		(체크아웃)
·······························
「」
  ↓	  ↓	  ↓	  ↓

git checkout branch-name
- 해당 브랜치로 전환(체크아웃)

git checkout -b branch-name
- 브랜치를 생성하고 전환까지

git checkout --[Filename]
- 스테이징에 커밋하지 않은 파일의 변경 내용을 취소하고 이전 상태로 되돌린다

git checkout .
- working directory에서 수정한 파일(git add이전)을 현재 버전으로 되돌리기

git checkout -f 
- 아직 커밋되지 않은 working directory 와 index(staging area) 수정사항 모두 삭제

·······························
············ merge ············		(병합)
·······························
「」
  ↓	  ↓	  ↓	  ↓

git merge branch-name
- 현재 브랜치에 해당 브랜치를 병합
※ 3 way merge 라는 기법으로 병합


·······························
············ remote ···········		(원격 저장소)
·······························
「」
  ↓	  ↓	  ↓	  ↓

git remote add [remote-name] [원격저장소주소]
- 원격저장소 추가

git remote -v
- 현재 원격저장소로 설정된 목록 확인

git remote show [remote-name]
- 리모트 저장소의 구체적인 정보를 확인
- 브랜치명을 생략하고 git push 명령을 실행 할 때 어떤 브랜치가 어떤 브랜치로 
push 되는지도 보여준다

git remote rename test1 test2
- 리모트 이름을 test1 에서 test2 로 변경

git remote rm origin
- origin 리모트 저장소 삭제



·······························
············ push ·············		(원격 저장)
·······························

「푸쉬를 하기 전에 pull을 해서 원격 저장소의 최신 상태를 유지해야한다」
  ↓	  ↓	  ↓	  ↓

git push [리모트 저장소 이름] [브랜치 이름]

git push [remote-name] [local-branch][:][remote-branch]
- 원격 저장소에 푸쉬 (remote-name의 remote-branch에 local-branch를 푸쉬)

git push origin v1.0.3
- 원격 저장소 origin에 v1.0.3 태그 올리기

git push origin --tags
- 모든 태그 올리기

git push origin :v1.0.0
- 원격 저장소에 올라간 태그 v1.0.0 삭제

git push -u [remote-name] [local-branch]
git push --set-upstream [remote-name] [local-branch]
- 브랜치를 추적하도록 해서, 이후에 git push 만 입력해도 push 가능

git push origin :branch-name
- origin 원격 저장소의 해당이름의 브랜치 삭제

·······························
··········· clone ·············		(저장소 복제)
·······························

「다른 프로젝트에 참여하거나(Contribute) Git 저장소를 복사하고 싶을 때 사용한다.
  git clone을 실행하면 프로젝트 히스토리를 전부 받아온다. 
  저장소를 Clone하면 origin이라는 리모트 저장소가 자동으로 등록되기 때문에
  origin이라는 이름을 볼 수 있다.」

  ↓	  ↓	  ↓	  ↓

git clone /로컬/저장소/경로
- 로컬 저장소를 복제

git clone 사용자명@호스트:/원격/저장소/경로
-원격 서버의 저장소 복제

git clone https://github.com/zave7/develop.git 
- 깃허브 서버의 저장소 복제



·······························
············ fetch ············		(변경) 
·······························

「fetch 를 실행하면, 원격 저장소의 최신 이력을 확인할 수 있습니다. 
  이 때 가져온 최신 커밋 이력은 이름 없는 브랜치로 로컬에 가져오게 됩니다.
  이 브랜치는 'FETCH_HEAD'의 이름으로 체크아웃 할 수도 있습니다.
  이 상태에서 원격 저장소의 내용을 로컬 저장소의 'master'에 통합하고 싶은 경우에는,
  'FETCH_HEAD' 브랜치를 merge 하거나 다시 pull 을 실행하면 됩니다.」

  ↓	  ↓	  ↓	  ↓

git fetch [remote-name]
- 로컬에는 없지만, 리모트 저장소에는 있는 변경된 데이터를 모두 가져온다
- 자동으로 merge 하지 않는다. 그래서 수동으로 해줘야 한다.



·······························
············ pull ·············		(내려받기) 
·······························

「사실 pull 이라는 것은 내부적으로 보면 fetch + merge 이다「」
  ↓	  ↓	  ↓	  ↓

git pull [remote-name]
- 원격 저장소 내용을 현재 브랜치에 합친다.
  pull은 변경된 데이터를 가져오고 merge도 한다.

git pull -u [remote-name] [remote-master]
- -u 옵션은 해당 [remote-name] [remote-master]를 기본 pull 옵션으로 지정하는 것
  설정 이후부터는 git pull 만 입력해도 된다

·······························
············· tag ·············		(태그)
·······························
「」
  ↓	  ↓	  ↓	  ↓

git tag
- 이미 만들어진 태그가 있는지 확인

git tag -l v1.4.2.*
- v1.4.2.1	패턴을 사용해서 태그 검색
  v1.4.2.2
  v1.4.2.3
  v1.4.2.4

※ tag 에는 Lightweight 태그와 Annotated 태그로 두 종류가 있다.
  Lightweight 태그는 단순히 특정 커밋에 대한 포인터일 뿐이다.
  Annotated 태그는 태그를 만든사람의 이름, 이메일, 태크만든 날짜, 태크 메세지도 저장
  이 모든 정보를 저장해둬야 할 때에만 Annotated 태그를 추천한다.
  단순한 태그는 Lightweight 태그

git tag -a v1.4 -m "my version 1.4"
- Annotated 태그는 옵션 -a 추가하고 comment 남기기 가능

git show v1.4
- 태그 v1.4의 정보와 커밋 정보 확인

git tag -a v1.0.4 -m"Release version 1.0.4" [커밋아이디]
- 원하는 커밋에 태그명 붙이기

git push origin v1.0.3
- 원격저장소에 v1.0.3 태그 올리기

git tag -d v1.0.0
- 태그 삭제

git push origin :v1.0.0
- 원격저장소에 올라간 태그 삭제

·······························
········· .gitignore ··········		(파일 무시)
·······························

※ .gitignore 이란?
  - Project에 원하지 않는 파일들을 Git에서 제외시킬수 있는 설정 File이다.
  - 항상 최상위 directory에 존재해야한다.

  ex) 	# : comments

	# 확장자가 .a인 파일 무시
	*.a

	# 윗 라인에서 확장자가 .a인 파일은 무시하게 했지만 lib.a는 무시하지 않음
	!lib.a

	# 현재 디렉토리에 있는 TODO파일은 무시하고 subdir/TODO처럼 하위디렉토리에 있는 파일은 무시하지 않음
	/TODO

	# build/ 디렉토리에 있는 모든 파일은 무시
	build/

	# doc/notes.txt 파일은 무시하고 doc/server/arch.txt 파일은 무시하지 않음
	doc/*.txt

	# doc 디렉토리 아래의 모든 .pdf 파일을 무시
	doc/**/*.pdf
	
	# /src 디렉토리 및 하위 디렉토리를 제외한 모든 디렉토리 및 파일을 무시
	/*
	!/src/
	
	# .svn 파일 제외
	/**/.svn
	
	# pom.xml 살리기
	!pom.xml

cat .gitignore
※ .gitignore File을 만들고 commit하면 적용된다.
  원격저장소의 경우 .gitignore File을 같이 push 하면 적용된다.
  - 제대로 적용되지 않을 수 있으므로
	( git rm -r --cached .
	  git add .
	  git commit -m "Apply .gitignore" )를 해준다



·······························
········· pull request ········		(풀 리퀘스트)
·······························

참고 - https://blog.outsider.ne.kr/865

Pull request 방법
-> 깃허브에서 참여하고 싶은 유저의 저장소 클릭
-> 우측 상단의 fork 클릭
-> 내 깃허브 저장소에 그 저장소가 복제됨
-> 복제한 저장소를 clone 해서 내 로컬 저장소에도 복제함
-> 복제한 로컬 저장소에서 내가 작업할 새로운 브랜치를 생성(의미있는 이름으로)
-> 로컬 저장소의 생성한 브랜치에서 작업 후 커밋
-> 커밋 후 내 깃허브에 있는 복제한 저장소에 푸쉬
-> 깃허브의 복제한 프로젝트에서 pull request 클릭
-> 풀리퀘스트를 할 원본 유저의 저장소의 브랜치와 내가 복제해서 작업한 깃허브의 저장소의 브랜치를 선택하라고 함
-> create pull request 를 하면 원본 유저 저장소에 풀리퀘스트가 감!!
-> 원본 유저는 다른 유저가 요청한 풀리퀘스트 코드를 리뷰해서 원본 저장소에 반영하는 것을 결정함

·······························
············ stash ············		(스태쉬)
·······························

「
  Stash는 Modified이면서 Tracked 상태인 파일과 Staging Area에 있는 파일들을 보관해두는 장소다.
  Git은 Stash에 저장할 때 수정하던 파일을 복원해준다. 
  복원할 때의 워킹 디렉토리는 Stash할 때의 그 브랜치이고 워킹 디렉토리도 깨끗한 상태였다. 
  하지만, 꼭 깨끗한 워킹 디렉토리나 Stash할 때와 같은 브랜치에 적용해야 하는 것은 아니다. 
  어떤 브랜치에서 Stash하고 다른 브랜치로 옮기고서 거기에 Stash를 복원할 수 있다. 
  그리고 꼭 워킹 디렉토리가 깨끗한 상태일 필요도 없다. 
  워킹 디렉토리에 수정하고 커밋하지 않은 파일들이 있을 때에도 Stash를 적용할 수 있다. 
  만약 충돌이 나면 알려준다.」

  ↓	  ↓	  ↓	  ↓

git stash (마지막 커밋 이후의 작업을 커밋하지 않고 나중에 다시 돌아와서 작업을 다시 하고 싶을 때)
- 커밋하기 전의 워킹디렉토리 작업 내용을 stash 영역에 저장
※ 스택에 새로운 stash가 만들어진다

git stash list 
- 저장한 stash를 확인(여러개의 stash 저장 가능)

git stash apply
- stash 적용 (이름이 없으면 가장 최근의 stash를 적용)
  적용할 stash를 선택하고 싶으면 apply + stash 이름

git stash apply --index 
-  staged 상태까지 복원

git stash drop stash@ {num}
- 해당 넘버의 stash를 제거

git stash show -p stash@{0} | git apply -R
- stash 되돌리기 (stash를 명시하지 않으면 git은 가장 최근의 stash를 사용)
  깃은 stash unapply 같은 명령을 제공하지 않기 때문에 
  stash를 이용해서 패치를 만들고 그것을 거꾸로 적용할 수 있다

git stash branch branch-name
- stash 할 당시의 커밋으로 checkout한 후 새로운 브랜치를 만들고 거기에 stash 적용
  성공하면 stash를 삭제한다
  ※ 이 명령은 브랜치를 새로 만들고 Stash를 복원해주는 매우 편리한 도구이다
git stash --include-untracked
git stash -u
- 추적 중이지 않은 파일을 같이 저장

git stash --patch
- 수정된 모든 사항을 저장하지 않는 대신
  대화형 프롬프트가 뜨며 변경된 데이터 중 저장할 것과 저장하지 않을 것을 지정

git stash pop [--index]
- 적용과 동시에 스태쉬 리스트에서 삭제
·······························
············ reset ············		(리셋)
·······························
「특정 지점의 과거 커밋으로 이동, 이동 된 이후의 커밋은 삭제됨
  사용 상 주의 요망 : 과거 커밋으로 이동하면서 그 이후 커밋은 삭제되어 되돌릴수 없으므로 주의가 필요
  특히 Push 후에는 다른사람의 코드에 문제 일으킬 소지 있으므로 금지
  이미 커밋한 내용에 절대적으로 지켜야 하는 전제가 원격저장소에 아직 PUSH 하지 않은 커밋에 대해서만 수정을 해야 한다
  ※ 주로 사용하는 옵션은 3가지 : --mixed, --hard, --soft, 기본값은 --mixed
    커밋ID는 앞자리 일부만 사용가능」

  ↓	  ↓	  ↓	  ↓

git checkout .
- working directory에서 수정한 파일(git add이전)을 현재 버전으로 되돌리기

git reset .
- 현재 버전으로 되돌리기 (add 무효화하기)

git reset --hard HEAD^
- 이전 버전을 되돌리는데, 파일 내용까지 되돌림

git reset HEAD^
- 이전 버전을 되돌리는데, 파일 내용은 그대로 유지

git reset --soft HEAD^
- 이전 버전을 되돌리는데, 파일 내용은 그대로 유지하면서 staging area에 올림

git reset {commit번호}
- 특정 버전으로 되돌리는데, 파일 내용은 그대로 유지하고 되돌린 버전 이후의 모든 commit 이력 삭제

git reset --hard
- (--hard) 옵션을 적용하면 해당 커밋ID의 상태로 Working Directory와 Index영역 모두 초기화된다.
  ex)
	-> 프로젝트 디렉토리에 ‘text.txt’파일을 추가 커밋
	-> git reset --hard 이전커밋id
	-> ‘text.txt’ 파일은 삭제되며 git status에서도 확인이 불가능하다.

git reset --mixed
- (--mixed) 옵션을 적용하거나 옵션을 적용하지 않으면 해당 커밋ID의 상태로 Index영역은 초기화되고 Working Directory는 변경되지 않는다.
  ex)
	- > 프로젝트 디렉토리에 ‘text.txt’파일을 추가 커밋
	- > git reset --mixed 이전커밋id
	- > ‘text.txt’파일은 살아있으며, Index영역에는 추가되지 않은 상태다.

git reset --soft
- (--soft) 옵션을 적용하면 해당 커밋ID의 상태로 Index영역과 Working Directory 모두 변경되지 않는다.
  ex)
	- > 프로젝트 디렉토리에 ‘text.txt’파일을 추가 후 커밋
	- > 다시 ‘text2.txt’ 파일을 git add text2.txt
	- > git reset --soft 이전커밋id
	- > ‘text.txt’, ‘text2.txt’ 파일 모두 git status를 확인 해보면 add된 상태를 확인할수 있다.

git reset [--soft][--mixed][--hard]HEAD^
- 커밋 취소(3가지 옵션)

git reset HEAD [file]
- git add한 파일 취소
  뒤에 파일명이 없으면 add한 파일 전체를 취소

git reset --hard <remote>/<branch>
- 원격 저장소 상태로 로컬을 초기화 하고 싶을 때

·······························
··········· revert ············		(리버트)
·······························

git revert 커밋id
- 특정 버전으로 되돌리는데, Working Directory 내용은 그대로 유지하고 되돌린 버전 이후의 모든 commit 이력은 그대로 보존

git revert <커밋id>..<커밋id>
- 범위를 지정하여 해당 커밋들에서 수정한 코드를 취소하고 새로운 버전의 커밋을 생성함


·······························
············ tool ·············		(도구)
·······························
kdiff3 (diff 와 merge 툴)
https://sourceforge.net/projects/kdiff3/

git config --global --add merge.tool kdiff3
git config --global --add mergetool.kdiff3.path "C:/Program Files/KDiff3/kdiff3.exe"
git config --global --add mergetool.kdiff3.trustExitCode false

git config --global --add diff.guitool kdiff3
git config --global --add difftool.kdiff3.path "C:/Program Files/KDiff3/kdiff3.exe"
git config --global --add difftool.kdiff3.trustExitCode false

Mac-os
git config --global --add merge.tool kdiff3
git config --global --add mergetool.kdiff3.path "/Applications/kdiff3.app/Contents/MacOS/kdiff3"
git config --global --add mergetool.kdiff3.trustExitCode false

git config --global --add diff.guitool kdiff3
git config --global --add difftool.kdiff3.path "/Applications/kdiff3.app/Contents/MacOS/kdiff3"
git config --global --add difftool.kdiff3.trustExitCode false

·······························
··········· rebase ············		(리베이스)
·······························

git rebase -i 
- 커밋의 이름이나 관련 이름을 부여할 수 있다
- 충돌이 발생했을 경우, 유저가 해결한 후에 add하고 git rebase --continue를 해주면 순차적으로 마저 진행된다.(commit 안해도된다)
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
		커밋 히스토리 단장 (집중)
★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
git에서 여러개의 commit들을 하나로 합치고 싶을 때가 있다.
이 작업은 일반적으로 Squash 라고 불린다

- Squash -
commit을 squash 하려면 interactive rebase를 실행한다.
git rebase -i HEAD~2
- HEAD~2는 HEAD로부터 2개의 commit 을 의미한다

$ git rebase -i HEAD~2 // HEAD~2는 HEAD로부터 2개의 commit 을 의미한다
-----------------------------------------------------------------------
▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽

pick 9e67594 Add title to a.md
pick e5af3cb Bye // 이 라인의 pick 을 squash 로 변경

# Rebase be86009..e5af3cb onto be86009 (2 command(s))
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

△ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △
-----------------------------------------------------------------------
아래 주석은 rebase 사용에 대한 내용이고, 위의 두 줄을 보면 시간 순서대로 commit 이 나열되어있다.

앞의 9e67594 commit 이 주가 되고 뒤에 있는 e5af3cd commit 을 합쳐버릴 것이기 때문에 
e5af3cd 앞에 있는 pick 을 squash 로 변경하고 :x (vi 에서 저장하고 나가기) 로 종료한다.

그러면 아래와 같은 내용이 출력된다.
-----------------------------------------------------------------------
▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽

# This is a combination of 2 commits.
# The first commit's message is:

Add title to a.md

# This is the 2nd commit message:

Bye

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Date:      Tue Jun 21 15:35:19 2016 +0900
#
# interactive rebase in progress; onto be86009
# Last commands done (2 commands done):
#    pick 9e67594 Add title to a.md
#    squash e5af3cb Bye
# No commands remaining.
# You are currently editing a commit while rebasing branch 'master' on 'be86009'.
#
# Changes to be committed:
#       modified:   a.md

△ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △
-----------------------------------------------------------------------
여기서 두 commit 을 합쳐서 생긴 새 commit 의 message 를 작성할 수 있다.

저 부분에서 주석 빼고는 다 message 에 들어가기 때문에 지금은

Add title to a.md
Bye

라고 작성이 될 것이고, 바꾸고 싶으면 원하는 대로 편집하면 된다.
앞에서처럼 작성하고 나가면 아래와 같은 결과가 출력되며 commit 이 합쳐진 것을 확인할 수 있다.
-----------------------------------------------------------------------
▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽

[detached HEAD 66ba47b] New commit! // 새로 작성한 commit message
 Date: Tue Jun 21 15:35:19 2016 +0900
 1 file changed, 2 insertions(+)
Successfully rebased and updated refs/heads/master.

△ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △
-----------------------------------------------------------------------
Remote repository 에 squash 한 commit push 하기


아무도 squash 한 commit 들을 pull 하지 않았다는 가정 하에 이 작업이 수행되어야 한다. 
누군가 이미 해당 commit 들을 pull 했는데 그것을 rebase 를 통해 수정하고 commit 하면 큰일 날 수 있다.
이미 remote repository 에 squash 하지 않은 commit들을 push 했을 경우, squash 한 commit 을 push 하면 거부 당한다.

위에 얘기한 대로 다른 사람이 이미 변경 전 commit 들을 pull 한 경우 꼬여버릴 수 있기 때문이다.



대표적으로 이러한 squash 작업이 필요한 경우가 Open Source repository 를 fork 해서 
수정한 후에 pull request 를 날렸는데 수정요청이 들어올 때이다.

Pull request 가 여러개의 commit 으로 이루어지게 되면 중간에 완성되지 않은 commit 이 존재하는 것이기 때문에 관리상에 어려움이 생길 수 있다. 
이를 방지하기 위해 squash 를 통해 제대로 동작하는 하나의 commit 으로 만들어 주는 것이 좋다.

Fork 해온 repository 는 어짜피 나만 수정하는 것이기 때문에 아무도 pull 을 해갔을리 없으니 꼬일 걱정 없이 강제로 push 할 수 있다.
-----------------------------------------------------------------------
▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽ ▽
$ git push origin <branch-name> --force 
- 강제 푸쉬
△ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △ △
-----------------------------------------------------------------------
참고 사이트 : https://json.postype.com/post/209499
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■
·······························
··········· reflog ············		(레프로그)
·······························

git reflog
- HEAD가 거쳐간 모든 캐시의 리스트를 출력해준다. 
  기본으로는 5개나 10개 정도를 보여준다
- 작업 시간과 상관없이 지금의 HEAD가 과거에 어디 위치해 있었는지 파악하는데 아주 유용하다
  브랜치를 자주 옮겨 다니는 작업을 하면서 어떤 이름을 잊거나, 
  실수로 브랜치를 지운 경우에도 남아있어서 이를 참조할 수 있습니다.

·······························
············ clean ············		(클린)
·······························
「작업하고 있던 파일을 Stash 하지 않고 단순히 그 파일들을 삭제하고 싶은 경우에 사용하는 명령어입니다.
  추적되고 있지 않는(unstage)경우의 파일이 삭제되는 경우입니다」

git clean -d -n
- 삭제될 대상들을 미리 확인
  ※ -n : 가상으로 실행해보고 어떤 파일들이 지워질지 알려주는 옵션
  ※ -i : 대화형으로 실행(파일마다 지우지 말지 결정하거나 특정 패턴으로 걸러서 지울 수 있다)
  ※ -x : .gitignore 무시하고 삭제
git clean -d -n