티스토리 뷰

놀고있네 연구소/자료실

GitHub

우유수염 2017. 7. 25. 15:19

GitHub는 web과 git을 기반으로 전세계의 개발자들이 공동으로 작업하기 위하여 만든 service 이다. Source code를 관리하는 git과 협업 문서도구인 wiki, 그리고 다중사용자관리 기능 등을 제공하는 service 이다. Git과 github는 다르다. Github를 활용하면 전 세계의 누구든지 각자 자신의 계정을 만들고 그 계정 아래에 저장소 복사본을 만들어서 거기에 자신의 작업 결과물을 올릴 수 있다. 이 때에 우선 적용되는 곳이 복사본 저장소이며 main project에는 영향이 없다. 개인 계정에서 작업한 결과물을 main project에 반영되길 원하는 경우 pull request를 요청하고 main project를 관리하는 사람들의 code review 를 기다리게 된다. Code review가 완료되고 병합이 승인되었다면, main project에 추가한 기능이 들어가게 된다.


Repository (https://github.com)

How to contribute

앞에서 간단히 살펴본 것을 다시 정리해 보면 다음과 같다:

1) Github에 가입하고 계정을 생성한다.
2) 원하는 Project에 가입한다. (관리자의 승인이 필요한 경우가 있다)
3) Web page에 'Fork' button을 찾아서 누른다. 그러면 개인 계정 밑에 그 시점의 저장소 복사본이 생긴다.
4) 작업할 환경, 보통은 개인의 desktop 또는 laptop,에서 git clone 명령으로 자신의 계정에 생성한 복사본을 가져온다.
5) Clone을 해서 local 저장소가 만들어 졌다면, 여기서 바로 작업을 해도 된다. 그러나, main branch가 수시로 변경되는 경우라면, fork와 main branch를 동기화 해 주어야, merge 또는 pull request를 요청할 때 충돌을 피할 수 있다. 그래서 main project를 local 저장소의 원격 저장소 목록에 추가해 준다.
6) 이제 개인의 작업 공간은 2개의 원격 저장소를 갖게 되었다. 필요한 때에 원격 저장소의 내용을 local 저장소에 반영하기 위하여 rebase 명령을 수행할 수 있게 되었다.
7) 그러나, 여기서 문제가 있다. Main project를 원격 저장소에 추가했다면, 여기에 바로 결과물을 합쳐 버릴 수 있기 때문이다. 적절히 권한 관리를 해주거나, 개별 작업자들이 main project 저장소에는 push 하지 않도록 설정을 추가해 주어야 한다.
8) 이제 작업을 위한 준비가 거의 마무리 되었다. 아무래도 fork 한 저장소의 master에 직접 결과물을 올리는 것이 마음에 걸린다면 branch를 추가하여 사용할 수도 있다.

GitHub Workflow (https://guides.github.com/activities/hello-world/)

[각주:1]

Fork repository

Github의 과제는 fork를 해서 project의 복사본을 만들고 여기서 작업한 다음, pull request 를 수행해서 main project와 변경사항을 맞추어 주는 방식으로 협업한다. Github website에 fork 단추를 찾아서 누르면 자신의 계정 아래에 복사본을 만든다. 이후 작업공간에가서 자신의 계정에 있는 복사본을 git clone으로 가져와서 작업하면된다. 복사본에 작업결과물을 올려서 관리한 다음, main branch에 결과물을 합치고 싶은 경우, pull request 를 요청한다.

[note] 저장소에서 clone 하는 것과 fork 하는 것은 어떻게 다른가?

Fork

만약 여러 분이 이미 있는 내용은 그대로 두고, 몇 가지 내용만 변경해서 사용하려고 한다면 fork를 하는 것이 좋다. Fork는 저장소에 있는 모든 (branch 및 commit을 모두 포함한) 내용으로부터 편집가능한 복사본을 만들기 때문이다. 만약 편집하여 사용하던 내용을 원래의 저장소에 반영하고 싶다면 pull request를 요청하여 원래 저장소의 내용에 변경한 내용을 합칠 수 있다. 자세한 설명은 아래 그림에 나타나있다.

Clone

만약 여러 분이 원래 저장소를 그대로 활용하고 직접 접근 및 편집권한을 가지고 있다면 clone 을 사용해도 된다. 아래 그림은 자세한 내용을 보여 주고 있으며, fork 한 저장소를 clone 하는 예시를 포함하고 있다. 

Fork vs. Clone (http://support.rightscale.com/12-Guides/Chef_Cookbooks_Developer_Guide/04-Developer/Source_Control_Management_Systems/GitHub/Clone_vs._Fork/index.html)

[각주:2]

 

Clone repository

원래 저장소로부터 fork 과정을 완료했으면, fork 저장소를 자신의 local 저장소에 복사하여 작업을 시작할 수 있다. Local에서 작업한 결과물을 push 하면 fork 저장소에 반영된다. 최종적으로 원래의 저장소에 작업한 변경내용을 반영해야 하는데, 이 때는 pull request를 사용해야 한다. 또한 작업이 진행되는 동안 원래 저장소의 내용이 바뀔 수 있으므로 적절히 동기화를 해주어야 하는데, 동기화 방법에 대해서는 아래 add the remote repository에서 자세히 다룬다.

$ git clone https://github.com/YOUR_USERNAME/FORK_REPOSITORY.git        # or $ git clone git@github.com:YOUR_USERNAME/FORK_REPOSITORY.git 

 

Add the remote repository

원래 저장소와 fork 저장소를 동기화 하기 위해서는 git의 기능을 이용하여 upstream 저장소를 추가해 주어야 한다. 이 과정을 하지 않으면, 시간이 흘러갈수록 fork 저장소의 내용과 원래 저장소의 내용이 달라지게 된다.

$ git remote add upstream git@github.com:/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git     # or $ git remote add upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git $ git remote -v origin https://github.com/YOUR_USERNAME/YOUR_FORK.git (fetch) origin https://github.com/YOUR_USERNAME/YOUR_FORK.git (push) upstream https://githug.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (fetch) upstream https://githug.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (push) 

[caution] Project your upstream/master branch

사용자 스스로 master 에 잘못 올리거나 헷갈리는 것을 방지하는 좋은 방법은 다음과 같이 no-push 설정을 지정하는 것이다 (no-push 대신 유효하지 않은 어떠한 값을 지정해도 되지만 명확하게 push를 하지 말라는 의미를 담기 위해서 no-push 로 url을 지정하는 것이 좋다).  

$ git remote set-url --push upstream no-push  

 

Make a local branch

필요에 따라 local 저장소에서 branch를 생성해서 작업을 진행할 수 있다. 이렇게 하면 master 가 자주 바뀌어도 영향이 적게 되어서 좋고, 현재 작업 중인 내용을 branch 이름으로 지정할 수 있어서 혼동을 방지할 수 있다.

$ git checkout -b your-newbranch $ git branch -a  * dev   master   test 

Update from remote

때때로, 사용자가 자신의 공간 (fork 해서 가져온 저장소)에서 작업을 하는 동안 remote branch (fork 해서 가져온 저장소의 원본) 에 변화가 생길 수도 있다. 그러한 경우 몇 가지 명령어를 통해 변경된 내용의 쉽게 따라잡을 수 있다.

1) Upsteam으로부터 상태를 최신으로 만든다.
2) Fork 저장소의 master로 check out 한다.
3) Fork 저장소를 upstream 의 master로 동기화 한다. Rebase를 사용할 수도 있고 merge를 사용할 수도 있다.
4) 변경사항을 Fork 저장소의 master에 적용한다.

여기까지하면 main stream의 master와 fork repository의 master가 동기화 된다. 이 후 부터는 fork master로부터 동기화 하고 작업하면 된다.

$ git fetch upstream remote: Counting objects: 75, done. remote: Compressing objects: 100% (53/53), done. remote: Total 62 (delta 27), reused 44 (delta 9) Unpacking objects: 100% (62/62), done. From https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY * [new branch] master -> upstream/master
$ git checkout master Switched to branch 'master'
$ git rebase upstream/master Updating 34e91da..16c56ad Fast-forward README.md                 |    5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)

$ git merge upstream/master Updating a422352..5fdff0f Fast-forward README | 9 ------- README.md | 7 ++++++ 2 files changed, 7 insertions(+), 9 deletions(-) delete mode 100644 README create mode 100644 README.md

 

Squash the commits down into a single one

Pull request 를 보냈을 때 commit 이 많은 경우 내용을 파악하기에 어려움이 있을 수 있다. 이러한 경우, fork 저장소의 master 또는 branch 의 commit 내용을 합칠 수 있다. 이 작업을 수행하기 위해서 가장 먼저 현재의 commit 내용을 편집없이 재조정하겠다는 명령을 실행한다. 그 다음, 원격 저장소 중 upstream 을 기준으로하여 rebase 명령을 실행하면, commit log를 편집할 수 있는 화면이 나타난다. 편집기를 사용하여 대표로 사용할 commit 을 골라 그대로 두고 나머지는 'pick' 을 'squash' 로 고친다. 편집을 할 때, 'pick' 으로 표시한 commmit은 그대로 유지되고 'squash'를 선택한 commit은 다른 commit에 합쳐진다. Commit 이력을 단순하게 만드는 것이 목표이기 때문에 대표 commit을 선택하고 나머지는 squash 로 적용한 다음 저장한다.

$ git commit --amend --no-edit 
$ git rebase -i upstream/master pick f392171 Update the manifest file of voicegateway app. for load test environment pick ba9dd9a Added new elements to page design pick df71a27 Added a new ansible file of variables for voicegateway configuration 
pick f392171 Update the manifest file of voicegateway app. for load test environment squash ba9dd9a Added new elements to page design squash df71a27 Added a new ansible file of variables for voicegateway configuration

Commit 이력을 재조정하였다면, 이제 branch에 반영해야 한다. 기존 정보를 덮어쓰기 위하여 강제 설정을 추가하여 git push 명령을 수행한다. Github의 pull request 를 가서 보면 commit 이 합쳐져 있는 것을 확인할 수 있다.

$ git push -f origin  

[caution]

만약 다른 작업자에게 이미 공유한 commit 이라면 압축/축소 작업을 하지 않는 것이 좋다. 공유한 이력을 변경해버리는 것은 많은 문제를 일으키기 때문이다.


 

  1. GitHub Workflow (https://guides.github.com/activities/hello-world/) [본문으로]
  2. Fork vs. Clone (http://support.rightscale.com/12-Guides/Chef_Cookbooks_Developer_Guide/04-Developer/Source_Control_Management_Systems/GitHub/Clone_vs._Fork/index.html) [본문으로]

댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
글 보관함