On Aug 11, 5:30 am, Daniel Trezub <daniel...@gmail.com> wrote:
> I've just started using git last week, and I am still learning a lot. This
> means I am still messing with my trees a lot, too :)
> I am trying to mantain a Wordpress website. So I want to use git to keep my
> wordpress installation up-to-date, as described in this post
> I am using git in a private and offline repo.
> At the same time, I am developing mainly two plugins for this site. They are
> kept in the sub-dirs /plugins/feed and /plugins/site-list.
> What I did until now is:
> > cd /wordpress
> > git init
> > git add .
> > git commit -m 'wordpress 2.9.2'
> No problem here, until now.
> My question is regarding the plugins in development: what is the best way to
> track them inside this dir using git? I was thinking about making two dev
> branches, one for the feed plugin and another for the site-list plugin, so I
> can develop them separatedly. The problem is: I have no idea how I can keep
> my main wordpress installation up-to-date with the changes in both plugins,
> once they are tested and commited.
I would create two branches: "upstream" and "master".
"upstream" would receive wordpress updates (hence the naming) and only
them; "master" would be based on "upstream", would host the plugins
and would receive merges from "upstream" each time it's updated.
Something like this:
1) Initial setup:
$ git init
$ git checkout -b upstream
... roll the wordpress files in
$ git add .; git commit -m "wordpress X.Y.Z"
$ git checkout master
$ git merge -m "Merge wordpress X.Y.Z" upstream
2) Hack on plugins (being on "master"):
$ git add ...; git commit; ...
3) When a new wordpress release appears:
$ git checkout upstream
... roll the new wordpress files, check if some of them are new and
to be added, some of them disappeared and have to be removed using git-
rm etc, so
$ git add ...; git rm ...; git commit -m "wordpress X.Y.Z+1"
$ git checkout master
$ git merge -m "Merge wordpress X.Y.Z+1" upstream
Then go to step (2).
If you do not touch wordpress' files while hacking plugins (and you
shouldn't) merges are guaranteed to be clean.
Such approach is used when maintaining Debian packages in Git using
git-buildpackage: you keep the "debianisation stuff" on master and
each upstream release of the software being packaged goes to
"upstream" branch first and is then merged into master.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To post to this group, send email to git-us...@googlegroups.com.
To unsubscribe from this group, send email to
For more options, visit this group at