Git & Gerrit 교육과정이론과실습 2017 TwoSeed,Inc.
1.1 Git 의배경이론 2017 spring TwoSeed presents
교육시작전에 이번교육내용은 Perforce 등기존 Tool 에익숙한개발리더들을대상으로 Git 을왜도입해야하는지에대한공감대를만들고자연스럽게 Git 이퍼져나가도록하기위해만들어진과정입니다. 손에익지않은도구는쓸모없는도구입니다. Git 과 Gerrit 이아무리개념이좋더라도손에익지않음무용지물이니, 이번교육을통해재미있게개념도공유하고손에익혀보아요.
들어가며... 전세계를주도하는무선사업부개발자...
지금까지 Perforce 를능숙하게다루던능력자들이라면 Git 이뭐야? 뭐긴하겠지만 난깃알못!!!
Git 을도입하겠다는이야기를듣는다면이런표정아닐까요?
하지만 GIT 을우습게보다간 이렇게열받고, 눈커지고, 소리지르게될일이있을지모릅니다. 그래서기존에비해 Git 이어떻게달라지는지같이보도록할께요.
참고사이트 볼만한사이트들알려드릴께요. 튜토리얼 : http://wiki.twoseed.co.kr GIT : http://rogerdudler.github.io/git-guide/index.ko.html Git-SCM : https://git-scm.com/book/ko/v1 Atlassian Git Tutorial : https://www.atlassian.com/git 참고자료 & 인터뷰 DVCS-GIT : https://www.slideshare.net/ibare/dvcs-git SVN : https://www.slideshare.net/einsub/svn-git-17386752 Subversion Vs. Git : https://www.slideshare.net/ienvyou/subversion-vs-git-42605130 Rebase? : http://dogfeet.github.io/articles/2012/git-merge-rebase.html : https://nolboo.github.io/blog/2013/10/06/github-for-beginner/ : http://techholic.co.kr/archives/31767
Git!= Perforce,SVN GIT 을처음들어보면이런생각들이들수있습니다. GIT? GitHub? GIT?, inline command, GiT? Branch, Tag??? Merge, Rebase... Push, Pull, Pull Request???... 또 p4 와비슷한것같지만막상해보면많이달라서, 직접겪어보면아리송한게꽤많다는거죠. 일단 GIT 이뭐길래깃깃거리는지... 지금까지잘쓰던도구를왜버리고 Git 으로가야한다는건지같이둘러보겠습니다.
짧게보는 Git 의역사 " 우리네삶의삼라만상처럼 Git 또한창조적파괴와활활타오르는갈등속에서시작됐다."
Let there be light Git - Let there be light
As is Git Git 의현재 Git 은 2005 년탄생하고나서아직도초기철학를그대로유지하고있다. 그러면서도사용하기쉽게진화하고성숙했다. Git 은미친듯이빨라서대형프로젝트에사용하기도좋다. Git 은동시다발적인브랜치에도끄떡없는슈퍼울트라브랜칭시스템이다 중앙집중형 분산형
Global Information Tracker? (http://techholic.co.kr/archives/31767). random three-letter combination that is pronounceable, and not actually used by any common UNIX command. "global information tracker": you're in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room. "g*dd*mn idiotic truckload of sh*t": when it breaks
Why Git? SVN 과 Git 에대한시간에따른관심도변화 Google Trend 분석 Leaderboard of Java Tools
So many books, info but 주위에서흔히볼수있는 git 가이드들은무척친절합니다. 하지만, 다른도구숙련자들에게는오히려혼란스럽습니다.,... why (?). Git.
1.2 Git 의구조이론 2017 spring TwoSeed presents
Perforce Vs. git 지금부터 Preforce 를기준으로 git 을설명드리겠습니다. Perforce 저장소 Repository 내컴퓨터 Working Space Repository 내컴퓨터 Working Space Working Space 저장소 그런데 git 에선저장소가내컴퓨터에있어요.
그럼혼자서만일하나요? 팀이같이일해야하는데 안될리가없죠. 저장소를외부에도만들면됩니다. 이것을원격저장소 Remote Repository 라합니다. 내컴퓨터 Working Space commit Repository 저장소 push Remote Repository 평소에내컴퓨터의 Repository 에저장해두고협업이필요할때원격저장소에 Upload 하는데이것을 Push 라고합니다.
Staging DB 서버에바로올릴경우, 생길수있는여러위험때문에일단올려두고 DBA 승인하에 deploy 가됩니다. git 에선 repository 에 commit 하기전에후보가된다는뜻에서 staging 이란개념이생겼습니다. 이곳을스테이지영역이라고하고, 인덱스 (index) 라고도부릅니다. Tracked File - Repository / /. Untracked File -. (add Tracked File )
Snapshot Perforce 는 Meta 파일과변경내역을조합하여최신버전의파일을만들고전달합니다. 반면 git 으로최신버전파일들을가져올때는오른쪽과같이최신의스냅샷으로만들수있습니다. git 은복잡한연산과정없이, 마지막에해당하는스냅샷들만으로최신버전을아주빠르게조합할수있습니다. 심지어 Local Repository 에서일어나기때문에네트웤으로인한 Lack 도없습니다. ( 4X ~ 300X 까지 faster) 체감하기에도엄청빠릅니다. 이런개념은 git 의철학인비선형적인개발 (Branch) 을위해만들어졌습니다. https://upload.wikimedia.org/wikipedia/commons/1/1b/linux_distribution_timeline.svg
분산형 버전콘트롤시스템 Perforce 우리가일했던 Perforce 가이렇게 commit 을할때마다 Repository 에저장되는구조였다면 Git 은 local repository 에 commit 해두고 Remote Reposotory 에 push 하는구조입니다. 이런구조를 D-VCS 라고합니다.
Why D-VCS? 이렇게로컬저장소가따로있어서어떤점이좋은지 3 가지특징을알려드릴께요. 1. 일단 commit 할때엄청빠릅니다. Why? = speed,. SSD? git commit 4, 325.
Why D-VCS? 2. Commit 할때그까이꺼하고부담없이할수가있습니다. 흠흠... 뭐라하든내컴터인데요뭐... Why? = freedom, conflict
Why D-VCS? 3. 네트웤문제가있거나, 서버가교체중이라도계속버전관리가가능합니다. (SVN 때처럼서버문제로개발자전원이멘붕되는사태는없겠죠 ) Why? = redundancy,.
GIT (DVCS) 의구조 - DAG "Directed Acyclic Graph" master Object (Tree Detail) SHA-1 Hash 100644 blob ace23...gitignore 100644 blob dbdbd...gitattributes sndg1.. 040000 tree a0bc3.. Assets 040000 tree 33d33.. ProjectSettings Object 100755 blob b1de7.. build.sh 100755 blob 7011e.. README.md Filemode Type SHA-1 Parent Tree Committer Auyhor tsd3d.. sndg1.. this sndg1..
GIT (DVCS) 의 Branch 구조 모든 Commit 은 Snapshot 으로저장되며, Branch 와 Master 의분할작업역시각 Snapshot 에대해포인터로연결됩니다. master Branch Head master
GIT 의 workflow 전략 분산환경하에서의대표적인 3 가지 Workflow 기준모델을제시합니다. 중앙집중식 Workflow Integration-Manager Workflow Dictator and Lieutenants Workflow Integration Dictator Shared Repository Blessed Repository Blessed Repository 개발자 개발 개발 개발자 Dev private Dev public Dev public Lieutenant 개발자 Dev private Dev public Dev public Lieutenant
Git Commands & Wrap up 앞으로다룰명령어를한장의그림으로정리해보았습니다. Git는분산소스관리시스템이다. Git은빈디렉토리는추적하지않는다. ( 최소한번커밋해야추적시작 ) 관리하지않을파일은.gitignore 파일에추가한다. HEAD 는현재브랜치의가장최신 커밋을의미한다. Checkout Clone 기본원격저장소를 origin 라고 부른다. 기본브랜치를 master 라고부른다.
1.3 Git 의사용실습 2017 spring TwoSeed presents
1.3-1. Git 기본설정 - Git Chapter Target Step #1 Step #2 Step #3 Git 설치 사용 정보및환경설정 폴더생성및초기화 OS 환경에알맞은설치 설치가능한제품 설치진행 사용자기본정보등록 명령어를통한부가환경설정 (Optional) 작업공간생성 초기화명령어사용 작업준비완료및참고사항 Local Install Setting Init
1.3-1. Git 기본설정 1. 설치하기 Linux 설치 : Linux에서 Git을설치시에는각 OS의배포판에서사용하는 Package 관리 Tool을사용한다. Fedora 계열 (RedHat, CentOS) $ sudo yum install git-all Debian 계열 (Unubtu) $ sudo apt-get install git-all Windows에서설치하기 : 필요한 Installer를다운받아설치진행 ( 취향에맞게선택활용 ) Windows용 Git 다운로드 : http://git-scm.com/download/win Totoise Git: http://code.google.com/p/tortoisegit/ (msysgit의추가설치필요 : http://msysgit.github.io/) Atlassian SourceTree: https://ko.atlassian.com/software/sourcetree GitHub: http://windows.github.com GitSwarm: https://www.perforce.com/ko/git GitLab: https://about.gitlab.co m/downloads/
1.3-1. Git 기본설정 2. 초기설정 Linux 에서설정 (Console 기반 ) I. /etc/gitconfig : 시스템의모든사용자와모든저장소에적용되는설정. git config --system 옵션으로이파일을수정 II. ~/.gitconfig, ~/.config/git/config : 특정사용자에게만적용되는설정. Git config global 옵션으로이파일을수정. III..git/config: 이파일은 Git 디렉토리에있고특정저장소 ( 혹은현재작업중인프로젝트 ) 에만적용. 각설정은역순으로우선시된다. (`.git/config`의설정이 `/etc/gitconfig`보다우선적용.) a. Git 설정내역은사용자홈폴더의.gitconfig 파일에저장되어있으며직접편집또는 Config 명령어를활용하여사용자계정정보를등록한다. ( 필수 ) $ git config global user.name "< 사용명 >" $ git config global user.email "< 메일주소 > b. 출력메시지의색상변경을원하는경우 ( 선택 ) $ git config global color.ui auto c. 기본 Editor 변경 ( 선택 ) $ git config --global core.editor vim d. 명령어를단축키로사용하기위해설정 (ex, Commit 을 cm 으로대체 ) ( 선택 ) $ git config global alias.cm commit e. 설정확인 $ git config --list
1.3-1. Git 기본설정 2. 초기설정 Windows / MAC 에서설정 (GUI 기반 )
1.3-1. Git 기본설정 3. 새저장소 ( 로컬작업공간 ) 설정 1) 작업 Directory 생성 2) 생성된작업 Dir 로이동하여 Git 초기화명령을통해저장공간지정 $ mkdir workdir $ cd workdir $ git init Initialized empty Git repository in /Users/yourname/Desktop/ workdir/.git/ 3) 모든작업을완료시 Git 을통해사용할기본준비가완료되며생성한지정 Dir 에서파일을추가 / 변경등의작업을통해 Version 관리를할수있는기본환경이구성 4) 참고사항 Git 은 DVCS 이므로기존다른도구와달리개인별설정이우선함에유의 개인이저장소를생성하거나원격의저장소에서파일을받기위해서는반드시폴더지정및초기화가필수 4. Git 파일구조 1) HEAD 현재 Branch 의가장마지막 Commit 파일 2) Index (Stage) Index 는워킹디렉토리에서마지막으로 Checkout 한브랜치의파일목록과파일내용을기록하며, Commit 시반영할정보를관리 3) Working Directory 실제작업을진행하는 Dir
1.3-1. Git 기본설정 * 시작시참고할내용 1) Git 은빈디렉터리는추적하지않음 2) 형상관리를하지않을파일은.gitignore 파일에추가 (Android studio 및 Eclipse 등의개발도구사용시주로사용 ) 3) HEAD는현재브랜치의가장최신커밋을의미 ( 다른버전관리도구의 Tip revision과유사 ) 4) Origin은기본원격저장소를의미 5) 모든파일추가및변경작업후에는반드시 add 명령을사용하여 Staged 상태로전환필요 6) Git은변경이력을 Reverse delta 방식의 Change set으로관리하는기존도구와달리 Snapshot 방식으로변경을저장 (Staging Area에있는데이터의스냅샷에대한포인터, 저자나커밋메시지같은메타데이터, 이전커밋에대한 포인터등을포함하는커밋개체 ( 커밋 Object) 를저장 )
1.3-2. Git 기본명령어사용 Git 을사용하는가장기본적인명령어에대한이해및활용 (add, Commit, push) Chapter Target Step #1 관리 File 의추가 (ADD) Step #2 추가된 File 을로컬저장소에등록하여이력관리 (Commit) Step #3 로컬저장소에등록된 File 을원격저장소에공유 Source 및 File 을 Version 관리하기위해작업공간에추가 추가된파일을식별하여등록 Status 명령을활용하여상태확인 등록된파일의저장소반영 로컬저장소에반영된파일의버전관리 원격의저장소에반영 로컬에서반영된내용을원격의저장소에공유 / 반영 Local Remote Add Commit Push 개발자 Staging Local Repository Remote Repository
1.3-2. Git 기본명령어사용 1. ( File ) 1) Add : File Folder Staging Commit 2) Process Local 3) : add / Stage (Index)
1.3-2. Git 기본명령어사용 2. 형상등록 ( 로컬저장소에파일 / 폴더등록하기 ) Commit 명령어 : Stage (Index) 에있는 Tracked 상태의파일 / 폴더를로컬저장소에등록, 버전관리 명령어활용 : $ git commit -m Comments" Stage (Index) 에있는 Tracked 상태의파일 / 폴더를로컬저장소에 Commit 하며. -m 은 Commit 메시지를등록하는옵션으로, 여러줄의메시지를쓸경우 -m 을여러개사용가능 $ git commit -a m Comments Tracked 파일중수정중인파일의 Stage (Index) 등록과동시에상태의파일 / 폴더를로컬저장소에 Commit. 단, Untracked 상태의 File 을자동으로 Tracked 상태로변환해주지는않으므로사용에유의 $ git commit -v -m Comments" -m 을사용하지않을때 -v 옵션을사용하면편집기에 Commit 하려는변경사항의다른점을보여주며, 특정파일만 Commit 하려면마지막에파일명을추가하여 Commit 진행
1.3-2. Git 기본명령어사용 3. 등록작업취소하기 1) Add 작업취소하기 : Stage 상태의파일등록을해제하기 (Unstaging) 작업순서 : 1. 현재상황에따라, Unstaging 명령어가다름 : git status를통해현재상태를확인 2. git status 출력메시지중 Changes to be committed:.. 아래표시되는명령을통해 Unstaging (add 작업취소 ) 2) Commit 작업수정하기 (amend): Commit 메시지변경이나수정이미처덜반영되어다시반복등록하고할때 명령어활용 (amend): $ git commit --amend : 전체 Commit 된내용을다시 Commit 반영, 이때변경내용이없다면기존내용으로그대로유지 만약 Commit 에서누락된파일이있을경우아래와같이명령을수행하여해당파일을추가하고재 Commit $ git commit -m 'initial commit' $ git add <forgotten file> $ git commit --amend 3) 수정중인파일 (Modified) 을최종 Commit 시점의원래파일로되돌리기 명령어활용 (Check out): $ git checkout <Hash 또는 Branch 등 > 기존 Commit 된파일중현재추가수정중인파일을 Commit 시점으로되돌리는명령
1.3-2. Git 기본명령어사용 4. Commit 이력조회하기 (Log 조회및 Diff) Log 명령어 : Commit 이력을조회하고, Commit 된이력간의비교를할수있음 명령어활용 (Git log): 기본 Commit log 확인 $ git log 저장소의 Commit 히스토리를시간순으로보여주며, 최신의내용을우선으로표시 $ git log -p -2 최신 Commit 2 개에대해서비교하여표시하는명령으로직접 diff 를실행한것과같은결과를출력 Log 의다양한 Option 에대해서는 1.3-8. Git 추가기능활용 에서설명
1.3-2. Git 기본명령어사용 5. 로컬에서등록한변경내용을원격저장소에저장하기 1) Push 명령어 : 로컬저장소에관리되는버전을원격저장소에전달, 저장하기 작업순서 : 1. Git remote 명령을통해원격 Repository 지정 2. 해당원격 Repository에대해 Push 명령을사용하여로컬저장소의내용보내기 명령어활용 (Git remote): $ git remote -v 원격저장소를확인 $ git remote add [ 저장소명 ] [ 저장소 URL] 원격저장소를추가, 삭제는 rm 인자사용 push 나 pull 실행단계에서원격저장소명을생략하면, 자동으로 origin 이라는이름으로생성 명령어활용 (Git push): $ git push [ 저장소명 ] master [ 저장소명 ] (origin) 원격저장소에 master 브랜치에추가된버전 ( 스냅샷 ) 들을 Upload. Remote repository 만들기 : $ git init --bare [ 저장소명 ].git 로컬저장소가아닌원격저장소를생성하는명령으로 Work directory 가포함되지않는순수 Repository 생성.
1.3-2. Git 기본명령어사용 5. 실습하기 Scenario 1. File을 Workdir에생성 2. 생성된파일을 git의 stage영역으로등록 (add) 3. Stage 영역의파일을로컬저장소에등록 (Commit) 4. 저장된 Commit에대한이력조회 (Log) 5. 원격저장소조회및추가 (Remote) 6. 원격저장소에 Commit 이력 Push하기 (Push)
1.3-3. Git 저장소공유 Chapter Target Step #1 원격저장소의프로젝트를로컬저장소로복제하기 (Clone) Step #2 원격저장소의변경내용을로컬로내려받기 (Pull, fetch) 원격저장소의프로젝트를로컬에복제 ( 내려받기 ) git remote add + git pull 과거의유사 원본 (origin) 확인 / 추적 / 동기화 원격저장소의내용중작업할최신항목을내려받기 원격저장소에있는 commit 을 fetch 하고, 로컬과 merge 원격서버 (remote) 추가 / 확인 / 추적 / 동기화 Local Remote Local Remote Push Push Local Repository Clone Remote Repository Local Repository Pull, Fetch Remote Repository
1.3-3. Git 저장소공유 1. 원격저장소의파일을로컬저장소로내려받기 1) Clone 명령어 : 원격저장소의프로젝트를복제하여로컬에저장소생성 명령어활용 (Git Clone): $ git clone [ 저장소 URL] [ 저장될폴더 ] 원격저장소에있는프로젝트를로컬로내려받기 ( 가장마지막의폴더는지정하지않으면현재위치를기준 ) $ git clone depth [ 숫 ] [ 저장소 URL] 공용프로젝트의경우버전히스토리가많으므로최신 Commit 일부만내려받고자할때사용 Clone 을통해원격의내용을갖고오는경우자동으로원격의원본은 Origin 이라는 Remote 식별자를갖는다. 2) Fetch 명령어 : 로컬에존재하지않는원격저장소의변경내용을확인하여내려받는명령으로, 로컬과병합은하지않음 명령어활용 (Git Fetch): $ git fetch [ 저장소 URL] 원격저장소에있는프로젝트의최신변경내용을로컬로내려받기 ( 병합은하지않음 ) 3) Pull 명령어 : 로컬에존재하지않는원격저장소의변경내용을확인하여내려받은뒤로컬과병합 명령어활용 (Git Pull): $ git pull [ 저장소 URL] 원격저장소에있는프로젝트의최신변경내용을로컬로내려받은뒤로컬의브랜치와자동병합
1.3-3. Git 저장소공유 5. 실습하기 Scenario 1. 생성된작업 dir에서원격저장소의프로젝트를 git clone으로내려받기 (Clone) 2. 내려받은파일중필요한파일을수정하기 3. git add 명령을통해수정한파일을 Stage 등록 (Add) 4. git commit 명령을통해 stage 상태의파일을로컬저장소에등록 (Commit) 5. 로컬저장소에저장된변경이력을원격저장소로보내기전에 git fetch를통해원격의최신변경확인 (Fetch) 6. git push 명령을통해로컬에서작업한이력을원격으로보내기 (Push)
1.3-4. Git Branch Chapter Target Step #1 Branch 의생성 (Branch, Checkout) Step #2 수정하고반영하기 (Commit) Step #3 Branch 를 Master 에통합하기 (Merge) 작업을위해 Branch 생성하기 생성된 Branch 에서작업진행 진행중인작업의수정을반영 Fast forward 방식으로 Master 에최신버전으로 Merge 작업이완료된 Branch 삭제 Master 1 2 3 Branch 2 3
1.3-4. Git Branch 1. Branch 생성 1 Master Branch 진행 Process Commit 1 (twos1..) Commit 2 (tosd2..) Commit 4 (tosd4..) Commit 5 (tosd5..) Commit 4 (tosd4..) Commit 5 (tosd5..) 2 Branch 명령어 : Master 에서작업 Branch 를생성하여 Main 과분리된별도의개별작업 Branch 를생성 명령어활용 (Git Branch): $ git branch [Branch 명 ] Master 에서별개의작업 Branch 생성. 단, Branch 를생성해도작업 Head 는여전히현재 Branch(Master) 에존재. $ git checkout [Branch 명 ] Branch 를작업하기위해 Head 를 Branch 로이동하는명령, 이작업을수행해야 Branch 작업의진행이가능 -b option 을추가시 Branch 의생성과 Checkout 을한번에진행할수있음 Branch 를생성후 Check out 을하지않고파일의변경시현재 Master Branch 에변경이반영됨에유의
1.3-4. Git Branch 1. Branch 병합 1 Merge 명령어 : Branch 와 Master 의병합 명령어활용 (Git Branch): $ git merge [Branch 명 ] 현재 Branch 에서병합할 Branch 명에대해병합시사용 Branch 를병합하는과정중가장기본적인 Fast-Forward 방식의병합은아래와같이진행 $ git checkout [Branch 명 1] -> Merge 작업을진행할 Branch $ git merge [Branch 명 2] -> 현재 Branch 에서 Merge 하고자하는대상 Branch Branch 를로컬저장소에서생성하고진행하는예제로서나머지응용은다음장에서상세설명 Process Master Head Commit 1 (twos1..) Commit 2 (tosd2..) Commit 3 (git3c..) Commit 4 (git3c..) Commit 5 (git3c..) Merge (Fast-forward) Branch1
1.3-4. Git Branch 5. 실습하기 Scenario 1. Branch1 을생성후 Head 를새로운 Branch 로이동 ($ git checkout -b branch1) 2. 새로운 Branch1 에서파일변경후 Commit ($ git commit -a -m 'added file to branch1 ) 3. Branch1 을 Master branch 에 Fast-forward 방식으로 Merge 1. $ git checkout master 2. $ git merge branch1
1.3-5. Git 변경이력통합및충돌해결 3Way Merge 활용시 Conflict, Merge, Rebase 기능활용 Chapter Target Step #1 Step #2 Step #3 Branch 의생성 (Branch, Checkout) Branch 를 Master 에통합시 Conflict 발생확인 (Merge) Branch 를 Master 에통합하기 (Rebase, Merge) 작업을위해 Branch 생성하기 생성된 Branch 에서작업진행 진행중인작업의수정을반영하고자할때충돌상황확인 (Reject, Conflict) 충돌발생시확인 전체 Branch 이력을 Master 에반영하기 (Merge) 최종 Branch 이력을 Master 에반영하기 (Rebase) Master 1 A M Branch 2 3 Conflict / Merge Master 1 A 2 3 Branch 2 3 Conflict / Rebase Merge
1.3-5. Git 변경이력통합및충돌해결 3-Way Merge 1 3-Way merge 진행 Process Commit 1 (twos1..) Commit 2 (tosd2..) Commit 3 (git3c..) Commit 5 (brc5d..) Commit 7 (mas7a..) Commit 4 (brc4c..) Commit 6 (mrgd6..) Scenario 1) Master branch 에서 Branch1을생성하여수정진행 2) 다시 Master branch 에서 Branch2를생성하고변경반영 3) Branch2를 Master Branch와 Merge 후 Branch2 삭제 (Fast-forward) 4) Branch1을 Master Branch와 Merge 시 3-way merge 진행및 Conflict 해결 (Master branch + Branch1 + Branch2)
1.3-5. Git 변경이력통합및충돌해결 상세진행순서 : 1. Branch1 을생성후 Head 를새로운 Branch 로이동 ($ git checkout -b branch1) 2. 새로운 Branch1 에서파일변경후 Commit ($ git commit -a -m 'added file to branch1) 3. 새로운 Branch 를만들기위해다시 Master branch 로 Head 이동하여작업환경전환 ($ git checkout master) 4. Master branch 에서또다른 Branch2 를생성후 Head 를 Branch2 로이동 ($ git checkout -b branch2) 5. 새로운 Branch2 에서파일변경후 Commit ($ git commit -a -m 'added file to branch2 ) 6. Branch2를 Master branch에 Fast-forward 방식으로 Merge 1. $ git checkout master 2. $ git merge branch2 7. Master 에병합한 Branch2 는삭제 ($ git branch d branch2) 8. 다시 Branch1 으로 Head 를이동하여작업환경전환 ($ git checkout branch1) 9. Branch1 에서추가파일변경후 Commit ($ git commit -a -m More added file to branch1 ) 10. Branch1 을 Master branc 에 Merge. 이때, 자동으로원래의 Master, Branch2 의변경,Branch1 의변경 Commit 3개에대한 3-Way merge가진행되며 Fast-forward로는진행되지않으며새로운 Merge commit을 Master에생성 1. $ git checkout master 2. $ git merge branch1 10 번을진행시동일파일에대한변경이중복될경우 Conflict 가발생되며조치는다음장을참조
1.3-5. Git 변경이력통합및충돌해결 3-Way Merge 2 3-Way merge 진행시발생한 Conflict 조치 조치순서 : 1 Merge 진행중 Conflict 발생시에는 Conflict 메시지와함께작업진행이되지않음 $ git merge branch1 Auto-merging index.html CONFLICT (content): Merge conflict in [ 파일명 ] Automatic merge failed; fix conflicts and then commit the result. 2 Merge 가진행이되지않는상황을 Status 명령으로확인 ($ git status) 3 2 번을실행시 Unmerged 로표시되는파일을수동으로조치 ($ git mergetool 또는사용지정도구 ) 4 Merge 도구를사용하지않을경우조치한파일을다시 git add 를통해변경등록 ($ git add [ 파일명 ]) 5 Git status 명령을통해변경상태를확인한후, Commit I. $ git status II. $ git commit -> 단, 이때에는 Commit 에표시되는 System 메시지가약간다름
1.3-5. Git 변경이력통합및충돌해결 3-Way Merge 에서 Commit 합치기 1 3-Way merge 진행시 Branch 의 Commit 통합하기 Commit 1 (twos1..) Commit 2 (tosd2..) Commit 7 (mas6a..) Commit 3 (git3c..) Commit 4 (brc4c..) Commit 6 (mrgd6..) Scenario 1) Master branch 에서 Branch1을생성하여수정진행 2) Master branch 에서 Branch1의 Commit을하나로묶어서하나의 Commit으로병합 (merge --squash option) 3) Branch1 을 Master Branch와 Merge 후 Branch1 삭제
1.3-5. Git 변경이력통합및충돌해결 상세진행순서 : 1. Branch1 을생성후 Head 를새로운 Branch 로이동 ($ git checkout -b branch1) 2. 새로운 Branch1 에서파일변경후 Commit ($ git commit -a -m Changed file to branch1) 3. Branch1 에서추가파일변경후 Commit ($ git commit a m 'Changed file to branch1 ) 4. Branch1을 Master branch에 Merge, 단 Squash option 추가하여 Branch의 Commit을하나로통합 1. $ git checkout master 2. $ git merge --squash branch1 4 번을진행시동일파일에대한변경이중복될경우 Conflict 가발생되며조치는 merge 와동일
1.3-5. Git 변경이력통합및충돌해결 Rebase 3 Rebase (Merge 와비슷하지만 Commit 이력을깔끔하게사용시활용 ) Patch 를이용하여 Rebase 를진행하는 Process Snapshot 1 Snapshot 2 Snapshot 3 Master Head Commit 1 (twos1..) Commit 2 (tosd2..) Commit 3 (git3c..) Commit 5 (brc5c..) Commit 4 (mas6a..) Commit Tree Author Size Tosd0 Js.park Commit Tree Parent Size 76abd twos1 Commit Tree Parent Size 969e8 Tosd2 Commit 4 (brc4d..) Committer Js.park Init message Author Committer Js.park Js.park Author Committer Js.park Js.park Branch1 Commit message Commit message Scenario 1) Master branch 에서 Branch1을생성하여수정진행 2) 다시 Master branch 에서파일을수정하고변경반영 3) Branch1의변경사항을 Patch화하여 Master Branch에반영 (Rebase) 4) 두 Branch가나뉘기전인 Commit3 으로이동후현재까지 Checkout한 Branch가가리키는 Commit까지 diff를 차례로만들어어딘가에임시로저장해놓은다음, Rebase할브랜치 (Branch1) 가통합될대상 (Master branch) 을 가리키는 Commit을향하여임시저장해놓았던변경사항을차례대로적용한후새로운 Commit을생성
1.3-5. Git 변경이력통합및충돌해결 상세진행순서 : 참고사항 : 1. Branch1 을생성후 Head 를새로운 Branch 로이동 ($ git checkout -b branch1) 2. 새로운 Branch1 에서파일변경후 Commit ($ git commit -a -m 'added file to branch1 ) 3. 다시 Master branch 로 Head 이동하여작업환경전환 ($ git checkout master) 4. Master branch 에서파일변경후 Commit ($ git commit -a -m 'added file to master ) 5. Branch1으로작업환경전환후 Master branch 에 Rebase (Branch1의내용을 Patch화하여 Master로반영 ) a. $ git checkout branch1 b. $ git rebase master 1. Rebase 의결과물은 Merge 와거의동일 2. Rebase 는보통 Remote Branch 에 Commit 을깔끔하게적용하고싶을때사용 3. Master branch 의이력은선형으로존재하므로통합작업시편의성제공 4. Rebase 는하나의프로젝트에서 Branch 를생성하고또거기서 Sub-Branch 를생성했을경우, Sub-Branch 를 Master 에바로통합하는경우에도유용하게사용할수있음 5. 모든이력을관리하여야할경우사용을제하여야함 6. 이미공개저장소에 Push 한커밋을 Rebase 하지말것!!
1.3-5. Git 변경이력통합및충돌해결 실습하기 Scenario 1. 동시에두개의 Branch를생성하고작업후 3-Way merge 수행하기 2. Conflict 발생상황을만든후조치하기 3. Squash option을활용하여 Merge하기 4. Rebase를활용하여 Merge와의차이비교해보기
1.3-6. Remote Branch 원격저장소를기반으로 Branch 활용 Chapter Target Step #1 Remote Branch 의생성 (Branch, Checkout) Step #2 Remote 의정보를갱신하여로컬에반영 (Fetch) Step #3 Branch 를 Master 에통합하기 (Rebase, Merge) 작업을위해 Branch 생성하기 생성된 Branch 에서작업진행 원격에서 Update 된내용을로컬에반영하기 (Fetch) 원격 Branch 추적하기 (--track) 전체 Branch 이력을 Master 에반영하기 (Push) 작업후로컬 Branch 삭제하기 Master (Remote) Branch (Local) 1 3 5 2 3 4 4
1.3-6. Remote Branch Remote Branch 생성및병합 Remote Repository Master Commit 1 (twos1..) Commit 2 (tosd2..) Commit 3 (git3c..) Commit 4 (brc4d..) Commit 5 (fab2r..) Commit 6 (mas7a..) Commit 5 (tosd5..) Commit 6 (tosd6..) Fetch Local Repository Origin/Master Push Commit 1 (twos1..) Commit 2 (tosd2..) Commit 3 (git3c..) Commit 4 (brc4d..) Commit 5 (tosd5..) Commit 6 (tosd6..) Rebase Master
1.3-6. Remote Branch Scenario 1. 원격 Repository에서 Clone으로로컬에프로젝트복제 2. 로컬에서수정및 Commit 진행 3. Remote의 Master에 Commit이별도로진행되어로컬과동기화 (Fetch) 4. 로컬에서작업된내용을 Remote에 Push 5. Rebase를통해원격저장소에새로운 Commit 등록하기 명령어활용 : 1. Remote branch의이름은 (remote)/(branch) 형식으로구성 2. $ git remote show origin : 원격의저장소원본정보보기 3. $ git checkout -b <branch> origin/<branch> : branch 생성과동시에 checkout 하고 remote와동기화하기 4. $ git push origin <branch> 또는 git push <remote> <branch> : 로컬 branch 를원격브랜치로 push 하기 5. $ git push origin <branch>:master : 로컬 branch 를 remote의 master branch 에 push 하기 6. $ git branch -D <branch> : 로컬 branch 삭제하기 7. $ git push origin :<branch> 또는 git push <remote> :<branch> : 원격 branch 삭제하기 8. $ git branch --set-upstream-to=origin/<branch> <branch> : 원격 branch 와로컬 branch tracking 정보설정
1.3-6. Remote Branch 상세진행순서 : 실습하기 1. 원격저장소의프로젝트를 Clone하여로컬저장소에생성 - 원격의 Branch를통해새로운로컬 Branch를만들고작업시작시 ($ git checkout -b branch1 origin/ branch1) 2. 로컬저장소의내용변경후 Commit 3. 원격저장소에서변경된내용을로컬에갱신 ($ git fetch origin) 4. 로컬의변경내역을원격저장소에반영 ($ git push origin branch1) - 로컬의 Branch 명을원격저장소에다른이름으로반영을하고자할경우 ($ git push origin branch1 :local1) 5. 원격저장소에변경분반영후로컬의 Branch 삭제하기 ($ git push origin :branch1) 1. 원격의저장소에서 Remote branch 생성하기 2. 로컬에생성된 Remote branch를작업중원격저장소의내용동기화하기 3. 원격저장소에변경내역을 Upload하기 4. Rebase를활용하여원격의저장소 Update하기
1.3-7. Git Tag Chapter Target Step #1 Tag 의용도및추가, 삭제 Step #2 Step #3 Tag 의종류 (Lightweight, Annotated tag) Tag 생성 Tag 삭제 (Reset) Tag 의종류및용도 각 Tag 타입의내용 특정버전에 Tag 를생성 생성된 Tag 정보확인 Tag 정보삭제 Master Branch 1 4 2 3
1.3-7. Git Tag 1 Tag 종류및사용 명령어활용 : Tag는 Annotated Tag 와 Lightweight Tag로구성 I. Annotation Tag: Tag 생성자이름, 이메일과 Tag 를만든날짜, Tag 메시지를저장하며 GPG서명추가가능 II. Lightweight Tag: 단순한특정 Commit에대한식별자로별도의정보를저장하지않음 $ git tag : Tag 정보보기 $ git tag -l [tag 명 ] : 특정태그이름검색하여선택적정보보기 $ git show : Tag 정보와 Commit 정보를모두보고자할경우 $ git tag [tag 명 ] : Lightweight tag 생성 $ git tag -a [tag 명 ] -m [Tag 메시지 ] 또는 git tag -s [tag 명 ] -m [Tag 메시지 ] Annotation Tag 생성 (-s option 의경우개인 GPG Key 를서명하고자할때사용하며 git tag -v [tag 명 ] 으로확인 ) $ git tag -a [tag 명 ] -m [Tag 메시지 ] [ 예전 Commit 의 Checksum] 이전 Commit 내용에대하여 Tag 부여시 (Checksum 은 6 자리이상만사용하면됨 ) $ git push origin [tag 명 ] : Push 할경우 Commit 만반영이되므로 Tag 는별도의 Push 가필요함 $ git tag d [tag 명 ] : Tag 삭제 $ git push origin :[tag 명 ] : 원격저장소의 Tag 삭제
1.3-7. Git Tag 실습하기 Scenario 1. Tag 생성하기 2. Tag 종류별활용 3. Tag 이력조회하기 4. Tag를원격저장소에공유하기 5. Tag 삭제하기
1.3-8. Git 추가기능활용 Stash, Cherry-pick, Commit 내용수정 / 삭제 / 통합등부가기능활용 Chapter Target Step #1 Step #2 Step #3 Step #4 작업의임시저장 (Stash, Cleaning) 작업의이력조회 (git log) 삭제파일만되돌리기 Commit 이력수정 / 삭제 (reset) 작업중의파일을임시저장 저장된임시항목삭제 Commit 이력조회 Log 의상세내용 작업진행중삭제된파일만복구하기 Commit 이력수정 Commit 이력삭제 Step #5 Step #6 Step #7 Bundle Cherry-Pick 특정구문찾기 (Grep) 로컬의작업을하나의파일로묶어내보내기 다른 Branch 의작업내용중특정 Commit 을현재 Branch 로갖고오기 Repository 내의파일특정구문검색
1.3-8. Git 추가기능활용 Stash 를활용한작업의임시저장 명령어활용 : 용도 : 작업도중변경한내용을임시로저장후변경전내용을기반으로다른작업을진행하고자할때활용 $ git stash 작업중인변경내용을임시저장소에기록, ( 임시저장후 Workdir 에서작업중이던내용은초기화됨 ) $ git stash list 임시저장된내용보기 $ git stash apply 임시저장된내용을복구하고자하는경우 ( 특정 Stash 를복구하고자할경우이름을추가 ) $ git stash apply --index 임시저장된내용의복구시 Stage 상태였던파일의상태를 Stage 상태인채로복구하고자할때 $ git stash drop stash 를삭제 $ git stash show -p stash@{0} git apply R Stash 적용후다시원복시키고자할때 $ git stash branch Stash 적용후많은변경을진행했을때다시 Stash 적용시새로운 Branch 를만들어서 Stash 저장당시의 Checkout 된내용과임시저장내용을 Merge 하고성공시 Stash 파일을삭제
1.3-8. Git 추가기능활용 2. 작업의상세이력조회 Log 명령의 Option 을통한상세이력조회 명령어활용 : 용도 : log를활용하여상세이력조회및 Commit 이력비교 $ git log -U1 --word-diff : 단어단위로 Commit 내역의비교 $ git log stat : Commit history의수정파일통계정보 $ git log --name-status : 수정된파일의목록및추가 / 수정 / 삭제여부확인 $ git log apply --since=2.weeks : 현재부터 2 주전까지한정된정보확인 $ git log all : 현재 Branch 이외의다른 Branch의 Commit 이력을포함한전체이력보기 3. 삭제된파일만되돌리기 작업진행중변경내용중에서삭제된파일만되돌리기 명령어활용 : 용도 : Workdir 에서작업진행중인내용중삭제된내용을되살리기 $ git ls-files -d xargs git checkout -- 현재작업 dir 에서삭제된내용만다시원복
1.3-8. Git 추가기능활용 Commit 된내용의수정및통합 명령어활용 : $ git commit --amend 최종 Commit 의내용을현재 Stage 내용으로저장및 Commit 메시지변경 $ git rebase -i HEAD~3 최근 Commit 으로부터 3 번째까지의 Commit 내용을병합 / 수정 ( 대화형으로진행 ) 수정진행시대화형창에서아래내용과같이변경을진행 병합 : pick 으로표기된내용중합쳐질내용을 pick 에서 squash 로변환하고대상은 pick 으로저장 순서 : 항목의순서를재배치 수정 : pick 이라는단어를 edit 으로변경 $ git filter-branch --tree-filter 'rm -f < 파일명 >' HEAD 프로젝트전체에서 Commit 된특정파일을삭제, --all 옵션추가시모든 branch 에명령이적용 Commit 이력의삭제 (Local) 명령어활용 : $ git reset --hard HEAD^ 가장최신의 Commit 을삭제 HEAD^ 는가장최신의 Commit 을의미하며, 최신으로부터 2 개이상의 Commit 을지우고자하는경우 HEAD~2 와같이 ~( 숫자 ) 로표시
1.3-8. Git 추가기능활용 Commit 된내용을통합하여하나의 Commit 만들기 명령어활용 : Commit 을지운뒤하나의 Commit 으로통합하기 (reset --hard 활용 ) 1 가장최종 Commit 의 Workdir 을다른 Dir 에복사 (.git 폴더제외 ) 2 $ git reset --hard HEAD~( 지우려는 Commit 숫자 ) 명령을실행하여 Commit 삭제 예 ) 4 개의 Commit 을지우려는경우 $ git reset --hard HEAD~4 3 다른위치에복사한작업 File 을다시갖고와 Work dir 에덮어쓴다음 git add 후 Commit Commit 을지운뒤하나의 Commit 으로통합하기 (reset soft 활용 ) 1 $ git reset soft HEAD~( 지우려는 Commit 숫자 ) 명령을실행하여 Commit 삭제 예 ) 4 개의 Commit 을지우려는경우 $ git reset soft HEAD~4 2 1 번을통해 Commit 을삭제한다음 Commit Soft option 을사용할경우, Commit 은삭제하지만그간의변경내용은 Staging 에보관
5. Bundle 1.3-8. Git 추가기능활용 로컬작업이력을파일로묶어서내보내기 6. Cherry-pick $ git bundle create [ 내보낼파일명 ] HEAD master 현재저장소의 master 를모두 Export 추가인자값지정을통해저장소의범위지정및특정커밋위주의 Export 가가능하며 Clone 으로다시 Import (ex. $ git clone [Import 할파일명 ] [ 대상 dir]) 1 Branch 의특정 Commit 을선택하여현재의 Branch 로갖고오기 Commit 1 (twos1..) Commit 2 (tosd2..) Commit 4 (tosd41..) Commit 3 (tosd3..) Commit 4 (tosd4..) Commit 5 (tosd5..) 상세진행순서 : 1 Branch1 을생성후지속적인변경 / 등록수행 2 Branch1의특정 Commit을 Master에반영 I. $ git checkout master II. $ git cherry-pick tosd4 -> Cherry-pick 을진행할대상 Commit의키값 III. $ git add [ 파일명 ] -> 위의 Cherry-pick 수행시충돌발생하는경우에수정후등록 IV. $ git commit
1.3-8. Git 추가기능활용 특정구문검색을통해특정파일또는 Commit history 찾기 명령어활용 : $ git grep l [ 검색어 ] 검색어가포함된파일리스트를조회, 검색어에정규식의사용이가능. Git grep 에대한설명은 https://git-scm.com/docs/git-grep 참조 $ git log--grep [ 검색조건 ] Commit 메시지에해당검색조건이있는 Commit 을조회 1. Stash를활용하여작업의임시저장및복원하기 2. Log 명령을활용하여이력조회및 Commit 비교하기 3. Working dir에서작업중인파일삭제후복원하기 4. Commit 이력수정하고, Commit을병합하기 5. Bundle을통해 Export하고 Clone으로 Import 6. Cherry-pick을통해특정 Commit을특정 Branch에갖고오기 7. 특정파일검색하기
1.3-9. repo 를이용한 Multi project 관리 Repo 를활용한멀티 Project 관리기능 Chapter Target Step #1 Git project 생성 Step #2 manifest git 생성 Step #3 Repo 사용 각각의개별프로젝트생성 생성된 Git 프로젝트를기반으로 Manifest.xml 생성 여러프로젝트를묶어하나의프로젝트로관리 Repo 명령어활용 Repo 를이용한여러프로젝트동시활용 Git Project A Repo command Git Project B Git Project C manifest.xml 개발
1.3-9. repo 를이용한 Multi project 관리 1. 여러 Git project 의통합관리 Repo 를통한 Multi git project 관리 [ 개요 ] Repo: Repository 관리 Tool 로여러 Git Repository 를묶어서관리할수있는 Python 기반 Tool 용도 : 여러 Git project 를묶어서하나의묶음으로관리하며내려받기등작업을한번에진행 Repo 설치하기 (Ubuntu OS 기준 ): 1 $ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo 2 $ chmod a+x ~/bin/repo 3 $ vi ~/.bashrc -> 추가 : PATH=$PATH:~/bin/ 4 $ source ~/.bashrc [ 설정 ] 1 Git project 설정 : 생성된 git proejct 를 --bare 형태로복사하고공개 git 으로설정 git clone --bare <my_project> <my_project>.git 1 manifest.xml 에 Project 정보추가 : 기본적으로관리자에의해배포되며, default.xml 또는 manifest.xml 등의이름으로관리되고, 사용자는해당파일내에추가관리할 Project 를등록할수있다. 관리하는프로젝트를추가시 <manifest> TAG 내에아래의내용을해당 XML 파일에추가 I. <default revision="master 또는 [Branch 명 ]" remote="origin" /> II. <project path= [ 로컬에저장되는경로 ]" name= [ 저장소명 ]" /> Gerrit 의 url 정보도 Manifest 에저장
1.3-9. repo 를이용한 Multi project 관리 2. Repo 명령활용 Repo 명령어활용 명령어활용 : ( 기본적으로 git 명령과거의유사 ) $ repo init u [ 원격 URL] 소스를갖고올원격 URL 의선언및현재 DIR 사용초기화, 특정 Branch 를갖고오기위해서 b option 추가가능하며 m option 을사용시특정 manifest file 을지정가능 $ repo sync init 을통해선언된원격저장소에서소스를내려받기, -j optio 을사용하여 Multi thread 작업이가능최초사용시 git clone 과동일하며, 그이후부터는 remote update 및 rebase origin/branch 를실행하는것과동일 $ repo start [banch 명 ] 지정 Branch 에서작업시작 $ repo upload [project 명또는리스트 ] 로컬의변경내용을원격저장소로 update, Review 도구에업로드여부에대해대화창을띄움 $ repo forall -c git reset --hard [ 특정 Tag 명 ] 특정 Tag 배포시해당 Tag 를내려받아반영할때 $ repo status [project 명또는리스트 ] staging area 의변경사항과최종 Commit 의변경사항을비교표시
1.3-8. Git 추가기능활용 실습하기 Scenario 1. Repo 설치하기 2. Repo를통해원격저장소의프로젝트내려받기 3. Manifest file에자신의 git 프로젝트추가하기 4. 작업후변경분 Commit 하기 5. 변경상태확인후원격저장소에변경분반영하기
1.4 git Training 실습 2017 spring TwoSeed presents
Training Scripts A (Basics)
Training Scripts B (git cmds) Staging, Commit, Push Clone, Pull, Fetch
Training Scripts C (Branch) Branch 만들고, 이동하고 병합 ( 충돌없는경우 )
Training Scripts D (Conflict / Branch) Conflict 내기위한준비 Conflict 를해소하고 Merge 수행
Merge Vs. Rebase (1) 진행방안 Master 에서 Branch 3 개를각각생성 (chg1~3) 한다음 Master 에서파일을변경하고, chg1 부터 3 까지각각의 Branch 에고유파일생성및등록을통해변경진행 단, 파일변경시 Branch 명과동일또는유사하게생성하고 Commit 메시지를 " 변경순서, 현재브랜치명 " 으로입력하여 Rebase 및 Merge 의차이점을확인할수있도록 Rebase 또는 Merge 를진행전해당폴더체를복제하여 Merge 먼저, 그다음 Rebase 를진행한후, 각각의폴더에서 Git log 및 Gitk 명령을통해 GUI 상태에서변경내역을확인 이내용은로컬에서만진행하여그변화를보다쉽게확인할수있도록진행 여기까지작업후해당작업폴더를복제하여 2 개의폴더로분리하고각폴더의이름을 Rebase, Merge 로분리
Merge Vs. Rebase (2)
2.1 Gerrit? 이론 2017 spring TwoSeed presents
Gerrit? 지금까짓다소생소할수도있는 git 에적응하시느라고생많으셨습니다. D-VCS 도생소한데, 이제코드리뷰란것까지살펴보겠습니다.
Code Review? 흠... 여러분이어떤표정일까요? Gerrit 의아이콘 DIFFY 쿵후리뷰뻐꾸기가보여주는장난기처럼코드리뷰도장난기있게하는게중요합니다.
Gerrit by Wikipedia 1. 게릿 (Gerrit) 은무료웹팀코드협업도구이다. 소프트웨어개발자가팀에서웹브라우저를사용해소스코드의다른사람의수정사항을검토하거나변경사항을승인또는거부할수있다. 분산버전관리시스템인 Git 과밀접하게통합된다. 2. 게릿은또다른코드리뷰툴인 Rietveld 의포크이다. " 게릿 " 은 Rietveld 라는명칭의유래가된네덜란드개발자 Gerrit Rietveld( 게릿, 리트벨드 1888-1964) 의이름이다. [1] 3. 포크 (fork) 또는소프트웨어개발포크 (project fork) : 개발자들이하나의소프트웨어소스코드를통째로복사하여독립적인새로운소프트웨어를개발하는것을말한다.) 4. 소프트웨어리뷰툴인 Rietveld 용패치묶음에서시작하여포크되었고 ACL 패치가 Rietveld 로합쳐지지않으면서저자인귀도반로섬 (Guido van Rossum) 에의해별도의프로젝트로진화했다. [3] 5. 게릿은안드로이드프로젝트의개발을위해션피어스 (Shawn Pearce, JGit 의설립자 ) 에의해구글에서개발되었다. [2]
Gerrit History
Code Review is Wikipedia : It is intended to find and fix MISTACKES overlooked Guido Van Rossum says : " Goal is COOPERATION, not fault-finding " Cooperation
Git Standalone Vs. Git & Gerrit Git Standalone Gerrit 이 git 과같이구성되면구조는아래와같이달라집니다. Working Space Commit Local Repository Push Fetch/Pull Remote Repository Working Space Git & Gerrit Commit Local Repository Fetch/Pull Remote Repository Sync Gerrit Review System Push for Review
Gerrit : Overview 리뷰중인코드 / 리뷰할코드 / 리뷰완료된코드목록 웹기반의리뷰 UI / 팀의작업방식선택가능 / 자동화하기쉬움, 커뮤니티 / 문서화
Gerrit : diff.view 리뷰할코드의 diff 를보면서의견제시 리뷰할떄는문제점을찾는다기보다, 같이코딩한다는마음으로 Pair Coding!!!
Gerrit : review-vote Repository 에넣을지 (+2) / 다른사람의의견을더들을지 (+1,0) / 추가작업할지 (-1,-2)
2.2 Gerrit 의구조이론 2017 spring TwoSeed presents
Gerrit 은소스 Merge 과정에 Code Review 포함 SVN 기반 SVN 은병합후코드리뷰를별도로수행 Gerrit 은소스 Merge(Push) 과정에 code review 를자연스럽게포함 Gerrit 기반 git 프로세스와통합 Jenkins 연동을통해품질측정결과를 Review 시에활용가능 IDE 도구와연동 출처 : Naver D2
접근제어가없는기존 Git Repository 구조 개별작업이가능한분산버전관리시스템 공동개발과정에서일관성을위해중앙저장소 (Authoritative Repository) 를둠 개발자는각각개별로컬 Git 저장소 (Developer1, Developer2) 사용 CI 빌드서버역시로컬저장소사용 이과정에접근제어를하지않기때문에누구나소스를받거나저장할수있음
접근제어와 Review 과정을추가한 Gerrit Repository 중앙저장소를기능별로분리하여접근제어관리 Review 를위한임시저장소 (Pending Changes) 최종소스가저장되는중앙저장소 (Authoritative Repository) 개발자는최신소스를가져올때 (Read) 만중앙저장소사용 변경사항저장은임시저장소에 리뷰어는임시저장소에서변경사항조회하여 Review 수행
Gerrit 기반 Code Review 워크플로우예시 git clone git branch Git/Repo 환경셋업및소스싱크 재작업요청 개발용로컬브랜치생성 소스코드수정및변경 Commit git commit 개발시작 (Gerrit 프로젝트생성 ) 개발자로컬저장소로소스싱크 개발용브랜치생성 생성한변경에대한 Reivew 요청 git push to refs/for/<branch> 코드작성후리뷰요청 ( 리뷰브랜치로 Push) 리뷰레이블 Verify -1 N 리뷰도구 Gerrit UI 리뷰레이블 Review -2~-1 N 빌드및테스트진행 빌드 / 테스트통과? 코드리뷰 리뷰통과? CI 도구 Jekins, QuickBuild Y Y 리뷰레이블 Verify +1 변경제출및병합 CI 도구로자동코드검증 리뷰어 Code Review 변경사항적용, 중앙저장소 (Authoritative Repository) 에 Merge 및 Conflict Resolution
Git 에서커밋 ID 관리 Git 에서내부적으로특정커밋을가리키는커밋 ID 는 SHA-a Hashing 값 사람이보거나이해하기에불편
특정커밋에대한알기쉬운포인터 Reference SHA-1 Hashing 으로된커밋 ID 에의미있는이름을부여한것 각브랜치, 태그등의 Referencer 가.git/refs 디렉토리에파일로저장 기본으로사용되는 master 브랜치는 /refs/heads/master 파일에저장 참고로 Gerrit 에서 Review 를받으려면 /refs/for/ 브랜치 로 Push
Gerrit 에서는 Review 를위해 Change-Id 를사용 각 Review 를구분하기위한식별자 커밋메시지의마지막에추가해야함 커밋을수정하거나 cherry-pick, rebase 한경우에도변경을방지하기위함 일반적으로 Prefix 로 I 를붙임 출처 :https://git-scm.com/book/ko/v1/git%ec%9d%98-%eb%82%b4%eb%b6%80-git- %EB%A0%88%ED%8D%BC%EB%9F%B0%EC%8A%A4
Commit Hook 을이용한 Change-Id 동생성 커밋메시지작성시, 매번 Change-Id 를생성하기는매우불편 Git 의 Commit Hook 스크립트를이용하여자동생성기능지원 출처 :https://git-scm.com/book/ko/v1/git%ec%9d%98-%eb%82%b4%eb%b6%80-git- %EB%A0%88%ED%8D%BC%EB%9F%B0%EC%8A%A4
Git 에서 Commit Hook 의활용 특정 Hook 이벤트 (Git 명령 ) 가실행될때자동으로실행되는스크립트.git/hooks 에저장되는실행가능한모든스크립트 ( 예 : Shell, Perl, Python) 샘플스크립트들이기본적으로들어있으며.sample 확장자만제거하면동작 로컬저장소에서동작하는 Client Hook 과서버중앙저장소에서동작하는 Server Hook 이있음 ( 자세한내용은 Git 매뉴얼참고 )
Git 브랜치합치기 공통조상인 C2 를기준으로두개의브랜치 experiment(c3), master(c4) Git 에서브랜치를합하는방법은두가지 : Merge, Rebase
Git Merge 를이용한브랜치합치기 Git Merge 를이용한일반적인브랜치합치기 다음 git merge 명령을통해 C3, C4 의변경내용을합하여 master(c5) 브랜치생성 > git checkout master > git merge experiment
Git Rebase 를이용한브랜치합치기 > git checkout experiment > git rebase master > git checkout master > git merge experiment 다른브랜치의내용을 Merge 하지않고 Patch 만들어추가하는방법 히스토리가트리구조가아닌선형. 단, 최종소스는 Merge 와동일 서버에 Push( 다른사람과공유 ) 한소스에 Rebase 하면안됨
Review 요청및처리과정 (1) Fetch 중앙저장소 (5) Fetch and Review 리뷰어 (2) 개발작업 (6) Submit 개발자 (3) Push for Review Pending Changes (4) Fetch and Verification Build 개발자는중앙저장소에서가져온소스를기준으로개발작업 변경된소스에대한 Review 요청을위해임시저장소로 Push Push 과정에 Verify, Review 요청을선택 Quick Build
Verify 와 Review (1) Fetch 중앙저장소 (5) Fetch and Review 리뷰어 (2) 개발작업 (6) Submit 개발자 (3) Push for Review Pending Changes (4) Fetch and Verification Build Quick Build Verify 과정에코드가컴파일, 실행등이정상적으로되는지검사 Verify 는주로 CI(Jenkins 등 ) 에의해자동으로수행됨 Review 는리뷰어에의해코드가프로젝트의가이드라인에따라작성되었는지검사
Verify 와 Review 수동 Verify 화면 Review 화면 일반적으로자동으로처리 수동 Verify 가능 +1 이면통과 리뷰어가하는일반적인 Review 일반적으로결과가 +2 이면통과 결과가 -2 이면 Merge 하면안됨
CI(Jenkins, Quck Build) 를통한 Verify 과정 Jenkins 는 Git Client Plugin, Git Plugin, Gerrit Trigger Plugin 을사용 Gerrit 에리뷰가제출되면빌드트리거가동작하여 Git 저장소로부터소스를가져와빌드 / 테스트후결과를제출 QuickBuild 는 Gerrit 이제공하는 REST API 를통해리뷰제출을감지하여빌드를트리거하며, 빌드 / 테스트결과를제출 빌드에성공하면 Verified/+1 을부여
CI(Jenkins, Quck Build) 를통한 Verify 과정 Jenkins Verify 결과 Jenkins Verify 결과제출 Verify 결과에 CI 도구가사용한 Gerrit 계정표시 QuickBuild Verify 결과
Gerrit 권한구조의이해 All Projects 권한만있는프로젝트 오픈소스 비공개 Gerrit JGit Project X Project Y 상속을이용한권한구조 자식프로젝트나하위그룹은부모의설정을상속 그룹에기반한권한 개별사용자는역할을가진그룹을통해권한부여 자원 주로 Git Reference 인권한제어의대상 제어 - Push, Merge 등저장소에대한접근권한과코드리뷰권한을포함
기본권한을설정하는 All-Projects Gerrit 이초기화될때자동으로생성 실제프로젝트가아닌 Gerrit 내모든프로젝트들의권한에대한기본설정 Global Capabilities Gerrit 시스템에대한관리기능 ( 예 : 사용자생성 ) 으로여기서만설정가능 All-Projects 권한 Reference Git Reference 단위의권한제어로하위프로젝트에서오버라이드가능
Project 별상세권한설정 상속받은상위프로젝트의권한을기본적으로사용 프로젝트별로권한을오버라이드가능 개별 Project 권한 왼쪽의예에서 reviewtest 프로젝트는기본적으로 All- Projects 의권한을상속하지만, 특별히 reviewtest 그룹 ( 프로젝트가아님에주의 ) 에게목표브랜치를생성하거나리뷰 (-2 ~ 2 사이점수 ) 를하고승인결과를제출할수있는권한부여
Git 저장소관련권한 Git 저장소에대한권한 Read Push(+Force) 브랜치복제권한 존재하는브랜치에대한 Fast-Forward ( 또는강제 ) 푸쉬권한 Create Reference Create Signed Tag Create Annotated Tag Forge Author Identity Forge Committer Identity Owner 새로운브랜치를생성할수있는권한태그를생성할수있는권한변경의저자및커미터저자정보를수정할수있는권한 refs/* 에적용하면프로젝트에대한전체관리권한부여 Project 권한설정에서위의 Git 저장소관련권한을어떤그룹에게부여할지지정가능
코드리뷰권한 코드리뷰관련권한정의 Push refs/for/refs/* 리뷰요청권한 Push Merge Commit refs/for/refs/* Merge Commit 에대한리뷰요청권한 코드리뷰관련권한예 코드리뷰를위해서는개발자가리뷰어가해당 Project 의관련 Reference 에적절한권한이있어야함 위의예에서 Gerrit 사용자는누구나 Review 를요청할권한이있음
코드리뷰권한 코드리뷰관련특수한권한 Label-<LabelType>- X..+Y Submit refs/heads/* refs/heads/* 진행중인리뷰에대해리뷰를올리고 X 에서 +Y 사이의점수를부여할권한 LabelType 에는 Review 와 Verify 가있음 리뷰결과로변경 (Change) 에대한중앙저장소브랜치병합 (Merge) 요청권한병합요청은바로처리되어병합이이루어짐 Abandon refs/heads/* 리뷰결과로변경에대한폐기권한 Rebase refs/heads/* 리뷰중인변경을목표브랜치로리베이스 (Rebase) 할수있는권한 Project 권한설정에서위의특수한리뷰관련권한을어떤그룹에게부여할지지정가능
사용 와그룹 모든 Gerrit 사용자는그룹에속해야해당권한을부여받을수있음 그룹은프로젝트의권한설정에서역할을부여받음 그룹은다른그룹을포함할수있음 LDAP 과같은외부시스템의그룹정보를가져와재정의해서사용가능 사용자별권한제어를위해서는특수한플러그인 (singleusergroup) 을통해서가능
기본그룹과역할 Administrators - Gerrit 관리자 (Gerrit 설치후최초생성된계정 ) Anonymouse Users 익명으로접근가능한사용자 ( 여기에권한을부여했다는의미는공개프로젝트임을의미 ) Project Owners 프로젝트의소유자로브랜치생성등프로젝트에대한전반적관리권한가짐
2.3 Gerrit 의사용실습 2017 spring TwoSeed presents
Gerrit 코드리뷰의작업흐름 시작 Change-ID 1. 변경 ID 생성 refs/for/<branch> 2. 리뷰를위한 Push 개발자리뷰어 시스템 4. 리뷰어추가및요청 3. 빌드, 테스트, 검토 (Verify) 커미터역할 5. 코드리뷰및검토 (Review) 6. 평가점수판별 7. 변경사항리베이스 (rebase), 재작업 (rework), 수정 (amend) 종료 8. 변경 ID 폐기 9. 변경 ID 제출 10. 변경 ID 병합 종료
Gerrit 프로젝트시작 사용 생성 Apache HTTPD 에계정생성및로그인 Gerrit 사용자정보입력 최초생성된사용자는자동으로관리자그룹에등록됨 > sudo htpasswd -c /etc/apache2/passwords admin (passwords 파일새로생성시에는 -c 옵션사용 ) > sudo htpasswd /etc/apache2/passwords dev01 > sudo htpasswd /etc/apache2/passwords rev01 전체이름입력 ssh 인증에필요한 PKI 공용키등록 (git ssh 인증과동일 ) 이메일등록 ( 사용자지정에사용되므로필수 )
Gerrit 프로젝트시작 그룹지정 Gerrit 그룹생성 그룹에사용자추가 개발자와리뷰어모두추가 reviewtest 그룹이름입력 dev01 추가할사용자입력
Gerrit 프로젝트시작 프로젝트생성 Gerrit 프로젝트생성 Only serve as parent for other projects: 권한만있는프로젝트 Submit Type: 변경을저장소에병합하는방법 저장소 clone 명령 projtest 프로젝트이름입력 상속할프로젝트
Gerrit 프로젝트시작 프로젝트구성 프로젝트소스및브랜치조회 프로젝트권한설정 브랜치생성권한부여 : refs/heads/* 에대한 Create Reference 권한을그룹에부여 소스조회 (gitweb) 브랜치생성권한 reviewtest
Gerrit 프로젝트시작 저장소 clone 프로젝트저장소 clone 프로젝트정보에있는 git clone 명령사용 (git config 로개발자 ID 지정 ) Change-Id 자동생성을위한커밋훅스크립트도같이복사 저장소 clone 명령 with commit-msg hook ssl > git clone ssh://dev01@yourdomain.net:29418/projtest && scp -p -P 29418 dev01@yourdomain.net:hooks/commit-msg projtest/.git/hooks/ (git 저장소 clone 및 commit-msg 커밋훅스크립트복사 ) > git log commit c01cfb0e3f8c59bb65a8366fb953f881cc1a184c Author: 정명훈 <javalove93@gmail.com> Date: Fri May 1 13:15:59 2017 +0900 Initial empty repository
1. 변경 ID 생성 ( 개발 ) 브랜치생성 로컬에서만브랜치작업하여병합하는방법 서버에브랜치생성하는방법 ( 프로젝트에대한브랜치생성권한필요 ) 소스변경작업 > git checkout b mybranch ( 로컬브랜치생성 ) Switched to a new branch 'mybranch > ssh -p 29418 dev01@yourdomain.net gerrit create-branch projtest mybranch master (master 브랜치를기반으로 mybranch 라는브랜치서버에생성 ) > vi branch.txt This is a file in new branch > git add branch.txt > git commit -a (Change-Id는 commit-msg 스크립트에의해자동부여됨 ) [mybranch b9d536f] mybranch file 1 file changed, 1 insertion(+) create mode 100644 branch.txt
1. 변경 ID 생성 ( 개발 ) 로컬브랜치병합 로컬에서만브랜치작업하여병합하는방법 로컬에만브랜치흔적이남음 > git checkout master Switched to branch 'master > git merge mybranch Updating 2dc8723..b9d536f Fast-forward branch.txt 1 + 1 file changed, 1 insertion(+) create mode 100644 branch.txt
2. 리뷰를위한 Push ( 개발 ) 리뷰전용브랜치로 Push 프로젝트정보에있는 git clone 명령사용 (git config 로개발자 ID 지정 ) Change-Id 자동생성을위한커밋훅스크립트도같이복사 > git push origin HEAD:refs/for/mybranch ( 서버브랜치를사용하지않는경우에는 refs/for/master) Counting objects: 4, done. Delta compression using up to 2 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 342 bytes 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) remote: Processing changes: new: 1, refs: 1, done remote: remote: New Changes: remote: http://yourdomain.net/7 remote: To ssh://yourdomain.net:29418/projtest * [new branch] HEAD -> refs/for/mybranch
2. 리뷰를위한 Push ( 개발 ) Push 과정에리뷰자지정 Push 과정에토픽지정 관련된변경들을묶어서하나의리뷰로지정 > git push origin HEAD:refs/for/mybranch%r=rev01@yourmail.net (rev01 리뷰어로초대 ) > git push origin HEAD:refs/for/mybranch%topic=mytopic (mytopic 토픽지정 ) > git push origin HEAD:refs/for/mybranch%topic=mytopic,r=rev01@yourmail.net ( 토픽과리뷰어동시지정 ) 초대된리뷰어 토픽 (mytopic) 으로묶인리뷰
3. 빌드, 테스트, 검토 ( 시스템 ) CI 도구 (Jenkins, Quick Build) 를이용하여자동빌드 / 테스트및결과를 Gerrit으로제출 Jenkins 설정 Gerrit 계정생성및 SSH Key 등록 계정을 Non-Interactive Users 그룹에등록하고 Project 권한부여 Project 에대한 Verify 관련권한부여 Gerrit 에 Jenkins 용계정생성 Gerrit 의 Jenkins 계정에 Jenkins 시스템의 SSH Key 등록
3. 빌드, 테스트, 검토 ( 시스템 ) Jenkins 설정 Gerrit Git 저장소설정 빌드를위한소스 Fetch Gerrit 트리거설정 리뷰제출시자동으로빌드 / 테스트동작 Git 소스주소 트리거에사용할 Gerrit 서버 빌드할브랜치 트리거대상프로젝트및브랜치
4. 리뷰어추가및요청 ( 시스템 ) 웹 UI 에서생성된리뷰조회 리뷰어추가 ( 초대 ) 커밋메시지및변경 ID 리뷰어및추가 필요한리뷰활동 리뷰대상소스
5. 코드리뷰및검토 ( 리뷰어 ) 웹 UI 에서변경된코드에대한리뷰및검토활동 기존소스와변경된소스를비교할수있는리뷰도구를활용한코드리뷰 소스중간에인라인의견 ( 커맨트 ) 추가 코드리뷰 소스중간에리뷰커맨트 Side-by-Sde 코드리뷰도구
5. 코드리뷰및검토 ( 리뷰어 ) 웹 UI 에서소스인라인편집 리뷰도중 UI 내에서바로코드를편집하여새로운패치셋생성 소스편집모드 인라인소스편집 편집내용반영
5. 코드리뷰및검토 ( 리뷰어 ) 리뷰피드백제출 부여된리뷰권한 ( 프로젝트권한에서설정 ) 에따른피드백제공 개발자 ( 리뷰요청 ) 에게전체적인의견제공가능 프로젝트권한설정 리뷰피드백 전체적인의견 리뷰, 검토권한 관리자 -2 ~ 2 점부여가능 일반사용자 -1 ~ 1 점부여가능 리뷰와검토점수 변경제출 / 병합권한 변경폐기권한 코드리뷰 (-1 ~ +1) 만가능한경우
5. 코드리뷰및검토 ( 리뷰어 ) 리뷰예절및프랙티스 리뷰및토론내용공유 : 모든의견은 Gerrit 을통해변경내용과같이관리및공유함 모든파일을리뷰 : 다른사람의코드를완전히이해하기위해변경된모든파일을리뷰 코드에대한의견 : 리뷰는다른사람의수준을평가하는것이아닌코드개선목적을위해코드에대한의견만을제공하는것임 모든의견에대답 : 모든의견과질문에대해반영여부와함께답변을제공 소스코드로의견제시 : 가능하면변경에대한대안이될수있는구체적인코드를제시 한번에한가지씩변경 : 리뷰의근본적인목적은변경을반영하는것으로, 리뷰에너무많은시간이들어가지않도록리뷰요청하는변경단위를최소화 토픽사용 : 큰변경은작게나누어서토픽으로구분
5. 코드리뷰및검토 ( 리뷰어 ) 코드리뷰용어 NIT(picking): 작은변경을필요로하는사소한문제 Optional: 리뷰자의개인취향으로원저자가무시할수있음 RFC(Request For Comments): 반드시병합될필요없이아이디어를공유하기위한리뷰 WIP(Work In Progress): 초안성격의변경으로리뷰를통해사전피드백을수집하기위함
6. 평가점수판별 ( 시스템 ) 시스템을통한평가점수판별 저장소에커미터권한을가진담당자가 +2점을부여할경우리뷰는통과된것으로봄 커미터권한을가진담당자가 -2점을부여할경우에리뷰는거부된것으로봄 대체로 +1점두개가모인다해서 +2점으로간주하지는않음 검토실패시 -1점을부여하고저장소에병합되어서는안됨 조직내부에서규칙을정해야함 리뷰제출버튼활성화 리뷰와검토점수통과요건 ( 각 +2, +1) 만족 검토는통과했으나리뷰통과실패
7. 변경사항리베이스, 재작업, 수정 ( 개발 ) 부정적인점수를받은리뷰에대한재작업 git-review 를이용한리뷰중인소스다운로드 리뷰중인변경 (change) 과패치셋기준으로다운로드하여로컬에브랜치생성 > sudo apt-get install git-review > vi.gitreview ( 프로젝트작업위치에생성 ) [gerrit] host=yourdomain.net port=29418 project=projtest.git defaultbranch=master 변경 (Change) 번호 > git review l ( 진행중인리뷰목록조회 ) 10 master mytopic 2 Found 1 items for review > git review d 10 (Change 10 번소스다운로드하여로컬에브랜치생성 ) Downloading refs/changes/10/10/1 from gerrit Switched to branch "review/_1/mytopic"
7. 변경사항리베이스, 재작업, 수정 ( 개발 ) git 을 fetch 를이용한리뷰중인소스다운로드 리뷰중인변경 (change) 과패치셋기준으로다운로드하여로컬에브랜치생성 리뷰중인소스다운명령 > git fetch ssh://dev01@yourdomain.net:29418/projtest refs/changes/12/12/1 && git checkout FETCH_HEAD From ssh://yourdomain.net:29418/projtest * branch refs/changes/12/12/1 -> FETCH_HEAD Note: checking out 'FETCH_HEAD'. > git branch * (detached from FETCH_HEAD) master
7. 변경사항리베이스, 재작업, 수정 ( 개발 ) 리뷰에따라소스수정 동일한 Change-Id 로커밋 다시리뷰제출 (git push 또는 git review 명령사용 ) > vi branch.txt ( 소스수정작업 ) > git add branch.txt 변경된소스리뷰요청 > git commit --amend ( 동일 Change-Id 유지하면서커밋 ) [review/_1/mytopic 48815e8] mytopic 2 revised 1 file changed, 1 insertion(+), 1 deletion(-) (-m option을사용시 Change ID가변경되므로유의 ) > git push origin HEAD:refs/for/master ( 리뷰제출 ) > git review f (git review 이용한리뷰제출및브랜치삭제 ) remote: Processing changes: updated: 1, refs: 1, done * [new branch] HEAD -> refs/publish/master/mytopic Switched to branch 'master' Deleted branch 'review/_1/mytopic' 새로운제출된패치셋
8. 변경 ID 폐기 ( 커미터 ) 변경에대한재작업을했음에도리뷰평가점수가기준에미달할경우변경내용을폐기 폐기된내용은목록 (Abandoned) 에남아있으므로다시복구가능 개발자는로컬저장소의커밋내용을취소 변경내용폐기 폐기된내용복구 > git status # On branch master # Your branch is ahead of 'origin/master' by 1 commit. # (use "git push" to publish your local commits) > git reset --hard HEAD^
9. 변경 ID 제출 ( 커미터 ) 변경내용에평가점수가기준이상일경우변경내용을제출 프로젝트의변경제출옵션에따라중앙저장소에병합됨 Fast Forward Only Merge If Necessary Rebase If Necessary Always Merge Cherry Pick 변경제출옵션 변경내용제출
10. 변경 ID 병합 ( 커미터 ) Fast Forward Only 방식의병합 해당커밋이최신 HEAD 보다더최신일때만병합을허용 리뷰중에다른커밋이있을경우코드를병합하기위해서는 Rebase 를해야만함 C002 여기서 Rebase 를해야병합가능 C004 Review 브랜치 병합불가 C001 C003 C004 Master 브랜치
10. 변경 ID 병합 ( 커미터 ) Fast Forward Only 방식의병합 해당커밋이최신 HEAD 보다더최신일때만병합을허용 리뷰중에다른커밋이있을경우코드를병합하기위해서는 Rebase 를해야만함 (1) 개발자 1, C002 변경및리뷰제출 > vi branch.txt > git commit -a > git review (4) 병합불가 (2) 개발자 2, C003 변경및리뷰제출 > vi dev02.txt > git commit -a > git review (3) 리뷰어, C003 리뷰및병합 (4) C002 병합불가능 (5) 리뷰어, C002를 rebase (C004로이름변경 ) (6) 리뷰어, C004 리뷰및병합 (7) 개발자2, git pull (8) 개발자1, git fetch & git rebase (5) Rebase
10. 변경 ID 병합 ( 커미터 ) Merge If Necessary, Always Merge 해당커밋이최신 HEAD 보다더최신일때는 Fast Forward 병합수행 그렇지않은경우에는리뷰브랜치를포함한 Merge 시도 (Conflict Resolution 없다면 ) Review 브랜치 C002 브랜치 Merge C001 C003 C004 Master 브랜치
10. 변경 ID 병합 ( 커미터 ) Merge If Necessary, Always Merge 해당커밋이최신 HEAD 보다더최신일때는 Fast Forward 병합수행 그렇지않은경우에는리뷰브랜치를포함한 Merge 시도 (Conflict Resolution 없다면 ) (1) 개발자 1, C002 변경및리뷰제출 > vi branch.txt > git commit -a > git review (2) 개발자 2, C003 변경및리뷰제출 > vi dev02.txt ( 다른파일변경 ) > git commit -a > git review (3) 리뷰어, C003 리뷰및병합 (4) 리뷰어, C004 리뷰및병합 (Conflict 없음 ) (5) 개발자2, git pull (6) 개발자1, git pull
10. 변경 ID 병합 ( 커미터 ) Merge If Necessary, Always Merge 해당커밋이최신 HEAD 보다더최신일때는 Fast Forward 병합수행 그렇지않은경우에는리뷰브랜치를포함한 Merge 시도 (Conflict Resolution 없다면 ) (1) 개발자 1, C002 변경및리뷰제출 > vi branch.txt > git commit -a > git review (2) 개발자 2, C003 변경및리뷰제출 > vi branch.txt ( 동일한파일변경 ) > git commit -a > git review (3) 리뷰어, C003 리뷰및병합 (4) C002 병합불가능 (Conflict 발생 ) (5) 리뷰어, 리뷰중인변경 git fetch (6) 리뷰어, git rebase 및 merge > git rebase master > vi branch.txt (Conflict 해결 ) > git add branch.txt > git rebase --continue (7) 리뷰어, git review 리뷰제출 (8) 리뷰어, C004 리뷰및병합 (9) 개발자 2, git pull (10) 개발자 1, git fetch & git rebase
10. 변경 ID 병합 ( 커미터 ) Rebase If Necessary, Rebase Always 방식의병합 해당커밋이최신 HEAD 보다더최신일때는 Fast Forward 병합수행 그렇지않은경우에는 Rebase 시도 (Conflict Resolution 없다면 ) C002 Rebase C004 Review 브랜치 C001 C003 C004 Master 브랜치
10. 변경 ID 병합 ( 커미터 ) Rebase If Necessary, Rebase Always 방식의병합 해당커밋이최신 HEAD 보다더최신일때는 Fast Forward 병합수행 그렇지않은경우에는 Rebase 시도 (Conflict Resolution 없다면 ) (1) 개발자 1, C002 변경및리뷰제출 > vi branch.txt > git commit -a > git review (2) 개발자 2, C003 변경및리뷰제출 > vi dev02.txt ( 다른파일변경 ) > git commit -a > git review (3) 리뷰어, C003 리뷰및병합 (4) 리뷰어, C004 리뷰및병합 (Conflict 없음 ) (5) 개발자2, git pull (6) 개발자1, git pull
END OF DOCUMENT. http://www.twoseed.co.kr