AI Convergence

공개팀으로 Git을 운영하는데는 비공개팀과 약간의 차이가 있다. 공개팀 운영시에는 모든 사람이 공유 저장소에 대해서 쓰기 권한이 없기 때문이다. 프로젝트 관리자는  Fork를 지원하는 Git 호스팅에서 -GitHub- 기여하는 방법에 대해 가이드 해야 한다. GitHub을 예로 Pull Request는 어떤 절차로 이루어 질까?

1) 갑순이 Fork 질 하기 

  - 갑순이 중앙 저장소(예, ysyun)의 GitHub에서 Fork질 하여 자신의 원격 저장소(예, nulpulum)를 하나 만든다  

    + GitHub의 갑순이 계정으로 로그인한다 

    + GitHub의 중앙 저장소(ysyun)로 이동하여 "Fork" 버튼을 클릭하면 갑순이 계정으로 중앙 저장소(nulpulum)가 clone된다 

     [GitHub Fork 클릭]

  - 갑순이 원격 저장소(nulpulum)를 자신의 PC 로컬 저장소로 clone 한다 : git clone <갑순이 원격저장소>

  - 갑순이의 원격 저장소 이름을 origin에서 myfork로 바꾼다

    + git remote -v : default 설정된 origin 명칭 확인 

    + git rename origin myfork : origin을 myfork라는 이름으로 변경 

2) 갑순이 별도 브랜치 만들고 push 질 하기 

  - 갑순이 별도의 featureA 브랜치를 만들고 두번의 commit 질 한다 

    + git checkout -b featureA : featureA 만들기 

  - 간혹 commit  실수 한것은 날려 버리고 싶다 : git reset --hard HEAD^ (참조)

  - 갑순이의 원격 저장소(nulpulum)인 myfork에 featureA를 push 한다 (참조)

    + GitHub 의 commit 내역은 "Commit" 탭에서 확인가능하다 

  [GitHub Commit]

 [갑순이 GitHub 저장소(nulpulum)의 featureA 브랜치]

3) 갑순이 Pull Request 질 하기 

  - 갑순이는 수정한 사항에 대하여 중앙 저장소(ysyun)의 관리자에게 Pull Request를 요청하여 자신이 수정한 것을 가져가라 알린다

    + 갑순이 GitHub 계정으로 들어가서 상단의 "Pull Request"를 클릭한다 

 [갑순이 GitHub 저장소(nulpulum)의 Pull Request 버튼 클릭]

    + Pull Request 원하는 브랜치를 선택한다 

    + 갑순이 원격 저장소(nulpulum)에서 featureA를 선택하고 중앙 저장소(ysyun)에게 Pull Request를 보낸다

    + featureA에 commit 두번 한것과 파일 수정 정보등이 보인다 -Commits (2) Files Chagned (1)-

  [Pull Request 요청 내역 입력한후 "Send pull request" 보내기]

    + 중앙 저장소 (ysyun)에서 Pull Request온 내역을 볼 수 있다 

 [중앙 저장소(ysyun)의 Pull Request 내역 보기]

  - 가급적 Pull Request를 할때는 별도의 토픽 브랜치(갑순이가 만든 featureA)와 같이 만들어서 관리자에게 요청한다 

    + master 브랜치와 구분하고 수정 내용을 거부할 때 쉽게 버릴 수 있다

  - 갑순이 다른 브랜치를 만들어서 작업할 때는 featureA에서 하지 말고 origin/master에서 한다 

    + git checkout -b featureB origin/master

<참조> 

  - Pro Git (p. 110)

  - 2개 아이디의 Public repository를 만들어서 테스트 해보았다.

비공개 대규모 팀을 운영할 때는 Git Workflow에서 Integration-Manager 방식을 선택한다. 이는 팀별로 별도의 Master를 두고 Integration Manager가 중앙 Master로 push할 수 있는 권한을 갖도록 한다. 즉, 중간 단계의 master가 하나 더 있는 구조이다. 

1) 가정

  - 갑순이는 두 팀에 속한다 

  - 1팀 갑순이 + 갑돌이

  - 2팀 갑순이 + 갑복이 

2) 1팀 갑순이 featureA만들어 갑돌이와 작업

  - 갑순이는 저장소를 clone하고 featureA 브랜치를 만들고 수정후 커밋한다 

    + feautreA 브랜치 생성 : git checkout -b featureA

    + 커밋 : git commit -am "add function"

  - 갑순이가 해당 브랜치를 갑돌이와 공유하려 한다. 

    + 여기서 갑순이는 Integration Manager가 아니다

    + 갑순이는 운격 저장소에 featureA로 push 하고 갑돌이에게 해당 사실을 알린다 

3) 2팀 갑순이 featureB 브랜치 만들어 갑복이와 작업

  - 갑순이는 갑복이와 원격 저장소의 master 브랜치를 기반으로 featureB작업을 계속 수행하기로 한다

    + 원격저장소에서 로컬 저장소로 fetch 하기 : git fetch origin

    + git checkout -b featureB origin/master

  - 갑순이가 몇가지 작업을 하고 featureB에 커밋을 한다 

    + git fetch origin

    + git checkout -b featureB origin/master

    + 2번의 커밋객체 생성 : git commit -am "modified some function" (e5b0f) -> git commit -am "add new function" (85127)

   [그림 5.12] 갑순이 현재 로컬 저장소 커밋 그래프

  - 갑순이 featureB를 push 하려는데 갑복이로부터 이미 featureBee 브랜치로 한번 push 했다고 연락을 받는다

    + 갑복이 내역을 merge 하기위해 fetch 한다 : git fetch origin

    + 갑복이 브랜치를 merge 한다 : git merge origin/featureBee

  - 갑순이 이제 featureB를 원겨 저장소로 push 하려는데 갑복이 featureBee 와 이름이 틀리다

    + 로컬 featureB를 원격 featureBee로 push 한다 : git push origin featureB:featureBee (cd685)

4) 1팀 갑돌이 featureA 작업

  - 갑돌이 featureA 작업후에 push 했고 갑순이에게 확인요청한다 

  - 갑순이는 내역확인을 위하여 원격저장소에서 fetch 한다 : git fetch origin 

  - 갑순이는  featureA 브랜치에 어떤 것이 업데이트 되었는지 확인한다 (갑돌이 커밋시 메시지 잘 입력했다 가정함)

    + 변경내역 확인 : git log origin/featureA ^featureA 

    + 확인후 로컬 featureA 브랜치로 이동 : git checkout featureA

    + 원격 featureA를 로컬 featureA에 merge 수행 : git merge origin/featureA

  - 갑순이 다시 일부 수정하여 featureA 브랜치를 원격 저장소로 push 한다 

    + git commit -am "small tweak"

    + git push origin featureA (774b3)

    + 갑순이의 저장소를 보자 

  [그림 5.13] featureB도 원격으로 push하고 featureA도 원격 저장소로 push한 갑순이 로컬 저장소 

5) 갑순이 메인 브랜치로 merge 요청작업 

  - Integration-Manager는 두 브랜치를 merge 하고 메인 브랜치의 커밋 (5399e) fetch해 온다 

  - 다음과 같은 구조가 될 것이다 

  [그림 5.14] integration manager는 774b3 과 ce685 커밋을 merge하여 5399e를 원격저장소에 커밋한 후 갑순이가 fetch 함!

<참조>

  - Pro Git 5장 108p

소규모 팀으로 일을 할때 어떤 절차에 의해서 소스를 Merge하고 원격저장소로 Push 할 수 있는지 알아보자. 팀원간 Git 기본 workflow로써 가장 기본적으로 숙지해야할 사항이라 판단된다. 

1) 가정 

  - 3~5명이 하나의 원격 Git - 예, GitHub Private Repository - 에 원본을 합친다 

  - 각자가 local repositor로 내려 받아서 작업을 한다 

2) 갑순이 push 작업

  - 갑순이가 GitHub에서 저장소를 복제한다 : git clone <git address>

  - 갑순이가 하나의 파일에 대해서 수정하고 commit 한다 : git commit -am "modified files"

  - GitHub에 변경된 파일을 push 한다 : git push origin master

3) 갑돌이 push 작업

  - 갑돌이도 GitHub에서 저장소를 복제한다 

  - 값돌이도 다른 파일 하나를 수정하고 commit 한다 

  - GitHub에 변경된 파일을 push 한다 => 오류가 발생하여 파일 push를 하지 못한다 

4) 갑돌이 push 오류 해결하기 

  - 갑돌이는 Push 하기전 원격저장소의 갑순이 commit 내역을 로컬 저장소에 merge 해야 한다 

  - 갑돌이는 먼저 원격 저장소의 내용을 fetch 한다 : git fetch origin

   [그림 5.4] origin에서 fetch를 하면 origin/master가 된다(fbff5) 로컬의 master (738ee)와 merge는 안된 상태

  - 로컬 master와 원격 origin/master를 merge 한다 : git merge origin/master

  - 갑돌이는 merge를 완료하고 push를 재시도 한다 : git push origin master  (origin master 생략가능)

  [그림 5.5] merge를 했을 때 새로운 commit object가 생성된다 (72bbc)

  [그림 5.6] push를 하게되면 origin/master의 위치도 최신 commit object를 가르키게 된다 (72bbc)

5) 갑순이 branch 생성후 push 추가작업

  - 갑순이는 이슈해결을 위하여 별도 issue54 브랜치를 만들었다

  - issue54 브랜치에 대해서 3개의 commit을 수행하였다. 

  - 원격으로 push 하기 위하여 먼저 원격의 갑돌이 push 내역을 fetch 한다 : git fetch origin

  [그림 5.8] fetch하여 원격의 origin/master를 가져온다 (72bbc)

  - fetch 해온 origin/master 와 merge할 내용을 확인한다 : git log --no-mergs origin/master ^issue54

  - merge를 위하여 master 브랜치로 checkout 한다 : git checkout master

  - 먼저 issue54 부터 merge 한다 : git  merge issue54

    origin/master 와 issue54 브랜치는 모두 master 보다 fast-forward 된 브랜치 이기 때문에 순서에 상관없이 merge해도 된다

  - 다음 origin/master 를 merge 한다 : git merge origin/master

  [그림 5.9] local의 issue54를 merge하고, origin/master와 merge를 하면 새로운 commit object가 생성된다 (8059c)

  - 로컬 저장소에 모드 merge 되었으므로 원격 저장소로 push 한다 : git push origin master 

  [그림 5.10] push를 하게되면 origin/master가 가르키는 commit object는 최신 8059c 가 된다. 

6) 최종 Workflow 모습

  - 갑순이 == Jessica

  - 갑돌이 == John

  [그림 5.11] push -> fetch -> merge -> push 작업이 이루어진다     

<참조>

  - Pro Git : 5장 page 104

Git commit 할 때 가이드 라인을 잘 지켜서 원격 저장소에 소스가 꼬이지 않도록 하고, 커밋된 내역을 잘 이해할 수 있도록 메세지 작성 정책에 대해 알아보자

  - 공백 문자를 깨끗이 제거 한다 : 확인)  git diff --check (공백 문자 오류확인가능, 잘 못 사용한 공백은 X 문자로 바꿈)

  - 최대한 수정사하을 하나의 주제로 요약한다

    + 여러 가지 이슈에 대한 수정사항을 하나의 커밋에 담지 말아라

    + 적절한 메세지를 작성한다 : 반드시 좋으 커밋 메세지를 담는다

  - 같은 파일의 다른부분을 수정하는 경우에는 git add -patch 명령을 이용한다 

    + 한 부분씩 나누어 Stage 영역에 저장해야 한다 

  - 메세지 작성

    + 첫줄엔 50자내로 간략히 요약

    + 두번째줄 비우고 세번째줄에 자세히 설명글 :개발동기, 구현 상황, 제약조건/상황

    + 글은 현재형을 사용한다 

    + 추가 내용은 한줄 띄우고 시작한다 

    + 잘쓰여진 커밋 메세지는 git log --no-merges 명령으로 꼭 살펴본다 

   예)

Git은 분산 버전관리 시스템이다. 서로 각자의 저장소를 가지고서 어떻게 충돌없이 잘 사용할 수 있을지 알아보자. (5장)

1) 중앙집중식 Workflow

  - 예전의 Subversion에 익숙한 사용자들의 방식

  - 예로 2명이 작업, 한명이 서버로 update코드 push하면 다른한명이 서버에서 update코드를 pull하여 merge 수행

  - 모든 사용자에게 서버에 push 권한을 부여해야 함

  - 그러나 중앙 서버 저장소로 a코드가 다른이에 의해 push 되었고, 다른사람이 a코드를 수정하여 push해도 Git은 이것을 방지해 준다. 즉, 다시 로컬로 fetch 또는 pull 하지 않으면 중앙 서버로 push 할 수 없게 막아준다

2) 통합관리(Integration-Manager) Workflow

  - 여러 리모트 저장소를 두고 한개는 R/W 가능, 다른 한개는 R만 가능하게 설정가능 하다

  - 이것은 GitHub의 운영방식이다. Pull Request 수행하면 통합관리자가 이것을 보고 기여자의 저장소에서 원본 저장소로 pull하여 merge 하게 된다

3) 독재자 보조관(Dictator and Lieutenants) Workflow

  - 2)번 형태의 확장판

  - Linux Kernel과 같은 큰 프로젝트에서 사용한다 

* 다양한 변종의 Workflow가 존재함 

<참조>

  - 성공적인 Git Branch 전략 (한글번역본 - dogfeet)

    + feature : 기능 만들기 

    + develop : 개발진행

    + release : 릴리즈 

    + hotfixes : 긴급 패치 

    + master : 원본 

Git의 열거형 명령을 하나의 Alias로 지정할 수 있다. 설정 방법을 알아보자 

1) Alias 설정하기 : git config --global alias.[Alias명] '[명령]'

  - Ustage상태로 변경 : git config --global alias.unstage 'reset HEAD --' 로 설정하면 하기 명령은 동일하다 

    $ git unstage fileA

    $ git reset HEAD fileA 

  - last 명령 : git config --global alias.last 'log -l HEAD'

2) 많이 사용하는 git alias : 참조사이트 

* 현 브랜치의 히스토리를 short SHA값, author 정보, 커밋 트리 그리고 히스토리에서 특정 커밋을 가르키는 refs(브랜치, 태그)보기

  $ git config --global alias.lg "log --name-status --color --abbrev-commit --date=relative --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset'"

  $ git lg 결과를 색깔별로 보여줌 

* 브랜치를 중심으로 히스토리를 보고 싶을 경우

  $ git config --global alias.tree "log --graph --decorate --pretty=oneline --abbrev-commit --all"

  또는 $ git config --global alias.lol 'log --oneline --graph --decorate'

  $ git tree 또는 git lol 수행 결과

* Visual 윈도우에서 변경 내역 보기 

  $ git config --global alias.visual '!gitk'

  $ git visual 을 수행하면 하기 화면이 뜬다 

<참조>

  - dogfeet alias 설정

  - 개발자 하루 alais 설정

  - 자료 : 민트기술

   Git-Guide-r1.pdf

SVN의 Tag처럼 Git에도 Tag가 있다. 어떻게 사용하는지 보자 

1) Tag 조회하기 : git tag 

  - 특정 버전 조회시 git tag -l 'v1.4.2.*' 식으로 조회한다

2) Annotated Tag 붙이기 : git tag -a [버전] -m '[메시지]'

  - Tag를 만든 사람의 이름, 이메일, 날짜, 메시지를 저장함. 단순 Tag일때는 Lightweight Tag를 사용함 

  - Tag 정보와 커밋 정보 보기 : git show [버전]

3) Lightweight Tag : git tag [버전]

  - 브랜치처럼 가리키는 지점을 최신 커밋으로 이동시키지 않는다. 단순 특정 커밋에 대한 포인터일 뿐임 (체크섬만을 저장할 뿐)

  - -a, -s, -m 등의 옵션을 사용하지 않는다 

4) Tag 검증하기 : git tag -v [버전]

  - GPG 서명을 검증하는 것으로 공개키가 필요하다

  - 서명 메시지가 없으면 하기와 같은 error 메시지가 나옴 (다음 기회에 다시 알아보자)

5) 나중에 Tag 하기 : git tag -a v1.2 [해쉬값 앞 7자리] -m '[메시지]'

  - 과거 특정 커밋에 대해서 Tag를 달 수 있다. 커밋 내역 확인하기 : git log --pretty=oneline

6) Tag 공유하기 : git push origin [버전]

  - 서버로 Branch를 push 하는 것과 동일하다 

  - 한번에 여러 개의 tag를 push 하기 : git push origin --tags

GitHub에 만들어 놓은 저장소 관리를 알아보자. 

1) 리모트 저장소 확인하기 

2) 리모트 저장소 추가하기 : git remote add [단축이름] [url] 

3) 리모트 저장소를 Pull, Fetch 하기 : git fetch [remote-name] 

   - fetch : clone 이후 변경된 데이터를 모두 로컬로 가져온다. 그러나 자동 Merge는 하지 않는다. 수동 Merge해야 함

   - pull : 리모트 저장소 브랜치에서 데이터를 가져와서 현재 작업하는 로컬 브랜치와 Merge 한다. 

4) 리모트 저장소에 Push 하기 : git push [리모트 저장소 이름] [브랜치 이름]

5) 리모트 저장소 살펴보기 : git remote show [리모트 저장소 이름]