F# doesn't really do anything that C# cant. They all ultimately compile down to the same CLR so there is no single technology that would be amazingly useful to you. You can even call F# from C# and vice versa.
Depending on the problems your designing F# could provide simpler and more concise code.
Functional languages also lend themselves very well to unit testing. That and that fact that there is much less mutable data means your code if written well will have much less bugs.
I can say from personal experience learning some F# can really improve your C# skills and help you think of problems in a new way.
Learning functional programming concepts can also really help your Javascript (which is itself a functional language).
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.
Best Answer
I think your idea of cloning your template is best. But you can tweak that by using GitHub or similar site.
With GitHub you would fork for each new project based on your template.
The fork would create a brand new git repository but based on your template.
Now if one your projects has an update you would like picked up in your original template repository, you could submit a pull request to the original template. Others could too, if you wanted to share.
Then you would simply accept the pull requests you found that you want to incorporate into your original project.