분기 전략

분기 전략

---

내가 일하는 회사는 현재 분기 모델에 문제가 생기기 시작했고 커뮤니티가 어떤 종류의 분기 전략에 노출되었는지 궁금합니다.

다른 상황에 적합한 것이 있습니까? 귀사는 무엇을 사용합니까? 그들의 장점과 단점은 무엇입니까 ??

---

다음은 과거에 성공적으로 사용한 방법입니다.

/ 트렁크-블리딩 에지. 코드의 다음 주요 릴리스. 주어진 시간에 작동하거나 작동하지 않을 수 있습니다.

/branches/1.0, 1.1 등. 코드의 안정적인 유지 관리 분기. 버그를 수정하고 새 릴리스를 안정화하는 데 사용됩니다. 유지 보수 브랜치 인 경우 컴파일 (해당되는 경우)하고 언제든지 QA / 배송 준비가되어 있어야합니다. 안정화 분기 인 경우 컴파일되고 기능이 완전해야합니다. 새로운 기능을 추가하거나 리팩토링하거나 코드를 정리하지 않아야합니다. 사전 접두사를 추가하여 안정화 분기와 유지 보수 분기를 나타낼 수 있습니다.

/ branches / cool_feature. 매우 실험적이거나 파괴적인 작업에 사용되며 트렁크 (또는 유지 관리 분기)에 들어갈 수도 있고 그렇지 않을 수도 있습니다. 코드 컴파일, 작동 또는 정상 작동에 대한 보장이 없습니다. 메인 라인 분기로 병합하기 전에 가능한 한 최소 시간 동안 지속되어야합니다.

/tags/1.0.1, 1.0.2, 1.1.3a 등. 패키지 및 배송 된 릴리스에 태그를 지정하는 데 사용됩니다. 절대 변경하지 마십시오. 원하는만큼 태그를 만들지 만 변경할 수 없습니다.

---

이 문제에 대한 Eric Sink의 의견을 읽는 것이 좋습니다.

7 장 : 분기

나는 Eric과 마찬가지로 그가 말하는 "폴더"스타일 분기를 선호합니다.

---

분기 패턴에 대한 어머니 광맥은 Brad Appleton의 Streamed Lines : Branching Patterns for Parallel Software Development를 참조하십시오 . 그것은 무거운 의무이지만 분기에 대한 지식의 폭과 깊이 측면에서 그것을 능가하는 것을 보지 못했습니다.

---

저장소는 다음과 같습니다.

/trunk
/branches
/sandbox
/vendor
/ccnet

/ trunk 는 표준, 최첨단 개발입니다. CI를 사용하므로 항상 테스트를 빌드하고 통과해야합니다.

/ branches 여기에 '승인 된'큰 변경 사항이 적용됩니다. 즉, 우리가 알고있는 것은 트렁크에 넣을 수 있지만 작업이 필요할 수 있으며 CI를 깨뜨릴 수 있습니다. 또한 자체 CI 프로젝트가있는 유지 관리 릴리스를 작업합니다.

/ sandbox 각 개발자는 자체 샌드 박스와 공유 샌드 박스가 있습니다. 이는 실제 작업을 수행하지 않을 때 수행하는 "제품에 LINQ 공급자 추가"유형의 작업과 같은 작업입니다. 결국 트렁크에 들어갈 수 있지만 그렇지 않을 수도 있지만 거기에 있으며 버전 제어하에 있습니다. 여기에 CI가 없습니다.

/ vendor 우리가 컴파일하는 프로젝트에 대한 표준 공급 업체 브랜치이지만 유지 관리하는 코드는 아닙니다.

/ ccnet 이것은 우리의 CI 태그이며 여기에는 CI 서버 만 쓸 수 있습니다. Hindsight는이 이름을 CI, BUILDS 등과 같은 좀 더 일반적인 이름으로 변경하라고 말했을 것입니다.

---

1. 활성 개발을위한 하나의 브랜치 (용어에 따라 / 메인 또는 마스터)
2. 각 유지 관리 릴리스에 대해 하나의 브랜치-> 아주 작은 수정 만 받게되며 모든 주요 개발은 / main으로 이동합니다.
3. 각 새 작업에 대해 하나의 분기 : Bugzilla / Jira / Rally의 모든 새 항목에 대해 작업 할 새 분기를 만듭니다. 자주 커밋하고 인치 페블 체크인을 사용하여 변경 사항을 자체 문서화하고 완료되고 잘 테스트 된 경우에만 "상위"분기에 다시 병합합니다.

이것 좀 봐 http://codicesoftware.blogspot.com/2010/03/branching-strategies.html 더 나은 설명

---

첫 번째 : KISS (단순하게 멍청하게 유지하세요!)

/ 가지
  /RB-1.0(*1)
  /RB-1.1(*1)
  /RB-2.0(*1)
/ 태그
  /REL-1.0 (또는 버전이 1.0.0.123 * 2)
  /REL-1.1
  /REL-2.0
/트렁크
  멋진 새 기능으로 현재 개발 ;-)

* 1) 버전 유지 관리-예를 들어 서비스 팩, 핫픽스, 필요하거나 필요한 경우 트렁크에 병합 될 수있는 버그 수정) * 2) major.minor.build.revision

경험의 규칙 :

1. 태그 폴더는 체크 아웃 할 필요가 없습니다.
2. 릴리스 브랜치에서 코딩이 거의 없음 (병합이 더 간단 해짐)-코드 정리 없음 등
3. 태그 폴더에 코딩하지 않음
4. 구체적인 버전 정보를 소스 파일에 넣지 마십시오. 빌드 메커니즘이 빌드중인 버전 번호로 대체 할 자리 표시 자 또는 0.0.0.0을 사용합니다.
5. 타사 라이브러리를 소스 제어에 넣지 마십시오 (또한 아무도 STL, MFC 등의 라이브러리를 SVN에 추가하지 않습니다 ;-))
6. 컴파일되는 코드 만 커밋
7. 하드 코딩 된 경로 (절대 및 상대 경로) 대신 환경 변수 사용을 선호합니다.

--hfrmobile

---

릴리스가 최종 QA를 위해 준비되면 분기합니다. QA 프로세스 중에 문제가 발견되면 분기에서 버그를 수정하고 유효성을 검사 한 다음 트렁크에 병합합니다. 분기가 QA를 통과하면 릴리스로 태그를 지정합니다. 해당 릴리스에 대한 모든 핫픽스도 분기에 수행되고 유효성이 확인되고 트렁크에 병합 된 다음 별도의 릴리스로 태그가 지정됩니다.

폴더 구조는 다음과 같습니다 (QA 라인 1 개, 핫픽스 릴리스 2 개, 트렁크).

/ 가지

/REL-1.0

/ 태그

/REL-1.0

/REL-1.0.1

/REL-1.0.2

/트렁크

---

We use the wild, wild, west style of git-branches. We have some branches that have well-known names defined by convention, but in our case, tags are actually more important for us to meet our corporate process policy requirements.

I saw below that you use Subversion, so I'm thinking you probably should check out the section on branching in the Subversion Book. Specifically, look at the "repository layout" section in Branch Maintenance and Common Branch Patterns.

---

The alternative I'm not seeing here is a "Branch on Change" philosophy.

Instead of having your trunk the "Wild West", what if the trunk is the "Current Release"? This works well when there is only one version of the application released at a time - such as a web site. When a new feature or bug fix is necessary a branch is made to hold that change. Often this allows the fixes to be migrated to release individually and prevents your cowboy coders from accidentally adding a feature to release that you didn't intend. (Often it's a backdoor - "Just for development/testing")

The pointers from Ben Collins are quite useful in determining what style would work well for your situation.

---

Henrik Kniberg's Version Control for Multiple Agile Teams also has some good points to take into consideration.

---

We currently have one branch for ongoing maintenance, one branch for "new initiatives" which just means "stuff that will come out sometime in the future; we're not sure when." We have also occasionally had two maintenance branches going on: one to provide fixes for what is currently in production and one that is still in QA.

The main advantage we've seen is the ability to react to user requests and emergencies more rapidly. We can do the fix on the branch that is in production and release it without releasing anything extra that may have already been checked in.

The main disadvantage is that we end up doing a lot of merging between branches, which increases the chance that something will get missed or merged incorrectly. So far, that hasn't been a problem, but it is definitely something to keep in mind.

Before we instituted this policy, we generally did all development in the trunk and only branched when we released code. We then did fixes against that branch as needed. It was simpler, but not as flexible.

---

Jeff Atwood wrote about this in a good blog post; that post has got some important links in it.

---

Gnat has written this excellent break down on the various bits of advice your can find on branching strategies.

There's not one branching strategy, it's what works for:

• Your team size
• Your product and the lifecycle periods
• The technology you're using (web, embedded, windows apps)
• Your source control, e.g. Git, TFS, Hg

Jeff Atwood's post breaks down a lot of possibilities. Another to add is the concept of promotion (from Ryan Duffield's link). In this setup you have a dev branch, test bracnh and release branch. You promote your code up until it reaches the release branch and is deployed.

---

The philosophy that we follow at work is to keep the trunk in a state where you can push at any time without drastic harm to the site. This is not to say that the trunk will always be in a perfect state. There will of course be bugs in it. But the point is to never, ever leave it broken drastically.

If you have a feature to add, branch. A design change, branch. There have been so many times where I thought, "oh I can just do this in the trunk it isn't going to take that long", and then 5 hours later when I can't figure out the bug that is breaking things I really wished that I had branched.

When you keep the trunk clean you allow the opportunity to quickly apply and push out bug fixes. You don't have to worry about the broken code you have that you conveniently branched off.

---

This would depend on which Version Control System you're using. Each VCS has different approaches to branching.

Which VSC do you use?

---

For Subversion, I agree with Ryan Duffield's comment. The chapter he refers to provides a good analyses on which system to use.

The reason I asked is that Perforce provides a completely different way to create branches from SVN or CVS. Plus, there are all the DVCSs that give it's own philosophy on branching. Your branching strategy would be dictated by which tool(s) you're using.

FYI, Svnmerge.py is a tool to assist with merging branches in SVN. It works very well as long as you use it frequently ( every 10-30 ) commits, otherwise the tool can get confused.

---

No matter which branching pattern chosen, you should try to keep your branches in a binary tree form like this:

   trunk - tags
     |
    next
   /  \  \
bugfix  f1  f2
        /   \  \          
       f11    f21 f22

• Child nodes should only merge with the direct parent.
• Try ur best to merge only the whole branch with the parent branch. never merge subfolders within a branch.
• You may cherry pick commits when needed as long as you only merge and pick from whole branch.
• The next branch in the above figure is only for illustration, you may not need it.

참고URL : https://stackoverflow.com/questions/34975/branching-strategies