0

I am a single developer learning how to use source control software. I have read the Subversion documentation. I understand the concept of merging but my question is: how often do you merge?

For example, if you have one developer working on the trunk and two developers working on separate branches then when do they:

1) Merge the trunk with branch 1
2) Merge the trunk with branch 2
3) Merge branch 1 with the trunk
4) Merge branch 1 with branch 2
5) Merge branch 2 with the trunk
6) Merge branch 2 with branch 1

In this example, please assume that the three changes are in isolation. Do you merge all at the end of each day? - assuming that the changes are stable of course or do you merge just in time for the release date?

In the past (when I have not used source control) I have released as and when. I assume it is better to set a release date, which I (and other developers) can work towards?

I have ready many posts on merging and branching today e.g. this one: Good branching and merging tutorials for TortoiseSVN?. I have not found an answer to my specific question.

Community
  • 1
  • 1
w0051977
  • 15,099
  • 32
  • 152
  • 329
  • You merge as often as possible, end of each day sounds a good option in your case. The reason for merging often is if there are dependency / code conflict they are much easier to maintain. – Mehul Rathod Jul 03 '13 at 07:29

2 Answers2

3

Different branching strategies are possible. But I would advise not to link them to any calendar or time events (like daily or weekly).

For me the following works:

  1. when I start a feature/bug-fix and I see it takes more than one commit, I create a branch for it
  2. implement the feature of fix the bug
  3. at the end merge all new changes from trunk (if any) to that branch
  4. check all tests
  5. reintegrate the branch into trunk

If development takes long time and there are changes in trunk it makes sense to merge trunk->branch several times during development to not deviate too much.

Sometimes such branches live 1-2 hours. Sometimes 1-2 months (but I dislike such things - usually that means insufficient decomposition).

Also I've never encountered a need to merge between branches (not including trunk), but this again depends on good decomposition of tasks. If a feature/bug-fix is completed, it should go to trunk, if it's not you should not use its intermediate state.

maxim1000
  • 6,297
  • 1
  • 23
  • 19
  • upvote for feature branches. see https://www.atlassian.com/git/workflows#!workflow-feature-branch for a longer explanation. they use another version control system, but feature branches stay feature branches -- and having heard about alternative vcs'es cannot harm ;) – mnagel Jul 03 '13 at 13:38
0

In addition to the answer of maxim1000 (+1 for that) here my experience:

i prefer to do more small merges over a big single merge, because you have often lees conflicts to solve. Disadvantage is that the total amount of invested time may be bigger when doing a lot of small merges.

When I do the merge depends on the number and quality of the changes which were done in the branches.

Micha
  • 5,117
  • 8
  • 34
  • 47