Re: Adding non-bare branches to a non-bare repository

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/3/2011 4:53 AM, mail@xxxxxxxxxxx wrote:
My website is a non-bare git repository. I have a copy of the website for
testing purposes which is a separate git repository. Currently these two
repositories are not aware of each other, and I copy across files from one to
the other in order to bring features from the test repo into the live site.

I would like to make the testing repository into a branch of the live website
repository so that I can easily merge in changes from one to the other.

Both repositories need to be complete copies of files as they are web
accessible and must be functional.

Is this possible?

In future I also need to make a third copy of the site to have a beta as well
as an alpha testing copy of the website.

I recommend re-creating beta repo as a git-clone or linux copy (cp -r prod-repo beta-repo) so that beta repo shares the same history as prod-repo. If you have stuff on beta-repo not yet in prod-repo then tar it up and "re-apply" it to the "new" beta-repo using the "vendor branch" methodology described in the git-rm manpage. (do likewise for alpah-repo -- clone/copy it from prod-repo and apply beta-repo additional commits via method described below.)

You can create an "integration" repo to perform merges between the production repo and the beta repo (and alpha repo): (1) clone the integration repo from the production repo. this is important because it will cause the integration repo master branch to correlate to the production repo master branch which is the "real" master branch or "ultimate" master branch.
(2) add the beta repo as a remote to the integration repo.
e.g. (a) git remote add -t master BETA git:///url.to.beta
(b) git fetch BETA --no-tags
(c) git branch beta-master remotes/BETA/master
(this will track the master branch of the beta repo in the beta-master branch of the integration repo) (d) after initial creation of beta-master via (a thru c) you update beta-master with: (d1) git checkout beta-master
(d2) git pull BETA
(3) now you can merge beta-master into master and then push master to the production repo. i imagine that beta-master will always be built on master so the merge should always resolve as a fastforward:
(a) git checkout master
(b) git merge --ff-only beta-master
(b1) you should set production repo to deny non-fastforwards. see git-config manpage. (c) git push origin HEAD (assuming you leave the default name of the remote to the production repo as "origin")

For the alpha-repo you can do the same steps but point to the url for the alpha repo and call the remote handle ALPHA. Call the tracking branch of the ALPHA master branch "alpha-master" in your integration repo and merge it into beta-master. However, when you push beta-master to the master branch of BETA you will need to specify a specific syntax so it pushes "beta-master" to the "master" branch on BETA instead of creating a new branch called "beta-master" on BETA. Look at the git push manpage for the syntax.

Hope this helps.

v/r,
neal
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]