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 용식

최근 회사에서 git을 사용하게 되면서 progit책을 구입하여 다시 git을 공부하고 있습니다.

github을 통해서 개인적으로는 git을 계속 써오긴했으나 사용하는 명령어가 clone, push, fetch, pull, commit등 주로 혼자 사용하게 되는 명령어로 한정이 되어있던데다가... 지금 회사처럼 많은 개발자가 동시에 사용해본 경험도 없어서 아무래도 한계가 금방 다가오더군요...


progit책에 대한 리뷰는 곧 쓸 예정이긴한데요.. 내용중 merge에 대한 내용을 직접 실습해보면서

정리를 할겸 블로그에 포스트를 남겨봅니다.


merge는 크게 fast-forward와 3-way merge로 나뉘어집니다.


저는 처음에 git에서의 merge가 각 파일의 수정사항을 하나하나 비교하면서 직접 파일의 내용을 가감하는줄 알았습니다. 근데 fast-forward의 경우 그런식의 merge가 아니더라구요..


즉, 아래와 같이 commit이 있을 때..


             master

                 |

C1 - C2 - C3


issue1 branch를 생성하면 아래와 같이 되고..


             master

                 |

C1 - C2 - C3

                 |

              issue1


issue1에서 commit을 하게되면 아래와 같이 커밋히스토리가 생성됩니다.


              master

                 |

C1 - C2 - C3 - C4

                        |

                       issue1


git에서의 commit을 svn처럼 각 파일의 변경내용과 그에따른 리비전 번호가 아닌 repository의 스냅샷입니다.

따라서, C4의 commit에는 이미 C3까지의 commit 내용이 담겨있는 상태입니다. 이상태에서 master로 merge라고 함은.. master의 포인터를 최신 커밋을 가르키고있는 issue1의 포인터로 이동시키는 것입니다. 


                      master

                         |

C1 - C2 - C3 - C4

                         |

                      issue1


이제 master 브랜치에서 다시 작업을 진행(C5 commit) 하고, merge가 되어 불필요한 브랜치인 issue1은 삭제를 합니다.


                           master

                               |

C1 - C2 - C3 - C4 - C5


위와 같은 방식으로 작동하는 merge가 fast-forward입니다.


3-way merge는 조금 다르게 작동합니다. issue1 브랜치를 만든 상태로 다시 돌아가보겠습니다.

              master

                 |

C1 - C2 - C3 - C4

                        |

                       issue1


그러다가, 다른 이슈가 급하게 들어와서 그걸 처리해야 할 일이 생겼습니다. 다시 master 브랜치로 돌아가서 issue2 브랜치를 생성합니다.


               master

               issue2

                 |

C1 - C2 - C3 - C4

                        |

                       issue1


그리고, issue2 브랜치에서 작업을 진행하고 commit을하면 아래와 같은 형태가 됩니다.


            master  issue2

                |       |

C1 - C2 - C3 - C5

                |

               C4

                |

               issue1


issue1과 issue2의 커밋 히스토리가 갈라졌습니다. 이 상태에서 급한게 처리한 issue2를 master에 merge해 적용합니다. 이 경우에는 앞에서 작성한 fast-forward 방식으로 merge가 진행됩니다.


                     master

                     issue2

                        |

C1 - C2 - C3 - C5

                 \

                    C4

                      |

                     issue1


issue2 브랜치를 삭제하고, 다시 issue1으로 돌아가 작업을 진행합니다.


                     master

                        |

C1 - C2 - C3 - C5

                 \

                    C4 - C6

                             |

                          issue1


작업이 모두 끝나고 이제 다시 issue1을 master로 merge합니다. master 브랜치에서 merge issue1을 실행하는 것인데요.. 현재 master의 커밋이 merge할 브랜치의 조상이 아닙니다. C5는 C4, C6과는 아무런 관련이 없죠. 때문에, 두 커밋의 공통 조상을 찾아 (C3) 3-way merge를 진행하고 그 결과를 새로운 커밋으로 만들어 master 브랜치의 포인터가 그 커밋을 가르키도록 합니다.


                                  master

                                       |

C1 - C2 - C3 - C5 ------ C7

                  \                /

                       C4 - C6 

                                |

                             issue1


여기서는 C3, C5, C6이 merge할 커밋으로 선택되어 merge가 되고, 그 결과를 C7 커밋으로 생성하여 master 브랜치의 포인터를 C7으로 옮겼습니다.


위 내용은 모두 pro-git 책이나 progit 사이트에 더 잘 정리가 되어있는 내용입니다. 다만, 처음 git을 사용하면서 merge와 branch의 작동 방식에 대해서 명령어와 결과만 알고 있었지 이렇게 그 원리를 알지는 못 했다가 이번에 책을 보면서 스스로 한번 정리를 해보기위해서 작성해보았습니다.


git을 사용하신다면 progit 책이나 사이트는 꼭 읽어보시면 좋을것 같습니다.


다음엔 rebase를 가지고.. 또 공부해봐야겠네요.. 사실 혼자 github으로 쓸때는 정말 쓸일이 거의 없던것이 rebase였는데... 

저작자 표시 비영리 변경 금지
신고
Posted by 용식
TAG git, git merge


티스토리 툴바