0

I have to setup git repository for development of software based on preexisting source code of a software vendor. The source code is being periodically updated, I'm looking for most effective approach, I've come up with 2 models of working and I would love to hear your opinion on which one (or maybe another one) would be most effective in my situation.

Overall, there will be 3 completely independent teams each working in their own separate code repositories: A, B, C.

Source code repository / team A is where based vendor code exits. Source code repository / team B is where based vendor code exits + extensions by 3rd party. Source code repository / team C the one I'm trying to setup, which should be based on A + B and our own extensions.

Whenever repository A changes, guys from team B will pull it into their repository, integrate and make it available for team C.

Team B may also make independent releases on their own (without any changes from Team A) which they will make available for Team C.

For team C, I would to setup repository separate branches:

master
TeamA
TeamB
develop

Branches TeamA and TeamB will be managed by us (Team C) - we will update them ourselves whenever we receive code from teams A and B and merge them into develop.

The goal is to be able to understand what is our diff (develop) between TeamA and TeamB (and diff between TeamA and TeamB) and most easily integrate changes from team A and B into develop.

I wonder whether there is any difference regarding if I setup following structure:

1) make all the branches based on master

master
    TeamA
    TeamB
    develop

or, 2) make following parent-child structure of branches

master
    TeamA
        TeamB
            develop

I wonder if it makes any practical difference.

Does anyone had similar situation in the past, what approach would you recommend?

michal.slocinski
  • 475
  • 1
  • 8
  • 19

1 Answers1

0

In Git repo, each branch works separately. So the two structures your provided actually work same with other other. And your branch structure can works for your team (Team C).

And you can also exempt TeamA and TeamB branches in repoC, pull changes from repoA and repoB to develop branch directly:

git remote add -f teamA <URL for repoA>
git checkout develop
#Use git fetch teamA and git fetch teamB when there has new changes on repoA and repoB
git pull teamA/master --allow-unrelated-histories
git pull teamB/master --allow-unrelated-histories
#After making changes and commit changes on develop branch
git checkout master
git merge develop

Note: No matter which branch structure you used, you should notice the merge conflicts since the three repos contain same files/code.

Marina Liu
  • 32,805
  • 4
  • 48
  • 60
  • Thank you for your answer. Yes, I'm aware of the conflicts that will have to be resolved - that is part of the business :-) So as I understand in general there is no additional functionality behind parent/child branches in Git that would help with merging / browsing through history / diff. – michal.slocinski Sep 27 '17 at 08:44
  • Yeah, a branches can be created (checkout) from another branch, but they are not parent/child relations, both of the branches are work separately. – Marina Liu Sep 27 '17 at 10:59
  • Did the answer help you solve the problem? If yes, you can mark it. And it will help others who have similar questions. – Marina Liu Oct 10 '17 at 09:44