git diff HEAD 2a8fe28

git diff HEAD 2a8fe28  -p > patch

git apply patch


apply patch.



Posted by 용식

fork된 repository에 대해서 원본 repository로부터 최신 소스를 받아오는 방법.


1. 원본 repository : http://github.com/need4spd/org.git

     forked repository : http://github.com/need4spd_sub/org.git


2. 원본 repository는 계속 commit이 push되고 있는 상태이고, forked repository에서 개별적인 작업을 진행하고 있는

상황이라고 가정


3. forked repository에서..

git remote add origin http://github.com/need4spd_sub/org.git

git remote add original_repo http://github.com/need4spd/org.git

로 forked repository와 원본 repository의 alias를 생성


4. pull 해보자

git pull original_repo master:master

 -> original repository의 master에서 내 local의 master pull

 -> fast foward로 merge가 안되는 경우 reject가 될 수도 있다.

! [rejected]        master     -> master  (non-fast-forward)


5. original_repository를 fetch 후 local에서 merge해보자

git fetch original_repo


.. 로그 중 

* [new branch]      master     -> original_repo/master 라고 보임..


git checkout -b original_master original_repo/master  (original_repo/master로부터 branch 생성)

git checkout master

git merge original_master




Posted by 용식
TAG git

git pull을 하는데 갑자기 아래와 같은 오류가 났다.


remote: internal server errorfatal: 

protocol error: bad pack header


스레드 생성 오류가 나면 메모리를 늘려주는것 같은데..

이건 그 케이스도 아니라서.. 찾아보니 현기형님 블로그에 똻!

(http://eclipse4j.tistory.com/178)


해결방법은

git remote prune origin

git gc --auto


git pull origin 실행시 발생하였는데, local과 remote간 branch가 차이가 많아

한번 정리를 해줘야하는건가.. 싶네.


Posted by 용식
TAG git

git checkout master

git fetch origin

git checkout -b localbranchname origin/branchname

git branch

Posted by 용식
TAG git

[git] merge squash

git/github 2013.11.06 11:35

git merge branchname --squash -Xignore-space-change

Posted by 용식
TAG git

처음 git을 접한 후 개인프로젝트에만 사용을 하면서 항상 쓰게되는 명령어만 사용하다가 

쿠팡에 온 후 애자일팀의 소스관리를 git으로 하게 되면서 혼자 쓰던것보다는 좀 더 많은 명령어를 사용하게 되었다.

몇권의 책도 읽고 했었지만 거의 사용하지 않았던 명령어가 대부분이었는데 최근 몇개월 git을 본격적으로 쓰면서 다시 pro git 책을 읽기로 마음을 먹었다.


사용하면서 "있었으면 좋겠는데.." 했던 기능들..하지만 내가 모르고 있는.. 그런 기능들도 다시 한번 찾아보고 싶고..

경험상 분명히 이해도가 예전과는 다를것이라서..


그래서 책을 재독하면서 그러한 내용들을 추가로 정리해보기로...


1. git add [directory] 하면 디렉터리 아래에 있는 모든 파일이 재귀적으로 추가된다.

 - 평소에는 git add . 만 거의 사용..


2. tracked 상태의 파일을 수정 후 git add [filename]을 하면, 그 파일은 staged 상태가된다.

여기서 다시 그 파일을 수정하면 그 파일은 staged이면서 unstaged상태가 된다.

이 상태에서 commit하게 되면 처음 수정하여 staged되었던 내용만 commit이 된다.


3. gitignore에서 디렉터리는 슬래시를 끝에 사용하는 것으로 표현


4. git diff는 워킹디렉토리 - staging area, git diff --staged는 commit - staging area

- 수정한 파일이 모두 staging area에 들어가 있다면 git diff는 아무것도 보여주지 않는다.


5. 그냥 파일을 삭제하면 unstaged상태, git rm 으로 삭제하면 staged 상태


6. git rm --cached [filename]은 staging area에서만 파일을 제거하고, 실제 워킹 디렉터리의 파일은 삭제하지 않는다. (.gitignore 파일에 추가하는 것을 빼먹었거나 했을 때 유용함)


7. git mv [sourcefile] [targetfile]은 아래의 명령어를 차례로 실행한것과 동일

- mv sourcefile targetfile

- git rm sourcefile

- git add targetfile


8. git log -p -2

-  최근 2개의 커밋히스토리와 각 커밋의 diff 결과를 확인


9. git log --pretty=format:"%h - %an, %ar : %s"

- format의 예제


10. git log --since-2.weeks

- 지난 2주동안의 커밋 히스토리 조회


11. 커밋의 수정은 git commit --amend

- staging area를 사용해서 commit하기 때문에, 마지막 커밋 후 수정한 것이 아무것도 없다면 커밋 메시지만 수정하게된다.

- 커밋 후 빠트린 파일이 있다면 아래의 명령어로..

 1) git commit -m 'init'

 2) git add forgotten_file

 3) git commit --amend


12. 예전 commit에 대해서 tagging하기

 - git tag -a [tagname] [commit hash]


13. alias 설정

- git config --global alias.co checkout


14. HEAD

 - 지금 작업하는 로컬 브랜치를 가리키는 포인터

 - git checkout [branch]로 현재 브랜치로 이동하면, HEAD로 옮겨진 branch를 가리킨다.


15. Fast forward

 - A브랜치에서 다른 B브랜치를 Merge할때 B가 A 이후의 커밋을 가리키고 있으면 A가 B의 커밋을 가리키도록 하는데 이러한 방식을 이야기함


16. git branch -v

 - 브랜치 리스트와 마지막 커밋 메시지를 보여줌


17. git push origin serverfix:serverfix

 - 로컬 브랜치와 리모트 브랜치 이름이 다를때 유용


18. fetch 후 리모트 브랜치에서 시작하는 새 브랜치 만들기

 - git checkout -b [local-branchname] [origin/remote-branchname]

혹은

- git checkout --track [origin/remote-branchname]


19. 공백문자 체크

 - git diff --check

 - 잘못된 공백문자를 'X'로 표시


20. 커밋은 논리적으로 구분하는 Changeset이다. 여러 가지 이슈에 대한 수정사항을 하나의 커밋에 담지 말자.


21. 커밋메시지는 첫 줄에 50자가 넘지 않는 간략한 요약정보. 그리고 한 줄을 비우고 그다음 줄부터 커밋에 대한 자세한 설명을 적는 가이드라인이 있음


22. 작업한 내용을 프로젝트의 공유 저장소에 push하고자 할 때에는 우선 origin/master 브랜치를 fetch하고 Merge한다. (git merge origin/master)


23. git show HEAD^ (HEAD의 부모 커밋)


24. git log origin/master..HEAD

 - origin 저장소의 master 브랜치에는 없고 현재 checkout중인 브랜치에만 있는 커밋보기


25, Stash가 적용된 브랜치 만들기

 - git stash branch [branchname]


26. 아래 3개는 모두 같음

 - git log origin/master

 - git log remotes/origin/master

 - git log refs/remotes/origin/master



Posted by 용식
TAG git, progit

local branch 삭제는


git branch --delete <branch_name>


입니다.


remote branch 삭제는


git push <repository> :<branch_name>


입니다.


ex> git push origin :branch_hotfix



Posted by 용식

git을 사용하다보면 checkout이나 rm등을 할 때 여러 파일들에 대해서 작업을 진행해야 하는 경우가 있다.

몇가지 파일을 수정 후 "git status" 명령어로 조회하면


modified: a.java

modified: b.java

modified: c.java


이런 형태로 나오는데, 이를 다시 롤백하려면 "git checkout -- a.java" 이런식으로 파일명을 적어줘야 한다.


rm도 마찬가지... "git rm a.java b.java" 형태가 되어야 한다.


이럴때 git ls-files 명령어를 사용하자.


git checkout -- $(git ls-files --modified)

git rm $(git ls-files --deleted)


뒤에 붙은 조건은 좀 더 여러가지가 있겠다.


git ls-files --help 로 메뉴얼을 읽어보자

Posted by 용식

git config --global core.editor "\"c:\Program Files (x86)\Git\bin\vi\""

Posted by 용식
TAG git

[Git] rebase

git/github 2013.06.18 00:10

이런 명령어가 있는줄도 몰랐었고.. (ㅋㅋ --;)

지금도 좀 어려운 rebase입니다. progit에서 보면 merge를 하긴하는데.. 일반적인 merge와는 다르게 작동을 합니다. 

보통 rebase는 리모트 브랜치에 깔끔하게 적용하고 싶을때 사용한다고하네요..

실제로 rebase 후에 커밋 히스토리를 보면 갈라졌던 브랜치의 커밋 히스토리가 선형으로 변경되는 것을 보실 수 있습니다.


progit에서 나오는 케이스 중 첫번째 rebase 설명에 대한 예제만.. 소스트리를 통해 확인해보았습니다.


우선, 마스터 브랜치와 br1 브랜치가 나누어져 커밋이 되어있는 형태입니다.

이 상태에서 merge를 하면 3-way merge가 발생합니다. 



- 3-way merge가 된 후의 커밋히스토리입니다. 새로운 커밋이 생긴것이 확인가능하고, b1 브랜치의 커밋 히스토리도 그대로 남아있습니다.


하지만 rebase를 하게되면 최종 커밋이 가지고있는 결과는 같으나, 커밋 히스토리는 사뭇다릅니다.

일단, br1 브랜치에서  rebase 명령어를 실행합니다.


git checkout br1

git rebase master


위 명령어는 br1 브랜치의 마지막 커밋을 패치로 만들어서, 이를 C3에 적용합니다.


- rebase전


- rebase 후..


보시면 C2가 C3 이후로 변경된것이 확인 가능합니다. 이 C2에는 C3의 내용도 당연히 포함이 되어있습니다.

그리고 처음 rebase를 위와 같이 하고나면 실제 master는 여전히 C3를 가리키고 있습니다. br1이 C2를 가르키고 있고요.. 책에서는 "rebase후 master 브랜치를 fast-forward 시킨다" 라고 되어있는데...

저 같은 경우는 그냥 merge 명령어로 master 브랜치의 포인터를 C2로 옮겼습니다.


이제 br1 브랜치를 삭제하면 되겠죠..




역시 뭐든 개념을 알고 덤벼야하는것 같습니다.. --;

Posted by 용식