언제 분기해야합니까?

언제 분기해야합니까?

---

SCM 시스템으로 작업 할 때 언제 분기해야합니까?

---

분기에는 몇 가지 용도가 있습니다. 가장 일반적인 용도 중 하나는 한때 공통 코드 기반이 있던 프로젝트를 분리하는 것입니다. 이것은 메인 트렁크에 영향을주지 않고 코드를 실험하는 데 매우 유용합니다.

일반적으로 두 가지 분기 유형이 표시됩니다.

• 기능 브랜치 : 특정 기능이 전체 개발 팀이 초기 단계에 영향을받는 것을 원하지 않을 정도로 방해가되는 경우이 작업을 수행 할 브랜치를 만들 수 있습니다.

• Fixes Branch : 메인 트렁크에서 개발이 계속되는 동안, 소프트웨어의 최신 릴리스 버전에 대한 수정을 보관하기 위해 수정 브랜치를 생성 할 수 있습니다.

분기의 원리와 사용시기를 설명하는 다음 기사를 확인하는 것이 좋습니다.

• Ned Batchelder-Subversion 분기 빠른 시작

---

일반적으로 분기 (VCS-버전 제어 시스템-기능)의 주요 목적은 코드 격리 를 달성하는 것 입니다.

당신은 적어도이 하나 개의 순차적 인 개발을 위해 충분히 될 수 분기를, 그리고 같은 독특한 분기에 녹화 (노력)있는 많은 작업에 사용됩니다.

그러나 그 모델은 그 한계를 빠르게 보여줍니다.

개발 노력 (리팩토링, 진화, 버그 수정 등)이 있고 현재 개발 브랜치와 동일한 브랜치에서 이러한 변경을 안전하게 수행 할 수 없다는 것을 깨달았을 때 (API를 손상 시키거나 중단되는 코드를 도입하기 때문입니다. 모든 것), 그러면 다른 지점 이 필요합니다 .
( 나중에 두 코드 세트가 병합 되더라도 레거시 코드에 대한 새 코드 를 분리 하려면 )

이것이 바로 거기에 대한 답
입니다. 한 지점에서 두 가지 개발 노력을 추구하고 기록 할 수 없을 때마다 분기해야합니다.
(유지해야 할 끔찍하게 복잡한 역사가 없음).

---

분기는 소스 코드에서 작업하는 유일한 사람이더라도 유용 할 수 있습니다.
그러나 "개발자 당 하나의 브랜치"를 만들어서는 안됩니다.
"격리"목적은 개발 노력 을 분리하기 위한 것입니다 ( "다음 버전의 소프트웨어를 개발하자"만큼 일반적이거나 "수정하자"와 같이 구체적 일 수 있음) bug 23 "),
"리소스 "를 분리하지 않습니다 .

( "VonC"라는 분기는 다른 개발자에게 아무런 의미가 없습니다. "VonC"가 프로젝트를 떠나면 어떻게됩니까?이 프로젝트로 무엇을해야합니까?
"bugfix_212"라는 분기는 예를 들어 버그 추적 시스템의 컨텍스트에서 해석 될 수 있습니다. , 모든 개발자는 자신이해야 할 일에 대한 아이디어를 가지고 사용할 수 있습니다.)

분기는 태그가 아닙니다 (SVN은 저렴한 파일 복사를 통해 디렉토리를 통해 분기 및 태그 지정과 같은 버전 관리 기능을 제안 하는 개정 시스템 입니다 . 태그가 분기라는 의미는 아닙니다)

브랜치를 정의한다는 것은 병합 워크 플로 를 정의하는 것을 의미하기도 합니다. 브랜치를 완료했을 때 브랜치를 병합 할 위치를 알아야합니다.
이를 위해 Practical Perforce (Laura WINGERD-O'Reilly)의 7 장은 서로 다른 종류의 브랜치 간의 워크 플로우를 병합하는 좋은 소개 (VCS 불가지론)입니다. "" 소프트웨어가 진화하는 방법 "(pdf)

이 용어 정의 코드 라인 (코드의 중요한 발전 단계를 기록 지점, 중 특정 지점에서 태그를 통해, 또는 분기에 중요한 병합 다시 통해를)

메인 라인 모델 (릴리스를 기록하는 중앙 코드 라인)을 소개하고 분기를위한 다양한 목적을 설명합니다.

• 활성 개발 스트림 : 순차적 인 다양한 개발이 발생할 때 지속적인 코드 라인
• 작업 브랜치 :보다 구체적인 작업을위한 단기 브랜치 (버그 수정은 고전적인 작업이지만 완료하기 복잡하다고 알고있는 병합 작업에 대한 브랜치를 정의 할 수도 있습니다. 해당 작업 브랜치에서 병합, 커밋 및 테스트 할 수 있습니다. 주요 현재 개발 브랜치에 문제를 일으키지 않고)
• 스테이징 분기 : 일부 사전 프로덕션 특정 데이터 또는 구성 파일이있는 릴리스를 준비합니다.
• 비공개 브랜치, 임시 브랜치 및 스파 스 브랜치 : 매우 작은 작업의 경우 공식적인 완료 또는 테스트 검토를 기다리지 않고 진행중인 일부 작업을 수행 할 수 있습니다.
  이를 통해 "일찍 커밋하고 자주 커밋"할 수 있습니다.

---

_{VCS에 대한 기타 흥미로운 개념 : 기본 개념
(원래 ClearCase에 대한 것이지만 모든 VCS에도 유효 함)}

---

모든 21 세기 SCM은 다음과 같이 말합니다.

새로운 기능, 버그 수정, 테스트 여부에 관계없이 작업해야하는 모든 작업에 대해 분기합니다 . 이를 토픽 브랜치라고하며 SCM으로 작업하는 방식을 변경합니다.

당신은 얻을 :

• 더 나은 격리
• 더 나은 추적 성-> 작업을 개별 변경 집합이 아닌 분기와 연결하여 원하는만큼 자유롭게 커밋 할 수 있으며 "작업 당 하나의 체크인"과 같은 제한을 부과하지 않습니다.
• 작업은 독립적이며 (일반적으로 안정적인 기준에서 시작하므로 사용자의 버그를 수정하는 것이 아니라 코드에만 집중할 수 있습니다.) 어느 시점에서 통합할지 아니면 나중에 통합할지 선택할 수 있지만 항상 아래에 있습니다. 버전 관리
• 메인 라인에 도달하기 전에 코드를 쉽게 검토 할 수 있습니다 (사전 커밋이 아닌 버전 제어에서).

Tools that can do it:

• Git
• Mercurial
• Plastic SCM

Tools that CAN'T do it:

• SVN
• CVS
• VSS
• TFS
• Perforce

---

It also depends on the SCM tool you are using. Modern SCMs (git, mercurial, etc.) make it increasingly easy to create and destroy branches whenever needed. This allows you to, for example, make one branch per bug that you are working on. Once you merge your results into the trunk, you discard the branch.

Other SCMs, for example subversion and CVS, have a much "heavier" branching paradigm. That means, a branch is considered appropriate only for something bigger than a twenty-something-line patch. There, branches are classically used to track entire development tracks, like a previous or future product version.

---

When you need to make significant and/or experimental changes to your codebase, particularly if you want to commit intermediate changes, without affecting trunk.

---

It depends on what type of SCM you're using.

In the newer distributed versions (like git and mercurial), you're creating branches all the time and remerging anyway. I'll often work on a separate branch for a while just because someone's broken the build on the mainline, or because the network's down, and then merge changes back in later when it's fixed, and it's so easy to do that it's not even annoying.

The document (short and readable) that most helped me understand what was going in in the distributed systems is: UnderstandingMercurial.

In the older systems with a central repository, (like CVS, SVN and ClearCase), then it's a much more serious issue which needs to be decided at a team level, and the answer should be more like 'to maintain an old release whilst allowing development to continue on the main line', or 'as part of a major experiment'.

The distributed model is much better, I think, and lacking only nice graphical tools to become the dominant paradigm. However it's not as widely understood, and the concepts are different, so it can be confusing for new users.

---

I find the advice from Laura Wingerd & Christopher Seiwald at Perforce is really concise and useful:

* Branch only when necessary.
* Don't copy when you mean to branch.
* Branch on incompatible policy.
* Branch late.
* Branch, instead of freeze.

See http://www.perforce.com/sites/default/files/pdf/perforce-best-practices.pdf for a detailed explanation of each of them and other best practice.

---

There are various purposes for branching:

1. Feature/bug branches. Dynamic and active branches that get moved back into the trunk when the feature/bugfix is complete.
2. Static branches (tags in Subversion, though in essence just a 'normal branch'). They provide a static snapshot of say, a release. Even though they could be worked on, they remain untouched.

---

The need for branching may also arise:

when you want to provide a hotfix to a particular customer (say important) and you are unsure whether the fix will be part of future releases

---

Whenever you feel like it.

You probably won't very frequently if you work with a centralized SCM since the branches are part of the official repository, and that doesn't really invite much experimentation, not to mention that merges really hurt.

OTOH, there's no technical difference between a branch and a checkout in distributed SCMs, and merges are a lot easier. You'll feel like branching a whole lot more often.

---

When you need to make changes, based on your current branch, not destined for the next release from that branch (and not before).

For example, we work on trunk usually. Around the time of release, someone's going to need to make a change that we don't want in the current release (it may be before release, at the moment it's usually after release). This is when we branch, to put the release on its own branch and continue development for the next release on trunk.

---

Leaving all the technicalities aside.....

Branch when you know its easier to merge back!

Keeping in mind that merging will always be effected with how the work is carried out in a project.

Once this achieved all the other tertiary issues will come in to play.

참고URL : https://stackoverflow.com/questions/2100829/when-should-you-branch