This workflow is great for things that are intended to be merged with
main. However, I think we have a lot of useful sandbox code that is not
intended to ever be mainlined, but is still useful and worth sharing.

On 09/02/2012 07:13 PM, Robert McGibbon wrote:

I'm just figuring out how to use git branches, and I think they might
be preferable in many cases to the sandbox system.

For example, here's a workflow that would work for Christian's work on
modifying Trajectory.py to load more flexibly.

|# create a new branch and check it out ;)
git checkout -b new-trajectory

[... make changes to files ... ]

git commit "awesome new features"

commit the new branch to github

git push origin new-trajectory
|

Instead of needing to create files like |Trajectory_crs.py| with new
names, you just edit the files in place and git does the work.

Switching between branches is really easy and takes no time at all.
Say you want to compare how your new code is working against the old
code, you do:

|git checkout new-trajectory
python setup.py install
[... test ...]

git checkout master
python setup.py install
[... test ...]
|

And then if you want to merge your changes into the "master" branch,
you can click the pull-request thing on github and then you get this
really nice GUI of where the code has changed, and people can comment,
etc.

—
Reply to this email directly or view it on GitHub
#15.

from msmbuilder-legacy.

Yeah, this is for working on new features.

I guess its an alternative to (1) just committing to the master branch and (2) doing it in the sandbox.

from msmbuilder-legacy.