Merging from staging to master

[Mike McGrath]

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