Hi,
On Sun, Feb 7, 2010 at 2:06 PM, Matt Di Pasquale
<liveloveprosper@xxxxxxxxx> wrote:
> [snip]
> Also, is there an easy way to do something like this with a branch
> instead of a remote? Remote doesn't make sense to me conceptually (and
> I already have a remote repo setup that I push to from master).
I'm already doing this with branches. It's true that I used a remote
configuration, but the remote configuration ("[remote local]") says
that we're treating the local repository as the remote repo ("url =
.") and to "fetch" the dev branch (into FETCH_HEAD).
(btw, instead of '[remote local]' it should be '[remote "local"]'.)
I do this so that you can just type "git pull" without specifying the
branch, unlike when using git-rebase.
> Maybe
> I should have 2 different branches? One for dev & one for pro. How
> would I do that?
You should.
Your history for the two branches would look like this:
a---b---c dev
\
A---B---C pro
(if you're reading this in a non-fixed width font, pro branches off at "c".)
The commits in uppercase (A, B, C) are those that are applied onto dev
- for example, changing file paths, configuration, etc.
Let's say you've made some changes onto your dev branch. To update
your production site, you would rebase your pro changes onto the dev
branch (using the config and commands in the previous message), so
that you get this history:
a---b---c---d---e dev
\
A'---B'---C' pro
(pro branches off at dev's tip, "e".)
You have to keep in mind several issues. For example, if you're
updating file paths, when new files are added in the dev branch, you
need to update the pro side to modify the file paths in those files. I
was also assuming your dev branch fast-forwards cleanly, or else the
rebase fumbles.
--
Cheers,
Ray Chuan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html