2014년 1월 27일 월요일

Concept git rebase and example

오전 6:47 Posted by jonnung 1 comment
git으로 코드의 버전관리를 하면서 브랜치 작업을 많이 하게 되는데 사실 난 브랜치 생성을 좀 즉흥적으로 하는 감이 없지 않아 있다.

무언가 작은 것이라도 개발을 할 때는 브랜치 계획을 어느정도 수립해 놓게 되면 느닷없는 브랜칭으로 커밋 로그가 복잡해지는 일은 없을 것 같는 생각이 든다.

브랜치를 사용하면서 개발을 하다 보면 어느 순간에는 머지(merge)를 하기 마련이다.
그런데 예전에 Git 브랜치 배우기을 해보면서 git에 merge와 결과는 같지만 동작 방식이 다른 리베이스(rebase)라는 기능이 있다는 사실을 알게 되었다.
그때 rebase 예제를 풀어보면서 개념 부족으로 상당히 오랜 삽질을 했던 기억이 난다. 윽..

아무튼 일단 rebase와 merge의 차이에 대한 결론부터 정리하자면 아래와 같다.


Merge는 결과를 합치고

Rebase는 과정을 비교하여 결과와 같이 합친다.

rebase와 merge의 차이를 간략하게 알았다면, 언제 rebase를 써야하는 지가 가장 중요하다.

위에서 말 했듯이 브랜치를 merge 하게 되다보면 히스토리가 복잡해지기 마련이다.
rebase를 사용하면 이런 히스토리를 깔끔하게 정리할 수 있는 효과가 있다고 보면 된다.

간단한 예제를 직접 해보면서 rebasemerge의 차이와 명령어를 좀 더 자세히 알아보겠다.


Base History


일단 merge와 rebase를 비교하기 위해 적당한 히스토리를 만들어 보겠다.
number.txt 라는 새로운 파일을 하나 만든다.
적당히 내용을 입력하고, master 브랜치의 stage영역에 추가(add) 후 커밋(commit)을 했다.
그리고 또 한번 number.txt 파일의 2번 줄의 문장을 변경 하고, 다시 한번 commit을 한다.

123456789
Number content.

이제 2명의 개발자가 각각 브랜치를 만들어 내용을 수정하는 과정을 진행 하겠다.
첫번째 개발자의 브랜치명은 dev-1, 두번째 개발자의 브랜치명은 dev-2로 정했다.

일단 dev-1 개발자가 먼저 파일을 2번 수정하고 각각 2번 commit 했다.

0123456789
Number content!!!

아직까지 dev-2 개발자는 파일을 수정하지 않았다. 그런데 이번에는 master 브랜치에서 파일의 수정이 한번 더 발생 했다. (파일 내용은 생략)

그리고 이제 dev-2 개발자가 자신의 브랜치에서 파일을 수정한다

0123456789
9876543210
10 Numbers contents.

그리고 마지막으로 다시 master 브랜치로 돌아와 새로운 내용을 한번만 더 추가 했다.

123456789
987654321
192837465
Number content.

자 이제 모든 수정이 완료 되었다. 횟수는 적지만 약간 복잡하게 파일 수정이 발생했고, 중간 중간에 master 브랜치의 내용도 수정이 되면서 상황은 점점 악화 되고 있다.

벌써부터 conflict의 그림자가 발밑까지 와있는 느낌이다.

제가 이렇게 히스토리를 만든 이유는 히스토리 그래프를 이해하기 쉽게 만들기 위함과 conflict 발생시 해결하는 과정 그리고 merge와 rebase의 차이점 모두를 담기 위함이 였습니다. 돌 던지지는 마세요. ㅠ_ㅠ)a

현재 상태에서 merge와 rebase를 각각 진행 해보겠다.


Merge


일단 현재 브랜치가 master 인지 확인하고, dev-1 브랜치를 merge 한다.

$ git branch
  dev-1
  dev-2
* master


Cap 2014-01-25 13-27-29-679



$ git merge dev-1

위와 같이 master와 dev-1브랜치 사이에 conflict가 발생했다고 알려준다. 그렇다면 에디터를 열고 number.txt 파일을 원하는 형태로 직접 수정을 해주고 계속 진행을 해야 한다.

<<<<<<<< HEAD
123456789
987654321
192837465
Number content.
=======
0123456789
Number content!!!
>>>>>>> dev-1

'======='을 중심으로 위쪽은 master 브랜치쪽 내용, 아래쪽은 dev-1 브랜치쪽 내용 이다.
123456789
987654321
192837465
Number content!!!

위 결과처럼 dev-1 브랜치의 내용 중 마지막 'Number content!!!'만 병합 하도록 수정 했다.
conflict를 해결하고 머지를 마무리하는 머지 커밋(Merge commit)을 한다.

$ git add number.txt
$ git commit
[master bc64d16] Merge branch 'dev-1'

Cap 2014-01-25 13-58-35-547

그리고 dev-2 브랜치도 위와 동일한 방법으로 master브랜치에 merge 한다.

$ git merge dev-2 
# 에디터에서 Conflict를 해결하고 다시 커밋!

$ git add number.txt
$ git commit
[master 2195143] Merge branch 'dev-2'

Cap 2014-01-25 14-09-07-136


Rebase


이제 rebase를 해보겠다.

이번에는 merge때와 위치하는 브랜치가 다르다는 것을 주의 해야 한다. 아래와 같이 rebase가 되는 토픽 브랜치(Topic)로 checkout 하고 master 브랜치로 rebase를 하도록 명령어를 실행 시킨다.

$ git branch
  dev-1
  dev-2
* master

$ git checkout dev-1
$ git rebase master

Cap 2014-01-25 14-21-04-841



여기서 rebase의 특징이 나오게 된다. Git은 변경 이력을 모두 비교하면서 병합을 시도 하기 때문에 위와 같이 conflict가 발생하는 것을 알려주고 처리 방법을 제안 한다.

123456789
<<<<<<< HEAD
987654321
192837465
Number content.
=======
Number content!!!
>>>>>>> 마침표를 느낌표 3개로 변경

저는 아래와 같이 수정하여 conflict를 해결하고 stage 영역에 올려놓고(add) 다음 rebase를 진행 한다.

123456789
987654321
192837465
Number content!!!


$ git add number.txt
$ git rebase --continue

다음 리비전에서의 conflict도 위와 동일한 방법으로 해결하고 계속 rebase를 진행 한다.

$ git add number.txt
$ git rebase --continue


$ git rebase --skip

Cap 2014-01-25 14-32-27-288
$ git checkout master
$ git merge dev-1

Cap 2014-01-25 14-32-56-525



dev-2 브랜치에 대해서도 위와 동일한 방법으로 master 브랜치에 rebase 한다.

$ git checkout dev-2
Switched to branch 'dev-2'

$ git rebase master


$ git add number.txt

$ git rebase --continue


$ git add number.txt
$ git rebase --continue
Applying: 더 자세한 내용 정의 문장으로 수정


$ git checkout master
Switched to branch 'master'


$ git merge dev-2
Updating bad6d94..258c855
Fast-forward
number.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

Cap 2014-01-25 14-39-35-832

이제 필요 없어진 dev-1과 dev-2 브랜치는 삭제 한다.

$ git branch -d dev-1 dev-2
Deleted branch dev-1 (was bad6d94).
Deleted branch dev-2 (was 258c855).

Cap 2014-01-25 14-40-00-703

위에서 각각 해 본 rebase와 merge는 결과는 같지만 보여지는 커밋 트리들의 차이가 있는 것을 알 수 있다.

2014년 1월 12일 일요일

Git 기본 명령어 정리와 참고하면 좋은 링크 정보

오후 5:01 Posted by jonnung No comments
 작년에 처음 Github를 알게 되면서 Git을 배워볼 기회가 있었다.
개인적으로 진행하는 스터디에 활용을 해보기는 했으나, 당시 회사에서 사용하는 버전관리 프로그램으로 SVN에서 머큐리얼(Mercurial)로 전환하는 시기였다.
그러다 보니 머큐리얼도 학습하게 되었고, 사용하게 되면서 당연히 Git보다는 머큐리얼을 사용하는 비중이 높아졌다.

 하지만 시간이 흐르면서 Github에서 소스 코드를 검색하고, 참고하는 빈도가 증가하는 것을 느끼게 되었다.
 그러면서 드는 생각이 올해는 내가 만든 소스 코드들을 Github에 올려서 전세계 개발자들과 공유하고, 평가 받으며(관심을 끌 수만 있다면..) 핵심적으로는 내가 열정을 갖고 진행하는 것들에 대한 증거를 남기고 싶다는 목표가 생기게 되었다.
 그래서 올 한해 계획을 세우면서 가장 먼저 배우고 능숙하게 다뤄야 하는 기술로 Git을 선정했고, 이번 포스트에서는 Git을 사용하기 위한 기본적인 명령어를 정리해 보았다.

 기본적인 명령어에 대한 구성은 웹 상에서 Git의 기본적인 명령어를 직접 실행해보고, 사용 방법을 배울 수 있는 Code School의 Try Git의 각 단계를 참고 하였다.

 각 명령어에 대한 설명은 Try Git에서 나오는 설명들을 기초로 하였고, 나름 번역을 해보았다.
 Git을 처음 접하는 사람들은 이 포스트를 보는 것 만으로 Git을 사용하기에는 많이 부족할 것이지만 Try Git을 단계별로 학습하면서 참고하면 좋을 것 같다.

Git의 고급 테크닉을 조금 더 능숙하게 다루기 위한 정보를 하나 더 추가 하자면 Git 브랜치 배우기를 추천한다.
Try Git에서 다루지 않지만 Git에서 좋다고 소문난 Rebase와 Cherry pick에 대한 학습에 많은 도움이 되었다.




tryGit

Initializing


Initialize a Git repository

Git 저장소를 생성 한다.

git init


Checking the status


To see what the current state of our project

현재 상태를 확인 한다.

git status


Adding Changes


Notice how Git says 'untracked?' That means Git sees that this is a new file.
추적 되지 않은 새로운 파일이 있다는 의미 한다.

To tell Git to start tracking chang
es made to this file. we first need to add it to the staging area by using git add
파일의 변경 내역을 추적하기 위해 Git의 준비 영역으로 파일을 추가 할 필요가 있다.

git add octocat.txt
git add '*.txt'

Committing All Changes

Notice how Git says 'changes to be committed?' The file listed here are in the Staging Area, and they are not in our repository yet. We could add or remove files from the stage before we store them in the repository.
 git status 명령어로 현재 상태를 확인하면 'changes to be committed'라는 부분을 볼 수 있다.

 여기에 해당하는 파일 리스트는 아직 Git 저장소의 준비 영역에 있는 파일들의 목록이고, 저장소로 보내기 전에 준비 영역에서 추가 하거나 삭제 할 수 있다.

To store our staged changes we run the commit command with a message describing what we've chaged.
준비 영역에서 변경 내역을 저장소로 저장하기 위해서는 남길 메세지와 함께 commit 명령어를 사용한다.

git commit -m "Add cute octocat story"

History

Git's log as a journal that remembers all the changes we've committed so far, in the order we commited them.
Git 로그는 커밋 된 모든 변경 사항에 대한 기록 이다.

git log

Remote Repositories

To push our local repo to the GitHub server we'll need to add a remote repository.
로컬 저장소의 변경 내역을 Github 서버에 push 하기 위해서는 원격 저장소(중앙 저장소)를 추가 해야 한다.

git remote add origin https://github.com/try-git/try_git.git

Pushing Remotely

The push command our local changes to our origin repo (on Github)
push 명령어는 로컬 변경 내역을 origin 이라고 지정한 중앙 저장소로 보낸다.

The name of our remote is origin and the default local branch name is master.
origin은 원격(중앙) 저장소의 이름(닉네임 정도)이고, 기본 로컬 브랜치의 이름은 master 이다.

The '-u' thel Git to remember the parameters, so that next time we can simply run git push and Git will know what to do.
'-u' 파라미터를 추가하면 다음 push 명령어 실행부터는 중앙 저장소와 로컬 브랜치의 이름을 입력하지 않고도 push 할 수 있다.

git push -u origin master

Pulling Remotely

We can check for changes on our Github repository and pull down any new changes.
Github 서버의 변경 내역이 있는지 확인하기 위해서 pull 명령어를 사용해 새로운 변경 사항을 가져온다.

git pull origin master

Differences

Let's take a look at what is different from our last commit by using the git diff command.
로컬 저장소의 최종 커밋 로그와 차이점을 살펴보기 위해서 diff 명령어를 사용 한다.

In this case we want the diff of our most recent commit, which we can refer to using the HEAD pointer
가장 최근의 변경 내역을 비교하려면 HEAD 포인터를 사용해서 조회 할 수 있다.
git diff HEAD

Staged Differences

Another great use for diff is looking at changes within files that have already been staged.
diff는 이미 준비 영역에 있는 변경 내역과의 비교하기에도 좋다.

Staged files are files we have told git that are ready to committed.
준비 영역의 파일은 커밋 되기를 전의 파일을 말한다.

git diff --staged

Resetting the Stage

Unstage files by using the git reset command.
준비 영역의 파일을 삭제하려면 reset 명령어를 사용한다.

git reset octofamily/octodog.txt


브랜치로 하여금 예전의 커밋을 가리키도록 이동시키는 방식으로 변경 내용을 되돌린다. 이러한 관점에서 '히스토리를 고쳐쓴다.'라고 할 수 있다. 이것은 마치 애초에 커밋을 하지 않은 것처럼 예전 커밋으로 브랜치를 옮기는 것과 같다.

git reset HEAD~1

Undo

Files can be changed back to how they were at the last commit by using the command: git checkout -- <target>
마지막 커밋 된 파일로 교체하기 위해서 checkout 명령어를 사용한다.

git checkout -- octocat.txt


위 명령은 로컬의 변경 내용을 변경 전 상태(HEAD)로 돌려놓는다. 하지만 이미 준비 영역에 추가된 변경 내용과 새로 생성한 파일은 그대로 남는다.

Branching out

Code make separate commits to. Then when they're done they can merge this branch back into their main master branch.
새로운 코드는 새로운 브랜치에 커밋을 할 수 있다. 브랜치는 특정 커밋에 대한 참조(Reference)이며, 그 코드가 완료가 되면 다시 master 브랜치와 병합 할 수 있다.

Create a branch call.
branch는 새로운 브랜치를 만들기 위한 명령어 이다.

git branch clean_up

Delete a branch

branch를 삭제하려면 -d 파라미터를 추가하고 브랜치명을 입력 한다.

git branch -d clean_up

Switching Branches

다른 브랜치로 변경 하려면 checkout 명령어와 브랜치명을 같이 입력한다.

git checkout clean_up
git checkout -b clean_up

Removing all the things

Not only remove the actual files from disk, but will also stage the removal of the files for us.
rm은 준비 영역의 파일을 삭제 할 뿐만 아니라 실제 개발자 컴퓨터에 있는 파일도 삭제 된다.

removed all files you'll need to commit your changes.
파일을 삭제한 변경 내역도 커밋해야 한다.

git rm octodog.txt
git rm '*.txt'

Preparing to Merge

The moment has come when you have to merge your changes from the clean_up branch into the master branch.
별도 브랜치의 변경 내역으로부터 master 브랜치로 병합할 때가 오면 merge 명령어를 사용한다.

git merge clean_up

Rebase

브랜치끼리 작업을 접목하는 방법으로 rebase가 있다. 리베이는 기본적으로 커밋들을 모아서 복사한 뒤, 다른 곳으로 떨궈 놓는 것이다.

리베이스를 하면 커밋들의 흐름을 보기 좋게 한 줄로 만들 수 있다는 장점이 있다.

git rebase master

Revert

각자의 컴퓨터에서 작업하는 로컬 브랜치의 경우 reset을 잘 쓸 수 있지만, '히스토리를 고쳐쓴다'는 점 때문에 다른 사람이 작업하는 원격 브랜치에는 쓸 수 없다.

변경 내역을 되돌리고, 되돌린 내용을 다른 사람들과 공유하기 위해서는 revert를 사용해야 한다.

git revert HEAD

Push

All that's left to do is to push everything you've been working on to your remote repository.
모든 것이 완료 되면 원격(중앙) 저장소로 push 한다.

git push




참고하면 좋은 정보

http://rogerdudler.github.io/git-guide/index.ko.html
http://git-scm.com/book/ko
http://marklodato.github.io/visual-git-guide/index-ko.html