On Fri, Jun 28, 2013 at 11:14:06AM -0700, HWSWMAN 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
As others have suggested it's better to use `git init --bare` when
creating the repo on the server.
> - added some files and directories, and commited them from the
> server
This step is rather unnecessary, once the repo exists on the server it
can be checked out and you can do all the work on your development
machine.
> - 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
No! The master branch is in *every* clone, not only on the server.
You may decide to use the server repo as the *master repo*, or blessed
repo, or whatever you want to call it, simply it's the one central
point where you always can turn to get the current, up-to-date source.
> - 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 ..
This is where my comment about Git not being a deployment tool comes
in, and where the point about using a bare repo clarifies things:
Pushing to a non-bare repo *will not* modify the checked out file
in that repo!
By using a bare repo on the server you avoid falling into the trap of
thinking about the server repo in the wrong way.
> - 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? ...
No, I would organise it as such (for the sake of argument I'm assuming
you are developing a web application):
- bare repo on the Git server
- each developer clones the bare repo from the Git server, do their
development, and push back to the Git server
- you clone the bare repo from the Git server onto the web
application server, and pull in changes when they are ready for
deployment
(the Git server and web application server can of course be the same physical
machine, even served by the same httpd server, but the central Git repo and
the web application should not live in the same folder on the file
system)
This is the basic flow, you then need to add details regarding
branching on top of this.
> - 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 to the state before the last merge? How do i do this?
In the repo on the web server you can simply roll back to a specific
point using `git reset --hard <ref>`.
/M
--
Magnus Therning OpenPGP: 0xAB4DFBA4
email: mag...@therning.org jabber: mag...@therning.org
twitter: magthe http://therning.org/magnus
Most software today is very much like an Egyptian pyramid with
millions of bricks piled on top of each other, with no structural
integrity, but just done by brute force and thousands of slaves.
-- Alan Kay
pgpX5ZFboSSDE.pgp
Description: PGP signature
