차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

--- git:git_use_2 [2023/11/07 15:38] – [git-flow의 브랜칭 모델 (출처: A successful Git branching model)] taekgu
+++ git:git_use_2 [2025/04/15 10:05] (현재) – 바깥 편집 127.0.0.1
@@ 줄 1: / 줄 1: @@
+====== Git 사용전략 2부 ======
+https://blog.naver.com/PostView.nhn?blogId=tmondev&logNo=220763012361
+Git에 대한 기본적인 사용법은 1부에서 알아보았다. 하지만 git은 사용법만 안다고 잘 사용할 수 있는 도구는 아니다. 어떤 식으로 사용하느냐에 따라서 그 효용성이 크게 달라지기 때문이다. 지금부터 git이 관리하는 핵심 대상인 commit을 잘 할 수 있도록 하는 것과, '형상관리'의 best practice라고 볼 수 있는 git-flow의 브랜치 전략을 이해하여 각자의 프로젝트 상황에 최적화 된 브랜칭 모델을 도출할 수 있도록 하는데 중점을 두고 차근차근 살펴보도록 하겠다.
+===== Commit 전략 =====
+이미 1부에서 commit이 무엇인가에 대해 살펴보았다. 까먹었을 수도 있으니 다시 짚고 넘어가자면, 'staged 상태에 있는 변경 내용들을 repository에 저장하는 것'이다. 하지만 이것은 사실 git을 사용하는 process 상에서 가지는 의미일 뿐이다. 이 보다 더 중요한 commit의 의미는, 'git이 관리해주는 history의 대상' 이라는 것이다. 왜 이 의미가 중요하냐면, git은 본질적으로 프로젝트의 역사를 관리해 주는 일을 한다. 즉, 프로젝트의 연표를 기록하는 것이다. 우리가 연표를 통해 어떠한 정보를 얻을 수 있는가는 연표에 기록된 사건 하나하나가 결정하게 된다. git을 통해 프로젝트의 변경이력을 관리할 때, commit이 그 프로젝트내에 발생한 개개의 사건이 되는 것이고, 이 사건들이 순서를 가지고 기록되어 나중에 우리에게 프로젝트의 역사를 알 수 있게 해준다.
+==== Commit으로 히스토리를 기록하자 ====
+브라우저와 웹기술 발전의 히스토리 연표 (출처 : The Evolution of the Web)
+위의 연표를 보면 우리는 각각의 웹브라우저가 언제 등장하고 어떻게 발전해 갔으며, 또 어느 시대에 어떤 웹 기술들이 등장했는지 쉽게 알 수 있다. git은 이와 같이 commit을 통해 히스토리를 기록해 과거를 알게 해주며 이에 그치지 않고 과거로 돌아가 오류를 수정하거나, 내가 기록한 역사와 다른 사람의 역사를 공유하게 하고 다양한 도움을 얻을 수 있도록 해준다.
+뭐, 역사에 빗대자면 그렇다는 것이고, 실제로는 과거에 개발한 소스를 매우 간단히 참조/수정/롤백할 수 있고, 다른 팀원이 개발한 소스를 쉽게 가져와 사용할 수 있으며, 여러 tool들과 연계하여 review 시스템을 구축한다던지 자동으로 static analysis를 하게 하는 등의 다양한 이점을 쉽게 취할 수 있는데, 이 모든 것이 commit을 대상으로 이루어진다는 것이다. 그렇기 때문에 commit의 형태나 규모를 어떻게 정하느냐에 따라 git이 관리해주는 history를 통해 얻을 수 있는 것들이 달라지게 된다. 그럼 이제 본격적으로 어떤 commit이 좋은 commit인지 알아보도록 하겠다.
+==== Commit은 의미있는 atmoic 단위로 작게! ====
+앞서 살펴본 바에 의하면 commit이 git이 관리하는 history를 결정하게 된다. 역사를 기록할 때 너무 큰 사건만 기록하면 알 수 없는 역사가 많아져서 문제고, 너무 작은 사건까지 일일이 기록하면 불필요한 정보가 너무 많아져서 정작 중요한 역사를 찾아보기 어려워 문제가 된다. 결국 기록의 정밀도를 정하는 것이 관건인데, 어느 수준으로 commit을 하는 것이 좋은지 한 번 살펴보도록 하자.
+단도직입적으로 얘기하자면 commit은 작은 단위로 하는 것이 좋다. 그런데 여기서 작다는 의미는 단순히 작다는 것이 아니고 의미를 갖는 더이상 쪼갤 수 없는 단위를 이야기 한다. 필자는 이런 단위를 atomic 이라고 부르길 좋아한다.
+==== atomic ====
+atmoic 단위는 TDD(Test-driven Development)를 빗대어 이해하면 쉽다. TDD를 보면 원하는 동작에 대한 test code를 먼저 작성하고 해당 test를 통과할 수 있는 실제 code를 작성해 매우 짧은 사이클의 개발이 반복된다. 예를 들어, 커피숍을 자동화 하는 프로젝트가 있다고 가정해보자. 필요한 시스템을 생각해보면, 최소한 주문/결제/생산시스템일 것이다. 주문 시스템만 더 세분화해서 보면 뷰를 제외하더라도 메뉴들, 장바구니, 선택버튼, 취소버튼, 주문버튼 정도는 있어야 할 것 같다. 여기서 선택버튼은 어떤 메뉴가 입력되면 이 것을 장바구니에 넣어주도록 동작하면 될 것이다. 이런 경우 TDD에서는 A라는 메뉴를 선택 후 선택버튼을 누르면 장바구니에 A가 정상적으로 담기는지 판정하는 test code를 작성하고 실제 시스템 코드가 이 test를 pass하도록 작업해 나가는 과정을 반복하게 된다.
+위 예시로 생각하면, 필자가 얘기하고자 하는 atomic commit 단위는 '각 음료 객체 추가', '전체 메뉴 리스트 추가', '장바구니 추가', '선택기능 추가' 등과 같이 작지만 의미가 있는 묶음의 단위이다. 내가 주문시스템을 담당하게 되었다면, 나는 주문시스템 전체를 완성해서 하나의 commit으로 만들어서도, 그렇다고 하나의 클래스나 메소드가 추가될 때마다 무의미하게 일일이 commit으로 만들어서도 안된다는 얘기다. 위에서 잠깐 언급 했지만, gerrit이나 bitbucket 등의 tool을 이용하면 commit을 기반으로 review 시스템을 구축할 수 있다. 이 때, 남이 개발한 코드를 review한다고 생각해보면 하나의 commit이 유의미한 최소단위로 되어 있을때 매우 고마울 것이다. commit 하기 전에 이렇게 review를 생각해 보거나 TDD를 생각해본다면 어느샌가 유의미한 최소단위로 commit을 하고 있는 자신을 발견하게 될 것이다!
+=== Commit 할 새도 없이 폭풍코딩 했을 때, 소소한 TIP ===
+commit을 작게 하려면 기본적으로 개발 싸이클을 작게 가져가야 한다. 하지만 우리 개발자들은 알고 있다. 그 분(?)이 오셨을 때 흐름을 끊지 않고 개발하는 것이 얼마나 효율적인지.. 아마 그 분이 가신 후 정신차리고 commit을 하려고 보면 너무 많은 코드가 수정되어 있어 곤란할 때가 있을 것이다. 이런 경우에는 1부에서 살펴봤던 stage 영역을 잘 활용하면 이미 개발된 대량의 소스를 작은 여러개의 commit으로 나누는게 가능하다.
+SourceTree에서 hunk, line 단위로 stage에 add 하는법
+SourceTree에서 보면 위와 같이 소스를 실컷 수정한 이후에 파일들이 'Unstaged files' 아래에 있는 것을 볼 수 있다. 이 상태가 1부에서 살펴본 'Modified' 상태이다. 여기서 'git add'를 통해 staged 상태로 보내진 내용들만 commit 되기 때문에 의미있는 작은 단위로 stage에 보내면 문제가 해결된다. 그런데, 보통 add는 파일 단위로 할 수 있기 때문에 내가 원하는 형태의 atomic commit을 만들 수 없지만, SourceTree에서는 line이나 hunk 단위로 stage에 보내는 것이 가능하다! 위 그림의 빨간 상자안의 버튼들이 바로 그것이다. 내가 작업한 소스들을 다시 한 번 살펴보면서 의미있는 작업내용들을 작은 단위로 뽑아서 아래와 같이 commit 할 수 있다. 단, 주의할 것은 반드시 모든 commit은 빌드 및 동작 가능한 상태를 유지해야 한다는 것이다.
+일부 line만 stage에 add한 결과
+===== Branch 전략 =====
+앞 장에서 좋은 commit을 만드는 방법에 대하여 고민해보았다. 좋은 commit을 만드는 것과 1부에서 다뤘던 브랜치를 깔끔하게 유지하는 것 만으로 하나의 브랜치에 대한 history는 충분히 유용하게 사용될 수 있는 형태가 되었다. 하지만 git이 정말 강력하고 유용한 도구로 평가받는 이유는 브랜치의 생성과 머지가 매우 간편해서 여러 브랜치를 동시에 운용하기에 유용하기 때문이다. 그렇다고 무분별하게 브랜치를 만들면 오히려 관리하기만 힘들어지고 전체 프로젝트의 생산성을 저해하게 된다. 이번 장에서는 대부분의 환경의 개발자들이 납득할 만한 브랜칭 모델인 git-flow에 대해서 살펴보고, 이를 통해 스스로 자신에게 맞는 브랜칭 모델을 설계할 수 있게 되는 것을 목표로 한다.
+==== Branch 따고, 머지하기 ====
+브랜치 전략을 알아보기에 앞서 브랜치의 분기와 병합에 대해 간단히 알아보도록 하자. 1부에서 브랜치는 stream과 같아서 갈라져 나오기도 하고 다시 합쳐지기도 한다고 했다. 갈라져 나오는 것을 분기(영어로는 branch, branching, branch out 등의 다양한 표현을 사용한다), 다시 합쳐지는 것을 병합(merge)이라고 한다. 지금까지 개발자들과 소통해본 결과로는 새로운 브랜치를 생성하는 것은 '브랜치를 따다', 브랜치를 합치는 것은 '머지하다'라고 많이들 사용하는 듯 하다.
+git에서 브랜치를 따는 것은 어느 commit에서든 가능하다. SourceTree를 기준으로 살펴보면 아래 그림과 같이 원하는 commit에서 우클릭을 하면 해당 시점에서 새롭게 브랜치를 딸 수 있는 메뉴를 제공한다. 내가 어느 브랜치의 어느 commit에서 브랜치를 따야하는지는 다음 챕터에서 git-flow에 대하여 알아보고 나면 감이 잡힐 것이다.
+commit에서 우클릭을 하면 branch 메뉴가 바로 보인다
+git에서는 브랜치를 머지하는 것도 매우 간단하다. 브랜치 목록상의 원하는 브랜치에서 우클릭을 하면 아래 그림과 같이 머지할 수 있는 메뉴가 나타난다. 머지 작업에 있어서 주의할 점은 source 브랜치와 target 브랜치를 혼동하지 말아야 한다는 것이다. git에서의 모든 변경은 활성화된(checkout된) 브랜치에 대해서 일어나게 된다. 따라서 내가 A라는 브랜치를 B에 머지하고 싶다고 하면, B 브랜치로 checkout한 상태에서 A 브랜치를 우클릭하여 머지해야 한다.
+==== branch를 merge하기 ====
+다행히도 SourceTree에서는 친절하게 "Merge myBranch into current branch" 라고 머지메뉴에 표시해 준다. 절대적은 아니지만 한가지 당부하고 싶은 것은, **가급적이면 브랜치 머지는 반드시 자신이 분기되어 나왔던 브랜치로만** 하길 바란다. 이 글의 목적이 git을 유용하게 사용하지만 쉽게 사용하자는 것인데, 무분별한 브랜치 머지를 일삼게되면 복잡한 그래프 속에서 git을 매우 어렵게 사용하게 되거나, history의 활용도가 떨어져 git을 단순 저장소로 사용하게 될 수도 있다.
+===== Git-flow =====
+Git-flow는 사실 Vincent Driessen이 [[https://nvie.com/posts/a-successful-git-branching-model/|A successful Git branching model]]에서 제안한 브랜칭 모델을 쉽게 사용할 수 있도록 구현한 tool kit의 이름이다. 해당 브랜칭 모델에 대해서는 따로 이름이 없기 때문에 일반적으로 그냥 git-flow를 tool kit과 브랜칭 모델 양쪽을 모두 이르는 중의적 표현으로 사용한다. 간혹 git-flow에 대하여 해당 브랜치 전략에 대한 이해는 배제한 채 git command 의 alias 정도로만 이해하고 사용하는 경우가 있는데, 사실 편의를 위해 제공되는 이 tool kit은 반복되는 typing 작업을 조금 줄여줄 뿐 git-flow의 진정한 가치와는 전혀 상관이 없다고 봐도 무방하다. 그럼, 아래 그림을 통해 정말 중요한 git-flow의 브랜칭 모델에 대해 알아보자.
+{{:git:git-model_2x.png?600|git-flow}}
+===== git-flow의 브랜칭 모델 (출처: A successful Git branching model) =====
+위 한 장의 그림이 git-flow의 거의 모든 것을 설명하고 있다. 하지만 다소 복잡해 보이는 것이 사실이다. 이 글의 주 목적은 git을 쉽게 사용하는 것이다. 그렇기 때문에 이런 복잡한 것은 그냥 패스하고 '그냥 정해진 순번대로 이렇게 작업하면 됩니다!'라고 알려주고 싶지만, 브랜치 전략 만큼은 방법론적 접근이 아닌 하나하나 이해할 수 밖에 없다. 왜냐하면 브랜치 전략에는 답이 없고, 프로젝트나 환경에 따라 각각에 맞는 브랜치 전략을 세워야 하기 때문이다. 앞서 말했듯이 git-flow는 상당히 많은 경우에 매우 합리적으로 작용하는 검증된 모델이고, 다소 복잡하지만 이 모델만 잘 이해하면 얼마든지 원하는 형태로 customizing할 수 있다고 보기 때문에 차근차근 이해해보자.
+git-flow에서는 **master**, **develop**, **feature**, **release**, **hotfix**의 다섯가지 브랜치를 제안하는데 나머지는 편의를 위한 것들이고 본질적으로 중요한 것은 굵은 글씨의 master와 develop 브랜치이다. 우선 이 두 브랜치에 대하여 살펴보자.
+  * master : 이미 충분히 검증되어 배포된 상용 소스를 버전별로 관리하는 브랜치이다. 즉, 버전 단위로 변경점이 관리되는 안정화된 브랜치이다.
+  * develop : 실제 개발이 이루어지는 브랜치이다. 모든 기능이 develop 브랜치에서 개발될 수 있고, 아직 개발중이기 때문에 안정성이 떨어질 수 있다.
+develop 브랜치에서 신나게 개발을 하고 안정화가 되면 master에 머지하고 버전을 찍는 구조라고 보면 된다. 이 두 개의 브랜치만 있으면 우선은 간단한 형상관리는 할 수 있다. 하지만, Vincent Driessen은 develop 브랜치에서 직접 master 브랜치로 머지하지 않고 다른 3가지 브랜치를 함께 제안하고 있는데, 거기에는 다 그만한 이유가 있다. 비본질적 브랜치이긴 하지만, 프로젝트를 성공적으로 이끌기 위해서는 사실 이 브랜치들의 역할이 정말 중요하다. 자세히 한 번 살펴보기로 하자.
+==== 1. 기능개발 (feature) ====
+새로운 기능을 개발하기 위한 브랜치이다. 이 브랜치는 develop 에서 분기되어 개발 완료 후 develop으로 머지되며, 개발중인 기능의 개수만큼 존재할 수 있다. 이 때 feature/myfeature 처럼 구분지을 수 있다. 대부분의 GUI tool에서 '/'에 의해 구분된 것을 폴더와 같이 hierarchy 구조로 보여준다. 기능개발은 develop 브랜치에서 해도 된다고 생각할 수 있지만, 동시다발적으로 여러 기능이 개발되거나, 규모가 큰 기능을 개발하는 경우에는 feature 브랜치를 사용해야 각각의 개발을 독립적으로 만들어 줄 수 있다. (간단한 수정은 develop에서 해도 무방하다) 그리고, 개발 단위가 기능으로 나뉘기 때문에 자연스럽게 모듈화에 도움을 줄 수 있다.
+==== 2. 릴리즈(release) ====
+기능개발 완료 후 안정화(일반적으로 QA가 되겠다)를 위한 브랜치이다. 다음 버전에 포함될 기능이 모두 머지된 시점의 develop 브랜치에서 분기하여 안정화 작업이 끝나면 develop과 master브랜치에 각각 머지된다. 테스트 등을 통해 발견된 버그들만 수정하여 release 브랜치에 반영하고 그 외의 변경은 일절 제한된다. 안정화 완료 후 release 브랜치를 develop 브랜치에 머지하는 이유는 release 브랜치가 develop 브랜치에서 분기되었기 때문에 release 브랜치에 존재하는 버그는 당연히 develop에도 존재하기 때문이다. 안정화가 진행되는 동안에는 변경이 제한되야 하기 때문에 개발이 일시적으로 중단되어야 하나, release 브랜치를 사용하면 안정화를 하면서도 develop 브랜치나 feature 브랜치에서 지속적으로 개발을 진행할 수 있다.
+<code bash>
+$ git checkout -b release-1.2 develop
+Switched to a new branch "release-1.2"
+$ ./bump-version.sh 1.2
+Files modified successfully, version bumped to 1.2.
+$ git commit -a -m "Bumped version number to 1.2"
+[release-1.2 74d9424] Bumped version number to 1.2
+files changed, 1 insertions(+), 1 deletions(-)
+</code>
+==== 3. 핫픽스(hotfix) ====
+이미 릴리즈 된 소스에서 버그가 발견되어 긴급히 수정하여 배포해야할 때 사용하는 브랜치이다. hotfix 브랜치는 master 브랜치에서 분기되어 master 브랜치와 develop 브랜치에 머지된다. 이렇게 hotfix 브랜치를 사용해야하는 이유는 Semantic Versioning에서도 발견할 수 있는데, 책임있는 개발자라면(특히 API를 개발한다고 하면) MAJOR, MINOR, PATCH 버전을 Semantic Versioning의 명시된 룰을 지켜서 기술해야 하며, 이 때 PATCH 버전을 변경해야 하는 상황에서 수정된 bug fix 이외의 변경점은 철저하게 통제되어야 하기 때문이다. 즉, hotfix 브랜치는 PATCH 버전이 변경되는 상황에 적합한 용도의 브랜치이다. 버그 없이 프로그램을 만들 수 있다면 hotfix 브랜치는 필요 없다고 할 수 있겠다.☺
+<code bash>
+$ git checkout -b hotfix-1.2.1 master
+Switched to a new branch "hotfix-1.2.1"
+$ ./bump-version.sh 1.2.1
+Files modified successfully, version bumped to 1.2.1.
+$ git commit -a -m "Bumped version number to 1.2.1"
+[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
+files changed, 1 insertions(+), 1 deletions(-)
+</code>
+정리하자면,
+  *1. 모든 개발은 develop 브랜치를 기반으로 진행하되, 새로운 기능을 개발하는 경우는 develop 브랜치에서 feature/* 브랜치를 새로 따서 작업 후 develop 에 머지한다.
+  *2. 배포를 위해 안정화를 해야 하는 경우에는 배포하고자 하는 기능들이 모두 머지된 develop 브랜치에서 release 브랜치를 따고 더 이상의 수정은 bug fix로 제한한다.
+  *3. 안정화가 완료되면, release 브랜치를 master 브랜치에 머지 후 versioning 하여 배포하고, release 브랜치에서 수정된 버그들은 develop 브랜치에 머지한다.
+  *4. 배포된 버전에서 문제가 생긴 경우에는 해당 버전의 master 브랜치에서 hotfix/* 브랜치를 따서 해당 문제를 수정한 후 master 브랜치에 머지하여 배포하고, develop 브랜치에도 확산전개 한다.
+git-flow에서 브랜치는 개발 프로세스의 각 단계가 독립적으로 진행될 수 있도록 하기위해 이용된다. 각 브랜치가 자신의 역할에 맞게 규칙을 두어 변경점을 제어함으로써 자신만의 형상을 관리하고 있는 것이다. git-flow의 브랜칭 모델은 절대적으로 따라야 하는 정답은 아니다. 이에 대해서는 다음 챕터에서 조금 더 자세히 이야기 하겠다. 다만, 우리가 git-flow의 브랜칭 모델을 통해 배워야 할 것은, git이 제공해주는 브랜치를 활용하는 방식이다. 자신이 직면한 형상관리 상의 문제들을 git-flow와 같이 브랜치를 활용하여 해결해 나갈 수 있게 된다면 git은 정말 강력한 도구가 되어 줄 것이다.
+===== Git-flow, 그대로가 아니라 커스터마이징 하자 =====
+세상에는 물건을 자르는데 쓰이는 수 많은 도구가 존재한다. 종이를 자르는데 쓸 수 있는 조그만 가위부터 커다란 나무를 자르는데 쓸 수 있는 전기톱까지 다양하다. 그런데 재밌는 것은 무조건 성능이 좋다고 좋은 도구는 아니라는 것이다. 종이를 자르는데 전기톱을 사용하면 오히려 정밀하게 자를 수 없을 뿐더러 힘만 더 들어가기 마련이다. 즉, 내가 하려는 작업의 규모에 따라 적절한 도구를 잘 선택해야 한다는 것이다. 브랜치 전략도 마찬가지이다. git-flow가 공개되고 몇 년 사이에 git 자체도 간단하지 않은데 설상가상으로 git-flow는 너무 복잡하다며 GitHub flow와 GitLab flow 등의 새로운 모델들이 등장했다.
+조금만 생각해봐도 QA 부서가 따로 존재하지 않거나, 개발단계에서 발견되지 않은 버그가 실제 필드에서 치명적으로 작용할 일이 없는 product를 개발할 때는 굳이 release 브랜치가 필요 없다. 또한, 사소한 버그들을 즉각적으로 수정해서 배포해야 할 의무가 없는 경우에 hotfix 브랜치도 필요 없다. 그리고, 한 두사람이 담당하고 있는 모듈의 경우 feature 브랜치도 필요없을 수 있다. 이와 같이 매우 간단한 프로젝트에서 완벽히 git-flow를 따른다면 이것은 전기톱으로 종이를 자르고 있는 격이 될 수도 있다는 것이다. 그렇기 때문에 git-flow를 그대로 차용하는 것이 아니라, 이를 통해서 브랜치를 활용하는 방식을 배워 자신만의 브랜치 전략을 세워야 한다.
+GitHub flow를 보면 master 브랜치와 feature 브랜치(feature/* 의 naming이 아닌 실제 작업의 내용을 요약하여 브랜치명으로 사용한다)만 존재하는 형태다. 기능개발이나 버그수정 모두를 동일한 레벨로 보고 각각의 브랜치에서 작업한 후 충분히 테스트 및 리뷰를 하고 master 브랜치에 머지하는 전략이다. 철저한 검증의 중요성보다 빠른 배포를 목적으로 한 형태라고 생각할 수 있다. 또한 실제 필드의 환경과 개발환경의 차이가 심한 상황이라 개발환경에서 제대로 검증할 수 없는 상황이라면 stage 브랜치 등을 만들어서 실환경에 물려 테스트 하는 용도로 사용할 수도 있을 것이다. 이처럼 자신들의 상황과 목적에 맞는 형상관리 형태에 맞춰서 git-flow에서 제시한 브랜칭 모델을 적절히 변형하여 활용하면 된다.
+==== 마치며.. ====
+'Git은 참 어렵고 복잡하다' 이것이 git을 접하고 6개월 정도 내가 가지고 있던 생각이었다. 하지만 지금은 '아! 정말 git이 있어 다행이다'라고 생각한다. 내가 그랬듯이 git을 어려워하는 사람들을 위해 이 글을 쓰기 시작했는데, 쉽게 잘 설명이 되었는지 모르겠다. 뭐, 1, 2부를 정독했는데도 도무지 무슨말인지 모르겠다면 개인적으로 문의하기 바란다.
+Git이 초반에 알아야 할 개념도 많고 자유도가 높아 쉽게 복잡한 모양새를 만들어 버릴 수 있어서 그렇지, 사실 원칙을 정해서 그에 맞게 사용하면 생각보다 단순하게 사용가능한 녀석이다. 그러니 다음의 몇 가지만 기억하자!
+  - GUI tool을 사용하자
+  - Git이 관리해주는 기본단위인 commit은 의미있는 작은 단위로 만들자
+  - 1부에서 설명한 7단계 방법을 이용해 하나의 브랜치에 기록되는 history를 끊임없이 깔끔하게 유지해주자
+  - Git-flow를 기반으로 자신의 상황에 맞는 브랜치 전략을 수립하고 룰에 어긋난 무분별한 브랜치 머지를 하지말자
+그럼 모두들 git과 함께 즐거운 개발 하시길~!!
+[출처] Git, 가장 쉽게 사용하기 - (2) commit, branch 전략 잘 짜는 법|작성자 개발몬스터

GaramX

사용자 도구

사이트 도구

차이

문서 도구