Transferring from SVN to GIT, merge workflow changes from SVN to GIT with shared repositories

Question

Right, so I am tasked with finding out if GIT would be a solution for an upcoming problem that we are having. (Easily creating feature branches, hotfix branches, bugfix branches, while keeping the trunk clean and only feature completed issues (feature, hotfix, bugfix etc). So that once a release needs to be done no half-completed/committed issues will be released.

Previously we been using SVN, with a modified version of the git-flow/branching model featured here: http://nvie.com/img/[email protected] Where the git-master is our svn-trunk. This works-ish, but is a bit cumbersome with SVN. Especially since we use two shared repositories.

And here comes the problem. Previously we used those two shared repositories as externals, and all the external references were pointed to lib/a/branches/develop and lib/b/branches/develop. This was cumbersome to work with if a feature/hotfix/bugfix branche was needed because it required creating three branches, modifying the super-project with the new references and then committing said changes.

After some careful tinkering we switched to using branches of the library repositories. (so, superProject/lib/a is a branch from lib/a/branches/develop) and future updates (both ways) would require a merge either from superProject/lib/a in to lib/a/branches/develop or visa versa.

This however still did not solve our problem of half-completed commits once a release would be near. (And sadly, at the company where I work this can be needed in an hour). So we thought a little bit more and agreed to start trying to use the tools provided by Atlassian a bit more, thus trying out Bitbucket (previously using Crucible/FishEye) and using their special integrated workflow for git where for each issue a branch can be created and once completed a pull request can be created so our release manager controls what goes in and what does not go in the next release. No more half-baked issues in /develop/ as all issues will be done using said workflow.

The problem I am facing is how to incorporate these shared projects (library a and b). I've been reading the web and found multiple sites talking about git-submodules, git-subtree-merging-strategy, git-subtree (the script) and manual merging (is that the same as the subtree merging?). But none really answer some of my git-newbie questions. So far I've been most intrigued by git-subtree, but the GUI support seems to be abysmal. Neither TortoiseGit, SourceTree has some good GUI support for git-subtree, which will require command-line actions, and knowing most colleagues, they don't like to do command-line things.

What's also been bothering me is that there is no good, what I can find, information on from which repository/branch the git-subtree was created and the fact that a clone from the remote git repository does not automatically include the correct remote-links for any git-subtree. Thus if I wan't any of my fellow developers to be able to update the git-subtree from their remote origin they would have to manually do a git remote add -f libraryXXX http://repohere/lib-xxx.git (once) and then do git subtree pull --prefix locationGoesHere libraryXXX master (--squash optional)

This all seems so much more cumbersome than the workflow for SVN with merging branches back and forth. Am I missing something? Am I reading outdated information? Am I just not looking at the correct way of working with shared repositories?

Some of the resources I used:

• https://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/
• https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt
• https://developer.atlassian.com/blog/2015/05/the-power-of-git-subtree/?continue=https%3A%2F%2Fdeveloper.atlassian.com%2Fblog%2F2015%2F05%2Fthe-power-of-git-subtree&application=dac
• https://medium.com/@porteneuve/mastering-git-subtrees-943d29a798ec
• Git subtree -- sharing subtrees with contributors

Answer 1

It's difficult to make many pronouncements on your setup, even with the detailed description you've given. However, I can say that you'll find branching in git to be practically painless (especially when compared to svn). I recommend using submodules for your library dependencies. They're not perfect, but they work. When you create a branch, that branch will start out using the same version of the libraries as it's parent, and you can edit the .gitmodules file to use different ones. You do have to remember to create a new clone with the --recursive flag (or to use git submodule update after cloning), but that's far easier than it is for subtrees.