On Wed, 16 Sep 2009, Todd Zullinger wrote: > 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. > Ahh, I've got you now. So we're not actually using the temporary branch, at least not directly. -Mike _______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
