Development Process
Once you have cloned the SORCER project, you will be developing Netlets (service-oriented scripts), Service Providers, Requestors and/or, Models in order to satisfy your computing needs. Your work should be done in a branch. This allows your modifications to be separated from other efforts, and also to ensure that the software you rely on does not change while you are doing your work.
Branching Strategy
Creating a branch in Git is simple:
git branch new_branch
That’s all that’s absolutely required (see the man page for all the options). And with that you now have a new branch to work on whose starting point is where you just were in your Git repository.
So what can you do with it? Or more to the point, what should you do with it?
We have two branches that always exist, master and dev.
master represents the most stable version of our project and you only ever deploy to production from this branch.
dev contains changes that are in progress and may not necessarily be ready for release.
From the dev branch, you create topic branches to work on individual features and fixes. Once your feature/fix is ready to go, you merge it into dev, at which point you can test how it interacts with other topic branches that your coworkers have merged in. Once dev is in a stable state, merge it into master. It should always be safe to deploy to production from master.
For a single developer, you can work on an experimental code path: You’ve got an idea about how a feature should be implemented and want to get started. But you’ve also got some regular devment that needs to take place at the same time (fixes, other features, etc.). So create a branch and code away:
git branch feature_x develop
git checkout feature_x
then add/commit... add/commit... add/commit
If the feature code works out, you merge it back into your development branch.
git checkout develop
git merge feature_x
If not, you just go back to the dev branch and delete feature_x:
git checkout develop
git branch -D feature_x
Actually, you really don’t have to delete the branch. You can leave it as is in case you want to easily go back to take a look at that work.
For a team, branches separate each developer’s individual updates. The distributed nature of Git sets up a default branch structure: Each repository creates a new branch in the extended repository network.
Check out the Git Branching Model
