-1

We're just starting to use git for source control on a multi developer website.

At the moment we've got a bare remote repository which we can all get a clone of and develop. Fine.

But we have to fetch another clone of the remote to give us the source code to actually upload to the webserver.

If our remote repository wasn't bare then it would contain working files - like our clones do.

As I understand it these would be from when the repository was created.
What I can't work out is how to update these 'working files' from the remote repository itself because then we could run against that directly.

I hope that makes scene.

I'm either missing something about how this all works or how I'm using it but I can see what!

CodeWizard
  • 128,036
  • 21
  • 144
  • 167
bigfatfrog
  • 59
  • 9

4 Answers4

0

Your remote repository should remain a bare repository. Working files on the server don't make sense. There is no developer working directly on that machine. Yes there are more steps to modifying the remote repository in git and that is by design. Don't try to skip steps in the process for convenience.

Sammy
  • 467
  • 3
  • 13
0

What is bare repository

As described the bare repository does not contain any regular files in its root directory. Instead there is the .git folder content instead.

How to update the code files

What I can't work out is how to update these 'working files' from the remote repository itself because then we could run against that directly.

If you want to work on the files and modify them you have to clone the repository with git clone.
Its not enought to run git init --bare on your servers, you need to set up some transfer protocol in orrder to "talk" to the server.

Once you have the repo and teh transfer protocol you can simply clone the project , modify its content and tehn commit and push back to the original repo.

Community
  • 1
  • 1
CodeWizard
  • 128,036
  • 21
  • 144
  • 167
0

As a first step, you could recreate your repository on the remote or make it non-bare directly, as in this answer. Once you have a non-bare repository, you could create a post-update or post-commit hook to run git reset --hard HEAD. That being said, this is a bad idea. You should read the following post before you decide to go ahead and to this: Git: how to make remote directory update when pushed to?

Community
  • 1
  • 1
Mad Physicist
  • 107,652
  • 25
  • 181
  • 264
0

What I can't work out is how to update these 'working files' from the remote repository itself because then we could run against that directly.

I'm either missing something about how this all works or how I'm using it but I can see what!

No, you've got it. You can't update a Git repository remotely.

It's a common desire to want to use Git to push changes directly to production. You can't and you don't want to. Why? Consider what happens if the production copy has uncommitted changes or there's a merge problem? Broken production.

Instead, the production clone needs to be updated from the production server. Because a git pull can involve a merge, which if there's a conflict can break production, ideally instead of pulling it should git fetch and then checkout a tagged release. This guarantees no merge conflicts and you know exactly what you're getting.

In general, don't try to use Git as a release manager. It can be part of a release manager, but it doesn't work well as one by itself.

Community
  • 1
  • 1
Schwern
  • 153,029
  • 25
  • 195
  • 336