10

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/git-model@2x.png 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:

Cœur
  • 37,241
  • 25
  • 195
  • 267
Daan Timmer
  • 14,771
  • 6
  • 34
  • 66

1 Answers1

3

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.

db48x
  • 3,108
  • 24
  • 16
  • I've read a bit about `submodules` however what I've been able to conclude from all the information on them is that they are analogues to `svn:externals` which we used before and wanted to get rid off badly. For the simple reason that we want each "super" project to have their own copy of the libraries that can be modified without interrupting other "super" projects. If that is not the case then I will look in to submodules a bit more though. – Daan Timmer Nov 16 '15 at 22:01
  • In that case you should just check the source of the libraries into the same git repository as the projects that use them. That does make pushing changes to those libraries back upstream more difficult though. Note that the superproject can use a branch of the library as a submodule; you could have each of your projects point to a different branch of the library. – db48x Nov 16 '15 at 22:19
  • "we want each "super" project to have their own copy of the libraries that can be modified without interrupting other "super" projects" .. that's exactly what submodules are. They're local repositories. There is no global state, there is only what gets sent. You can maintain private branches in them, that's very common. – jthill Nov 17 '15 at 03:21
  • Well `git submodules` is a no go. It seems that the buildserver (Atlassian Bamboo) doesn't like submodules. The only way to get that working is by giving the bamboo server complete read/write access through a public key which, I am not too fond off. So I am going for subtree. I've given a small presentation to my colleagues and they did not seem to be against it and quite liked the workflow involved. – Daan Timmer Nov 22 '15 at 12:31