SVN을 오랫동안 써온 그것도 회사에서 약간 이상하게 써온 나로써는 git과 github에 적응하는데는 많은 시간과 어려움이 있었다.
최근에 계속 고민하게 된것은 두가지인데,
pull request 전에 upstream에 새로운 commit이 올라오면 그것을 merge해서 보내야 하는데 이때 내 만든 commit과 merge한 commit이 두개 올라가는 짜증(?) 나는 상황이 생긴다.
또 한가지는 내가 보낸 pull request가 아직 upstream에 merge되기 전에 pull request를 보내면, 이미 보낸 pull request에 붙어 버리는 문제가 생긴다.
이런 한 것에 대하여 왜(why)를 설명하기 보다는 어떤 방식으로 작업하면 이런 문제가 발생하지 않는가(how)에 대해서 설명하고자 한다.
1. contribute 하고자 하는 repository를 Fork 해온다.
2. local pc에 개발환경 셋업하기.
local pc에 clone 한다.
remote에 upstream 추가하기
3. issue(일감)에 따라 branch하기
앞에 이야기 한 두번째 문제인 pull request가 붙어버리는 문제가 발생하지 않게 하기 위해서는 내가 처리할 이슈(즉 pull request할 부분)을 branch로 분리해서 작업하고 commit(local에 적용)/pull(origin에 적용)/pull request(upstream에 적용요청) 하는 것이다.
사실 일하다 보면 그렇게 미리 지정해서 하기가 잘 안된다. 쉽게 생각했던 issue가 풀리지 않아서 하다가 다른거 하는 경우가 허다하다. 그래서 내 경우에는 master에서 이것저것 만지다가 commit전에 stash로 수정사항 저장하고 new branch를 생성하고 거기서 stash pop하여 commit한다. 여기서는 branch하고 수정하는 걸로 설명한다.
branch를 새로 생성하고 checkout 하기.
issue 수정하기
issue는 wrapMediaTag를 warpMediaTag로 잘 못 쓴 것을 고치는 것이다.
git diff 를 활용하여 아래와 같이 수정상태를 확인 할 수 있다.
4. commit 하고 pull, rebase, push하기
사실 upstream에 변경이 있기 전에 빠르게 commit/pull/pull request를 던지면 제일 좋지만 맘대로 되지 않는다. ㅡ.ㅡ;
rebase 고민 없이 하는 방법이 이슈 수정 및 테스트가 끝났다면 commit하지 말고, stash로 묶어두고 merge후에 stash pop해서 수정한 사항을 재반영하고 빠르게 test 및 commit/pull/pull request를 하는 것이 좋다.
그러나 항상 그럴 수는 없기에 여기서는 commit하고, rebase하고 pull, pull request하는 것으로 설명하겠다.
git에서는 staged 상태라는 개념이 있는데 여기서는 설명하지 않는다. 그냥 -a 옵션으로 커밋!
commit하기
rebase하기
앞에 commit한 log와 비교하면, 새로 갱신된 내용이 내가 새로 commit한 log 전으로 들어오고, 내가 commit한 hash값이 변경된 것을 확인할수 있다. 주의사항은 내가 local에 commit한 것이 다른 곳으로 전달되지 않았을 경우에만 rebase해야 한다.
push하기
5. pull request 하기
이제 github에 들어가면 보면 pull reqest하라는 내용이 나오고, 깔끔한 1 commit을 볼 수 있다.
깔끔한 1 commit
끝~
참고
http://ift.tt/1LmNtMN
http://ift.tt/1caBfeh
http://ift.tt/1JIm1uF
from WordPress http://ift.tt/1AkCfZa
