Mike McGrath wrote:
> On Wed, 16 Sep 2009, Mark McLoughlin wrote:
>> Merging the topic branch into staging is the same as doing the
>> working on staging itself, except the work is better isolated for
>> merging into master later.
>
> Because we have to pick which branch to send to staging. So if I
> picked branch 'mmcgrath' and luke picked branch 'lmacken' neither of
> them would end up being tested in our actual staging environment
> since we have to point the staging environment at a specific branch.
I think Mark's suggested workflow goes something like this:
# Want to test out some changes for, say, geoip
git co -b geoip-changes staging
# Work, work, work
# Merge to staging
git co staging
git merge geoip-changes
# Push to puppet1
git push origin staging
# Test, test, Test
# Looks good, let's get this into production
git co master
git merge geoip-changes
This makes it easier to do that merge, whereas merging staging into
master would involve cherry-picking commits most times. The trouble
with cherry-picking is that it just creates a new commit with the same
changes. You lose the commit-id which makes it harder to see just
what commits are on staging that are not merged into master and vice
versa.
For collaboration, sharing these topic branches is also trivial with
git. If both you and Matt wanted to work on the geoip-changes topic,
you can add each others's personal repos as remotes and share that
way. Or if you really wanted, that topic branch could be pushed to
the main repository for easy collaboration among everyone.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A fool's brain digests philosophy into folly, science into
superstition, and art into pedantry. Hence University education.
-- George Bernard Shaw
Attachment:
pgphgbasSDtdk.pgp
Description: PGP signature
_______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
