리파지토리 관리를 어떻게 가는게 좋을까요?

[SeongJae Park]

안녕하세요, 박성재입니다.

어제도 잠깐 이야기가 나왔지만, repository 관리를 어떻게 할지 공론을 해보면 어떨까 하는데요.

기존에 존재하는 방식을 보면, 디테일하게 더 따질 부분이 많지만 일단 간략화 시켜보면 제 생각엔 다음과 같이 분류를 할 수 있지 않을까 싶은데요.

1. svn과 마찬가지로 그냥 push.

(이미 우리 모두 메인 repository에 push 권한이 있습니다)

2. 각자 fork를 따고 중앙 관리자(누가 될지 모르지만)께 pull request

3. 각자 맡은 부분에 대해 maintainer가 되어 자기껀 직접, 남의껀 pull request

제 개인적 생각으로는 2번이 가장 깔끔하게 히스토리 관리가 될 것 같긴 한데, 중앙 관리자 분이 피곤해질 것 같고,

github / git 공부의 효과도 있을 수 있는 3번이 어떨까 싶습니다만...

어떻게들 생각하시는지요?

[Jimmy Moon(문현경)]

개인적으로 선호하는 방식은 2번이고 yeoman 이나 grunt 커뮤니티에서 사용하는데요. 리뷰가 필요하거나 리뷰나 의견을 받을 만큼 많은 changes 를 가진다면 PR 그게 아니고 새로추가되는게 아니라 문자 수정 등의 마이너한 것을 직접수정을 하고요. 그리고 개인적으로는 2번이 git 을 가장 잘 사용하는 방법이 아닐까 싶습니다. fork 후에 upstream(gpgstrudy) 를 등록하고 아래 명령을 통해서 최신 데이터를 계속 merge 만 해준다면 잘 사용할 수 있습니다. 올리는 부담도 별로 없고요.

workflow 는 fork 는 이미 한 상태에서 

- git fetch origin -v; git fetch upstream -v; git merge upstream/master 로 최신 데이터를 다시 가져오고

- coding

- add and commit

- push origin master

- PR request 

이렇게 합니다.

다음은 원재님이 달라고 이야기 하셔서 제일 많이 사용하는 3개 첨부합니다. ;)

alias glog="git log --graph --pretty=format:'%Cred%h%Creset %an: %s - %Creset %C(yellow)%d%Creset %Cgreen(%cr)%Creset' --abbrev-commit --date=relative"

alias gaa='git add -A;git commit -a -m '$2''

alias gpu='git fetch origin -v; git fetch upstream -v; git merge upstream/master'

alias gfu='git pull --rebase upstream master'

[Jimmy Moon(문현경)]

아 추가로.. 전체 버전 관리는 별도의 branch 로 가는 방법도 있고 master 는 항상최신 그 다음 버전 발행은 tag 를 만드는 방법도 있습니다.

2013/7/25 Jimmy Moon(문현경) <ragin...@gmail.com>

[nurinamu]

저도 2번이 좋아보입니다만, 자원해주시는 분이 나타나지 않으시면 현실적으로는 3번이 되어야할 듯 합니다.

개인적으로 제가 git 관리를 하겠어요! 라고 손들고 싶지만 현재 업무들을 보다보면 잘 할 수 있을지 의문이네요.

자원하실 분 계신가요?

2013년 7월 25일 오전 10:46, Jimmy Moon(문현경) <ragin...@gmail.com>님의 말:

--
Google 그룹스 'Google Cloud Platform Lab - GCP Lab' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에서 탈퇴하고 더 이상 이메일을 받지 않으려면 google-cloud-platf...@googlegroups.com에 이메일을 보내세요.
http://groups.google.com/group/google-cloud-platform-lab에서 그룹을 방문하세요.
더 많은 옵션을 보려면 https://groups.google.com/groups/opt_out을(를) 방문하세요.
 
 

[Jimmy Moon(문현경)]

maintainer 는 어떻게든 뽑아야하니.. maintainer badge 받을실분은 어서.. 하하. 아무래도 go 를 리뷰해주셔야 하니. 쿨럭. 전 일단 탈락입니다. 아 뱃지 아깝네요. 

전 

First Timer Attender, First PR 두개 가지고 있네요. 아까비.

2013/7/25 nurinamu <nuri...@gmail.com>

[Jimmy Moon(문현경)]

Timer 라니... ㅋㅋ

2013/7/25 Jimmy Moon(문현경) <ragin...@gmail.com>

[Jimmy Moon(문현경)]

제가 '재활훈련'을 해야해서 모임에 정기적으로 나가거나 제가 하나 턱하니 맡아서 하기 힘든데요. 하시다가 저한테 투척하실 것 있으시면 github issue 로 알려주시면 온라인으로 가능한 해보도록 하겠습니다. 짜잘한걸로다가 mention 해서 주세요 :)

2013/7/25 Jimmy Moon(문현경) <ragin...@gmail.com>

[이원제]

지금 모임에서 나온 이야기를 정리하자면,

각자는 gcplab 을 fork에서 사용하고

gcplab에 dev branch를 만들어서 pull request를 받는다.

정기적으로 모임에서 dev branch에 대해 다같이 확인한 이후에 dev->master merge를 한다.

가장 문제는 dev branch의 pull request를 confirm을 누가하냐 인데.

일단 자기가 생각하기에 너무나 마이너한 변경이라면 자신이 confirm,

하지만 수정이 많거나 모듈의 검증이 필요하다면 자신이 생각하기에 가장 적합한(?) 사람에게

요청을 보내 review받고 confirm되도록.

일단은 여기까지 이야기된 상태입니다.

의견들 주시고 없는 동안은 위의 상황으로 진행하시죠~

[Jimmy Moon(문현경)]

네 저번 오프처럼 제가 PR을 종민님이 리뷰해주시면서 인텐트 이야기 해주고 그러면 될 것 같은데여.

2013/7/31 이원제 <nuri...@gmail.com>

[Jongmin Kim]

네 일단은 현재 dev 브랜치가 gcplab/badge의 default branch로 해뒀습니다.

각자 fork해서 작업하다가 소소한 작업은 그냥 본인이 merge하고

수정이 좀 많거나 최소한 한 명이라도 코드리뷰를 했으면 좋겠다 하는 것은 dev 브랜치로 pull request 보내면서 누구 한 명을 assign 해서 그 assign 받은 사람이 리뷰하고 merge 하는 걸로 하시죠~ assign 받은 사람이 바빠서 한 동안 리뷰 못 하고 있으면 다른 사람이라도 보고 merge 해주고요.

일단은 이 방법으로 해보다가 시행창오 겪으며 문제 있으면 좀더 보강하고요.

2013년 7월 31일 오후 7:38, Jimmy Moon(문현경) <ragin...@gmail.com>님의 말: