On Apr 15, 2013, at 3:45 PM, Yannick Spill yannick@salilab.org wrote:
> Could you tell us a bit more about git flow? Do you want to use this dev scheme? I use it a lot and plan to use it for managing patches once we have a release. And I would like to move towards a somewhat more controlled commit process, although how to do this well isn't at all clear to me. In general, I think I currently recommend the following strategies - if you are making a bug fix that will go into develop as well as patch the last release, use a git-flow hotfix branch. I would like to get to doing some sort of code review on such things, but that requires a lot of changes to how people operate. - if you are making a small change that is self-contained and you will finish before you move on to anything else, just commit to develop. This is particularly true if it is to a module you control. - if you are making a large change that, for example, touches a bunch of files or will not necessarily be finished before you would like to work on something else IMP related, use a git flow feature branch - if you are making a change that you would like to share with other people before it is committed into develop (eg to get them to check it doesn't break anything, or to test it as you are developing it), use an imp-flow feature branch. -if you are developing a new module or other large body of related code, create a new module in another repository and develop it against the release version of IMP
Using a branch (feature or hotfix) allows changes to be shared and inspected more easily. I'll update the wiki with the above ideas.
> and when do we need to run setup_git.sh ? After you clone the git repository. Running it multiple times is harmless.