Refter to: http://stackoverflow.com/questions/315911/git-for-beginners-the-definitive-practical-guide/5968622#5968622
Workflow example with GIT.
Git is extremely flexible and adapts good to any workflow, but not enforcing a particular workflow might have the negative effect of making it hard to understand what you can do with git beyond the linear "backup" workflow, and how useful branching can be for example.
This blog post explains nicely a very simple but effective workflow that is really easy to setup using git.
quoting from the blog post: We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state:
The workflow has become popular enough to have made a project that implements this workflow: git-flow
Nice illustration of a simple workflow, where you make all your changes in develop, and only push to master when the code is in a production state:
Now let's say you want to work on a new feature, or on refactoring a module. You could create a new branch, what we could call a "feature" branch, something that will take some time and might break some code. Once your feature is "stable enough" and want to move it "closer" to production, you merge your feature branch into develop. When all the bugs are sorted out after the merge and your code passes all tests rock solid, you push your changes into master.
During all this process, you find a terrible security bug, that has to be fixed right away. You could have a branch called hotfixes, that make changes that are pushed quicker back into production than the normal "develop" branch.
Here you have an illustration of how this feature/hotfix/develop/production workflow might look like (well explained in the blog post, and I repeat, the blog post explains the whole process in a lot more detail and a lot better than I do.
-----------------------------------------------------
Silence, the way to avoid many problems;
Smile, the way to solve many problems;