설정

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

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

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

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

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"

or 그냥 git commit 을 실행하면, vi등 편집기를 통해 메시지 편집 가능

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

빈 커밋 (empty commit)

간혹 빈 commit 을 만들어서 push 해야 하는 경우가 (github pages 에 실패한 deploy를 다시 수행하는 경우 등등) 있는데, 다음처럼 수행하고 git push 한다.

git commit --allow-empty -m "empty 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 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.

계통 관계로 찾기

이름 끝에 ^ (캐럿) 기호를 붙이면 Git은 해당 커밋의 부모를 찾는다.

git show HEAD^

^ 뒤에 숫자도 사용할 수 있다. 예를 들어 d921970^2 는 “d921970의 두 번째 부모” 를 의미한다.

git show d921970^2

계통을 표현하는 방법으로 ~ 라는 것도 있다. 이것은 이전 commit 을 찾는다.

이 두 표현을 같이 사용할 수도 있다. HEAD~3^2 를 사용하면 증조부모의 Merge 커밋의 부모의 부모를 조회한다.

Git-도구-리비전-조회하기

태그 붙이기

현재 버전을 v1 이라고 하기로 하자.

git tag v1

바로 이전 버전을 가져오는 방법

git checkout v1~  or
git checkout v1^

^ notation to indicate "the parent of v1"

이 이전 버전을 v1-beta 라고 태그를 붙이자.

git tag v1-beta

태그 조회

git tag

태그 삭제 (로컬)

 git tag -d <tag명>

태그 삭제 (원격)

 git push --delete origin <tag명>

태그 삭제 (tag 명이 브랜치명과 같은 경우)

명시적으로 tag임을 지정해서 삭제해야 함

 git push origin :refs/tags/<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들을 하나의 COMMIT으로 합치기

다음처럼 커밋 히스토리가 존재할때

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 에서 삭제된다

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된 상태).

remote 서버 역활 구성

cd /USER/kojh/serverRepository.git
git init --bare

소스를 서버에 push

cd /USER/kojh/MySrc
git remote add origin /USER/kojh/serverRepository.git
git push -u origin master

개발자 1 의 작업

git clone /USER/kojh/serverRepository.git dev1WorkSpace
git remote add origin /USER/kojh/serverRepository.git

개발자 2 의 작업

git clone /USER/kojh/serverRepository.git dev2WorkSpace
git remote add origin /USER/kojh/serverRepository.git

이제 개발자1,2 가 일반적인 commit, push, pull 을 수행.