Here's how I would approach this. Never work in master or release, only
perform merges in those branches. Never merge release into master. Instead
do all your work in topic branches branched off of master (never off of
release). When they're ready to test, merge them into release. When
they've been tested and are ready to be pushed out, merge the topic branch
into master.
I'm assuming, of course, that "release" is a
staging branch used to testing, not a branch that represents your
released versions (you might want to name it staging instead to make
this clear).
Tekkub
GitHub Tech Support
http://support.github.com/
Join us on IRC: #github on freenode.net
Discussion group: [email protected]
On Mon, Jun 1, 2009 at 10:10 PM, shenkin <[email protected]> wrote:
>
> Consider the following three (separate) scenarios:
>
> 1. Git is tracking a file in multiple branches. I want to code up a
> quick fix for a showstopper bug in the release branch, but don't want
> this change to ever be propagated into the master when I later merge
> the release branch into the master. (Assume that we will be making a
> far more robust and elegant change in the master when we have "world
> enough and time." As we all know, that's "after the release goes
> out.")
>
> 2. I add a new file to the release branch but don't want it be added
> to the master when I later merge the release branch into the master.
>
> 3. Git is tracking a file in multiple branches. I want to remove it in
> the release branch but don't want it to be removed when I later merge
> the release branch into the master.
>
> How are these best done?
>
> I have workarounds for (1) and (2), but not (3). For (1) and (2), I
> would do the merge into the master, then, for (1), edit out my change,
> or, for (2), "git rm" the file in the master branch, then commit.
> Hopefully there is a better way -- ideally, one that allows me to do
> something to prevent the later merge while I am still right there in
> the branch (i.e., before I forget about it).
>
> I don't see a workaround for (3). If I allow the merge to take place,
> an attempt to add a saved copy of the deleted file will create a brand
> new file, losing all history. Maybe there's a way to re-checkout the
> deleted file by referring to a previous tree-ish? That would be a
> workaround, and if you know how please tell me; but, s with (1) and
> (2), it would be much better to be able to avoid the merge of the
> deletion in the first place.
>
> Thanks,
> -P.
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"GitHub" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/github?hl=en
-~----------~----~----~----~------~----~------~--~---
