* 설정 

git config --global user.name "Your Name"
git config --global user.email "aaa@bbb.com"

라인 ending 설정 (윈도우경우)

    git config --global core.autocrlf true 

    git config --global core.safecrlf true

인코딩 설정:  윈도우 환경일 경우.

    git config --global i18n.commitEncoding cp949 

    git config --global i18n.logOutputEncoding cp949 

    물론 인코딩이 utf8 이라면 

    git config --global i18n.commitEncoding utf8 

    git config --global i18n.logOutputEncoding utf8


SSH-Key 생성

    ssh-keygen -t rsa

* 추적하지 않을 파일 설정하기

    .gitighore 파일을 생성, 패턴을 기술.

    echo "*.security" > .gitingnore
   
* 현 설정 확인

    git config --list


* Repository 생성

    git init

* 상태 확인  

    git status
   
* 변경사항을 staging 하기

    git add test.c
    git add .
   
    staged 상태 : Git가 변화를 인지한 상태, git add 를 수행하면 됨.
    아직 commit을 안한 상태이기때문에 변경사항이 영구적으로 저장된 상태가 아님을 나타냄.
   
* 커밋

    git commit -m "Changes for a and b"
    혹은 vi등 편집기를 통해 메시지 편집 시에는 그냥 git commit

    주의) 파일 수정후 add, 다시 파일 수정후, commit 을 하면,
    2번째 수정 사항은 staging안된 상태이다.
    커밋을 해도 2번째 수정 사항은 저장안됨.
    이때는 2번째 수정 사항에 대한 add 도 수행하고 그것에 대한 commit도 다시 수행 해야함.
   
* 이력보기

    git log git log --pretty=oneline --max-count=2
    git log --pretty=oneline --since='5 minutes ago'
    git log --pretty=oneline --until='5 minutes ago'
    git log --pretty=oneline --author=<your name>
    git log --pretty=oneline --all
    git log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short
    git log --all --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short

    아직 커밋 안된 상태 에서 변경 사항 알아내기
     
        git diff HEAD 파일명       
        HEAD란 최종 커밋을 의미.

    2개 커밋 간 변경된 파일 목록 조회     
   
        git diff --name-only <commit hash1> <commit hash2>

    각 commit 별 변경된 파일 목록 조회

        git log --name-status


* 이전 버전 가져오기

    git log --all --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short
   
    * cdb6848 2012-07-18 | 3 commit (HEAD, v1, origin/master, master) [kojunghyen]
    * b5cda22 2012-07-18 | 1st [kojunghyen]
    * 2314983 2012-07-18 | 2 commit [kojunghyen]
    * ece0e9f 2012-07-18 | first commit [kojunghyen]
   
    git checkout <hash>
   
    ex: git checkout 23149839d82ce5f104aa6fba72b201566da44ec6
   
    다시 master branch의 최신 버전으로 돌아오려면,
   
    git checkout master
   
    'master’ is the name of the default branch.
    By checking out a branch by name, you go to the lastest version of that branch.
   
   
* 태그 붙이기

    현재 버전을 v1이라고 하기로 하자.
        git tag v1
   
    바로 이전 버전을 가져오는 방법
        git checkout v1~1 => v1^
       
        ^ notation to indicate “the parent of v1”   
    이 이전 버전을 v1-beta라고 태그를 붙이자.
        git tag v1-beta
   
       
* 태그 조회
   
    git tag


* stage->un-staged 상태로 변경하기

    git reset HEAD myfile


* 수정한 내용을 무시하고 처음 상태(최근 커밋된 버전으로)로 되돌리기

    git checkout -- myfile


* 커밋된 변경 되돌리기

    git revert HEAD
   
    This technique will work with any commit (although you may have to resolve conflicts).
    It is safe to use even on branches that are publicly shared on remote repositories.


* AMENDING COMMITS (커밋 수정하기, 혹은 기존 커밋에 추가하기)

    git commit --amend 

    add, commit된 상태에서 수정이 발생하였고 이전 커밋에 포함하고 싶은 경우(2개의 커밋생성없이).

* 여러개의 COMMIT들을 하나의 C OMMIT으로 합치기
    다음처럼 커밋 히스토리가 존재할때
    git log --oneline
    -->
    commit4
    commit3
    commit2
    first commit
    3,4 커밋을 합치고 싶은 경우,

    git rebase -i HEAD~2
    pick .......
    pick .......
    이것을 다음 처럼 변경  (출력 순서 주의 : 제일 위가 제일 오래된 커밋 이다, git log 와 반대)
 
    pick     ...
    squash ...
       
* MOVING FILES

    git mv hello.rb lib

    혹은 add 후 제거,

    git add lib/hello.rb

    git rm hello.rb
   
   
* branch 만들기
   
    git checkout -b 브랜치명

    => 이후 브랜치내에서 작업을 수행하고 commit한다.

    브랜치를 선택할 경우는

    git branch -a

    => 브랜치들을 리스트업, 이후 선택할 브랜치를 checkout 하면 됨

    git checkout master

    git checkout greet

   
* branch 제거
   
    git branch -d 브랜치명
   

* Merging

    git checkout greet

    git merge master

    => master변경분을 greet에 merge시킨다.


    예: clean_up branch를 만들고 작업후 master branch로 돌아와서 merge수행시
    git merge clean_up
   
   
* branch 변경 비교하기

    git diff --color branch1..branch2


* branch내에서 commit간 변경 비교하기

    git diff --color commit_hash1 commit_hash2

    => hash 시작 문자 일부만으로도 가능.


* 충돌 해소

    여러개의 BRANCH간 CHECKOUT시 불일치 발생 경우면 수동으로 해당 파일 수정후 ADD, COMMIT.


* branch push/pull 하기

    자신이 생성한 branch 를 원격저장소에 push

    git push origin my-branch


    원격 브랜치 가져오기: 먼저 원격 브랜치 확인

    git branch -r

    git checkout -b 생성할브랜치이름 원격브랜치이름

    동일한 이름을 사용한다면 -t 옵션 사용

    git checkout --track 원격브랜치이름


* REBASING VS MERGING

    rebase는 말 그대로 베이스를 다시 잡는 작업이다.
    변경사항을 적용할 기준(베이스) 브랜치를 지정하고 현재 브랜치의 변경사항을
    그 기준되는 브랜치에 적용을 하여 선형적인 커밋 히스토리를 만들어주므로
    지저분하지 않게 된다.

    다음설명이 가장 잘 이해됨.
    Choose to merge when you have a feature on a separate branch and want to bring that
    code into master or another branch.(feature branch 만들어서 다른branch 와 합칠거면
    merge 를 사용해라. 즉 일반적인 용도에 사용)

    Choose to rebase when you want to stay in sync with the main branch
    when you’re working on a long-lived side branch.(없어지지않고 계속 사용될 branch 와
    main branch 가 일치된 내용으로 가고싶을경우 rebase를 사용해라)

    다음 링크에서도 rebase 에 대해서 그림으로 잘 설명됨.
    rebase를 사용하지 말자는 내용임. feature branch에서 에러가 발생되면 rebase 시 
    모든 commit 에 에러가 포함되는 문제를 지적하고 있음. 
    그냥 간단하게 merge 를 사용하는게 좋다.
    https://medium.com/@fredrikmorken/why-you-should-stop-using-git-rebase-5552bee4fed1

    When to Rebase, When to Merge?
        Don’t use rebase … 커밋 히스토리를 변경시키기 때문이다.
        http://stackoverflow.com/questions/3357122/git-pull-vs-git-fetch-git-rebase
      
        정확한 커밋 히스토리가 중요한 경우에는 리베이스 사용을 자제.
   
    하지만 동일한 branch인 경우에는 선택의 여지가 있음 (아래 git pull 참고)


* add a remote repository

    git remote add origin git@github.com:jeremyko/try_git.git


* git fetch

    원격저장소의 변경사항 가져와서 원격브랜치를 갱신.


* Pushing Remotely

    로컬 변경을 origin repo (on GitHub)에 반영한다.
    -u 옵션은 입력인자들을 기억하는 옵션이다.
    이 경우 다음부터는 git push 만 입력하면 된다.
   
    git push -u origin master
   

* Pulling Remotely

    git pull
   
    remote repository의 변경사항을 가져온다. 그런데 pull명령은 다음과 동일하다.
   
    git fetch 
    git merge origin/master

    즉 변경 내용을 가져온후, 로컬의 변경사항과 머지하는작업이 동시에 일어난다.

    git pull --rebase
   
    pull 사용 시 매번 merge commit 이 생기는게 필요없는 경우
    (즉, 동일한 master branch만 pull로 가져오는 경우, master 브랜치끼리 merge commit 은
     불필요 할수 있으므로)
    --rebase 옵션을 주면 merge commit log 가 발생 하지 않게되어,
    좀 더 직관적인 이력관리가능.
   
* log 

    commit history 로그 보기.
    특정 사용자의 commit history 만 보고 싶다면, git log --author=userid

    특정 파일에 대한 log를 보고 싶으면, git log /xxx/yyy/source.hpp   

* stash

    만약 local의 변경 사항을 임시로 저장했다가 나중에 다시 적용하고 싶다면 'git stash' 로
    변경사항을 stash 한 다음, git stash list 로 목록을 확인할수 있다.
    예를 들면, feature branch에서 이슈에 대한 수정을 진행 중인데, master branch로 패치된
    내용을 반영하고 작업을 해야 하는 경우, commit 후에 master branch와 merge 할 필요없이
    stash로 수정사항을 보관 후, master 와 merge 후 다시, 작업 중이던 수정 사항을 반영 하면
    다시 이전과 같은 개발 중 상태가 된다.
   
    'git stash apply' 명령을 pull 작업 이후에 실행해서 재 적용 시킨다.
    git stash drop 을 수행해야 list 에서 삭제된다.
    (git statsh apply 대신 git stash pop 을 수행하면 자동으로 list 에서 삭제된다)
   
   
* cloning

    원격 저장소에 있는것을 복제하기 위해서는 git clone을 사용한다.
   
    git clone https://github.com/jeremyko/kothreadpool.git 

    git clone user@61.40.220.178:/path/rep_name.git my_repo_name

* Mac 사용시, .DS_Store 파일이 커밋되는것을 막으려면

    http://hints.binaryage.com/how-to-remove-ds-store-files-from-a-git-repo/


* local GIT Server 설정

    동일한 서버에서 여러 개발자가 개발하는 경우 간단하게 설정 가능.
    서버 위치는 /USER/kojh/serverRepository.git 디렉토리라고 가정.
    소스 존재 위치는 /USER/kojh/MySrc 라고 가정(이미 git init된 상태).

    1. remote 서버 역활 구성
   
        cd /USER/kojh/serverRepository.git
   
        git init --bare
   
   
    2. 소스를 서버에 push
   
        cd /USER/kojh/MySrc
   
        git remote add origin /USER/kojh/serverRepository.git
   
        git push -u origin master
   
   
    2. 개발자 1 의 작업
   
        git clone /USER/kojh/serverRepository.git dev1WorkSpace
   
        git remote add origin /USER/kojh/serverRepository.git
   
   
    3. 개발자 2 의 작업
   
        git clone /USER/kojh/serverRepository.git dev2WorkSpace
   
        git remote add origin /USER/kojh/serverRepository.git
   
   
    4. 이제 개발자1,2 가 일반적인 commit, push, pull 을 수행.