Here's a strategy that might work for you:
Create 2 private git repos, with one repo being for company work and the other being the general (I'd like to commit back) repo.
In order to make this system work, you need to do this (which I consider the most important strategy): Define what is "general" and can be used by everyone else in the community
By having this definition, you can separate out what you will commit back and what you don't need to commit.
It makes sense that what you code for the community be in a general form, as too specific a piece of code will benefit nobody (and might not even make it to the master branch).
Now that you know what you're going to commit to the community, you can do most "give-back" work in the repo dedicated to it. Then you simply fork that repo over to your work-based repo and do any work-specific work on top of that.
I suspect that you will spend a lot more time in the "give-back" repo, so just remember to provide valuable comments, etc (maybe even documentation) for people who would use that project in the future.
I also believe that git can do a lot more than you think. I watched this video on Vimeo: http://vimeo.com/46010208 and she did a brilliant job of explaining a lot of wacky things git can do.
My strategy isn't the only one out there, but it can definitely be a starting point for you to think of 1 that suits you specifically.
This is very similar to a successful git branching model that we've employed in my workplace - it works wonders for us (though we differ slightly from your branching a little, and put the git tag on production server so that devs don't patch live and update git via production server (and possibly fubar the branches)).
When developing
Your proposed method is great. Every developer has their own workplace (on the server) and they have their own [feature] branches - this will be great help as you'll be able to track what features are in development, where in the development lifecycle they are, and who is responsible for them (though if you adopt agile workflow, you'll know this; it's nice to know when you look back in the past).
Developers having their own [feature] branch when developing will allow you to work on different features without overwriting each others work.
This stage is fine, no caveats
When testing
Testing can become confusing, because what if you find a major bug that needs patching but feature X is ready to go live? Who is responsible for the testing?
Fixing a bug during testing
When you have your testing
branch on the test server and you find a bug that needs patching, it can be addressed 2 ways;
- Checkout of
testing
branch into a bug fix (bf-
) branch. When there is a bug, usually I create an issue detailing what needs patching and name the bug fix branch after it (ie: opened issue #293, the branch will be bf-293
). This will greatly help you track what was fixed.
- Directly patch the
testing
branch.
Testing multiple features
Again, very easy to do with your proposed branching model. Ensure you create a pull/merge request to document what code was changed (this has saved my bacon many times in the past) and at what stage in the products lifecycle a particular feature went into testing and production.
Once all features have been merged into the development
branch, ensure you create a fresh testing
branch (I usually name these release candidates. Ie: we are testing v2.42, I will name this testing branch rc-2.42
) and push up to the testing server.
This stage is fine, no caveats
Go live
Going live with git is great. Once you're happy with your test results and ready to push live, ensure you open a pull/merge request so that it's documented what is going live when (as previously mentioned).
! If you fixed some bugs during testing then make sure you merge the testing
branch back into development
. You don't want things that are in master
and not development
- things will get messy and confusing very quickly.
Once merged into master
, ensure you tag it to create a point in time to roll back to (I'll explain later). When you go live, ensure you checkout into the new tag so that you cannot patch live without going through the git procedure.
When you've gone live, I like to create a post in the wiki to document the new version and link the pull/merge request. It will be much easier to track what went live.
Why use the tag?
Tagging creates a point in time that is very easy to rollback to should something go terribly wrong on the production server. It also manages your visioning and nice to look back in time to see what went live when.
Conclusion;
- Your branching model is fine
- Make sure you open pull/merge requests before merging
- Ensure you tag your
master
branch
- Ensure you document the push to production (in the wiki)
- When patching (either hot fix or bug fix), ensure you create an issue to document the bug.
![enter image description here](https://i.stack.imgur.com/ETf2Z.png)
Best Answer
Summary: Vanilla Git Flow is pretty sane. For code that exist next to each other, use directories rather than branches. Feature branches should be short-lived, and don't introduce additional
develop
branches for each program and subject.For projects of a certain size – and your project is well past that point –, the “Git Flow” describes best practices for Git branch management. The central branch is the
develop
branch, which is used for integration of features. If you do continuous integration testing, this is the branch you test. Themaster
branch is always in a production-ready state and only lists previous releases.As an aside: the
master
branch being production-ready does not imply that the contents of themaster
branch will literally be deployed in production. Although it's sometimes used as one, Git is not a deployment system. Instead, themaster
branch describes the states of the project that can be used to create the actual deliverable. This (hopefully automated) build process can then ignore subjects, programs, or really any files that are not needed for the that build.There are now a couple of workflows that make up the Git Flow:
Releasing: When we want to release, we create a temporary branch from
develop
and perform release testing. Any work associated with releasing (such as minor fixes or bumping the version) can be committed on this branch. Once everything works out, this branch is merged intomaster
anddevelop
, and the merge commit onmaster
is tagged with the version number. Somaster
represents the current release,master^
the previous release, and so on.Development: Development happens on relatively short-lived feature branches. These are forked of
develop
. Once they are complete, they get merged back intodevelop
. If these branches are long-lived, it's a good idea to rebase the feature branch ontodevelop
on a regular basis in order to prevent large merge conflicts. Also, keeping features small is a good strategy to make merging more pleasant.Hotfixes: are not relevant here.
This is outside of the scope of Git Flow, but it can make sense to subdivide feature branches further, for large features that require the immediate collaboration of multiple people (this is not the default!). The sub-team working on this feature could treat the feature branch as if it were a local develop branch, and merge their own sub-features into this branch using the normal development workflow. Once the feature is ready, it would be merged into the main
develop
branch. However, this subdivision has certain dangers: The feature branch and the maindevelop
are likely to drift apart over time. This can be counteracted by having a liaison developer regularly merge the maindevelop
into the feature branch (which acts as the sub-teamsdevelop
branch). But when this mega-feature is merged into the main project, the impact for everyone else will be substantial and disrupt smooth development. Therefore, such over-complication should be only used as a last resort. It's preferable to have lots of small feature branches.If we try to follow the Git Flow, having 4 subjects × 4 programs = 16 develop branches is not recommended. Quite likely all of that shouldn't be in the same repo, but if you have to, just use different directories inside the repo. You don't need a separate branch for each topic (i.e. subject, program). Git Flow uses branches to keep track of multiple threads of development (in the case of feature branches) or to signify the status of the code (in the case of
develop
andmaster
).As an analogy: I'm storing a blog about cats and dogs in a Git repo. I do not have two long-lived branches
cat
anddog
where I write all posts about cats and dogs, respectively. Instead, I'd create a new feature branch for each post, but all cat-related posts are kept in thecat/
directory. Once the post is complete, it can be merged back into the main branch.