On Mon, Nov 23, 2015 at 3:19 AM, Matthew Leach <M.Leach@xxxxxxxxxxx> wrote:
> Hi,
>
> I was hoping that somebody could give me advice since I'm new to git.
>
> I'll be installing a couple of projects from github on our servers, and adding some features.
So you take source code from github and improve it...
>
> Should I create a repository on our server (e.g. in /opt/git/), add the github project as a remote, and create a branch?
You can certainly do that. Why would you want to keep it on your
server though? (Is it not worth to be open because it's highly company
specific stuff? Is it closed intentionally because it would reveal
core company secrets? Is it just for backup, because you don't trust
githubs uptime?) Having 2 remotes (github and your server) makes the
workflow slightly more complicated, but if you don't mind a
complicated workflow that's no problem. But be sure to know why/what
benefits you gain from that. You could also go with your github fork,
which could be set to private, I'd guess.
> Then on my local machine add our server as the remote and then pull / push with that?
Sure, sounds fine.
>
> On the server there will be two web directories: stable and dev. I was planning for these to be branches, and then just pull from the server repository using the local protocol.
Beware of that. There are quite a lot of servers serving the contents
of the .git directory, you may or may not want to expose the history.
(Certainly it looks odd)
For a private server I'd have the git directory somewhere non-public
(outside of /var/www, so maybe in the home directory of the git user)
and then a hook like this:
$cat .git/hooks/post-update
GIT_WORK_TREE=/var/www/your-stable-web-dir git checkout stable-branch
GIT_WORK_TREE=/var/www/your-dev-web-dir git checkout dev-branch
That's one way to do it. And outdated by now (as I just wrote down the
config I have in a personal server).
Git has learned a push-to-deploy[1], which should do what you want there, too.
[1] https://github.com/blog/1994-git-2-4-atomic-pushes-push-to-deploy-and-more
>
> I think it would mean sorting out merge actions on the server. I'm hoping to be able to fetch and integrate updates from the developer's github repository, but without making things more complicated than they need to be.
>
> Does anyone have any suggestions? I drew a diagram if it helps (https://drive.google.com/file/d/0B7JhUXLbxPT9RkVNMUV6cjJNVnc/view?usp=sharing)
As said above, what exactly do you solve by having yet another line in
the diagram (with /opt/git/proj.git) ?
You can directly pull from github to the local developers workspace
(and sort out merge conflicts there)
and then push to deploy from the workspace, too.
If you need a place to share for just the subset of people in your
company, you could use the /opt/git/proj.git for sure, but you'd
pull&resolve merge conflicts to your workstation and then push for
sharing to your server.
(Also think about external hosting solutions, if they make sense there)
If you dislike the push-to-deploy approach (not everybody should be
able to push a new version, only a subset of people should be able to,
that should also work the same way as you would restrict the "pull
dev" and "pull stable", I'd guess)
--
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