I've been using Git on projects by myself, creating branches to
work in, and then merging them into the 'master' branch and pushing
that to 'origin/master' in a remote repository. Now I've hired
someone to give me some help with a project and I'm wondering if what
I'm doing makes sense.
I want to handle merging their changes, so I've asked them to create
branches 'task1', 'task2', etc. They push those to remote branches
'origin/task1', 'origin/task2', etc.
When I want to test and deploy task1, I do
$ git fetch
* [new branch] task1 -> origin/task1
* [new branch] task2 -> origin/task2
I see they've actually pushed new code to two branches. I'll stick
with just the first task.
$ git branch task1
$ git checkout task1 # I know these first two commands could be combined
$ git merge origin/task1
Merge made by recursive.
app/controllers/bookings_controller.rb | 1 +
app/controllers/reviews_controller.rb | 5 +
etc, etc....
Then I do any migrations, run tests, and use the app to see if I like it.
If I do, then I
$ git checkout master
$ git merge task1
and if there are not collisions, then I can
$ git push origin master
and deploy with Capistrano.
Since I just created a stager, I'm thinking of deploying the 'master'
branch to the stager, where the client can bang on it a bit, creating
a new branch 'release', and occasionally merging 'master' into
'release', then deploying 'release' to the production server.
In the simplest model of one gatekeeper (me), is this good? Or have I
missed a trick?
Thanks,
Scott
--
SD Ruby mailing list
[email protected]
http://groups.google.com/group/sdruby
