Thank you, I did try this but I was confused ...
The files are on the server, these are the production files .. they have to
be there or there is no website ... so can i still use a bare repo? My
understanding of this is that a bare repo simply has the history info
(branches, commits, etc) .. but it does not store the files .. is this
correct? Then is the idea that the developers make changes locally, commit
and push, but then simply FTP the files? Is that how it works with a bare
repo? How do the files get there and what would push do for a bare repo?
On Fri, Jun 28, 2013 at 11:22 AM, Gergely Polonkai <gerg...@polonkai.eu>wrote:
> if I was you, I would use a bare repository on the server side. This will
> render the server's repository unreadable for the human eye, but the
> server-side merging would become unnecessary. To do this, create a new
> directory on the server, and issue the command
> git init --bare
> in it. After that, simply `git push` into it from your local machine, and
> tell your developers to use that repo from then on (or overwrite the old
> plain text repository with the new, bare one).
> Again, you can only do this if you don't need the source files to be
> present on the server, or you can clone it to a separate directory to
> access, test or serve them.
> On 28 Jun 2013 20:14, "HWSWMAN" <ed.pat...@gmail.com> wrote:
>> Ok, I want to start over after having spent a few hours trying things
>> Here is my situation ... I need to use GIT for some source control .. i
>> have never used any source control before and I want to use it in the
>> simplest possible way first, to get running, and have some version control
>> going on ... i have a very small team of only a few people, but in
>> different locations.
>> I read some stuff and this is what I am planning on doing, please tell me
>> if this makes sense:
>> - I went on the server and used "git init" to create a new repo
>> - added some files and directories, and commited them from the server
>> - i installed and opened GIT GUI, simple and free, this is what i
>> want ... i cloned the repo to my local machine ... all good
>> - now my understanding is that on the server is the master branch, so
>> all the developers who develop locally on their machines, should create a
>> branch so that they can push ... i created a branch on my machine called
>> <company>-<name>-<desc>, I will recommend all the developers to do this
>> - I made some changes to files in the repo, staged, and commited ...
>> all good ... i also pushed and no issues ...
>> - Now I notice i have to go to the server to merge the changes so the
>> files actually show up on the web server ... worked fine ..
>> - So the idea is, since this all worked, that i would tell the
>> developers to (1) clone the repo (2) create a branch to work out of (3) do
>> their development and stage and commit changes locally, then push to the
>> server ... (4) then they should tell me they need me to merge the branch,
>> and I would ask for the branch name ... i would then go to the server and
>> merge the changes
>> - Does this all sound good so far? Will it work fine? ...
>> - Now if yes, if there is an issue, how do i roll back a change? ..
>> can i simply issue a command on the server, and have the files roll back
>> the state before the last merge? How do i do this?
>> Otherwise please let me know if this is not right in some way how i am
>> thinking ... note i do not care if i do not have the 110% most optimal way
>> of doing things, i just need a simple method to have some control, and some
>> tracking for now .. this seems to work and i just want some verification ..
>> i am sure more experienced users have suggestions as to how to make this
>> better/smoother/more efficient, and I welcome that too, but please do not
>> just say i am "wrong" because you know more than i do and you know a
>> fancier way .. what i want to know is if this above is reasonable, and if
>> it will work for basic tracking and control of source files ...
>> Thank you
>> You received this message because you are subscribed to the Google Groups
>> "Git for human beings" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to git-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
> You received this message because you are subscribed to a topic in the
> Google Groups "Git for human beings" group.
> To unsubscribe from this topic, visit
> To unsubscribe from this group and all its topics, send an email to
> For more options, visit https://groups.google.com/groups/opt_out.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/groups/opt_out.