It is easy to use Git 'the wrong way' when transferring over from other styles
of version control.
Most old styles of version control (including what most people think in their
head) have a master-slave copy viewpoint. This assumes that there is a single
'master' (both the respository and its items), and every now and again one is
allowed to edit some small well defined item from the repository. It has been
that was since RMS Titanic was drawn on kaolin and linen drawing sheets. Often
it was only allowed to record the 'notice of change' (changeset) as the master
was too precious to be let out for any old minor correction. The changeset
implementation still exists in some tools.
That mind set is now outdated when it comes to computer files. Computer files
can be perfectly duplicated at essentially zero cost and protected (be
verified) by secure hash codes. The old problems that version control 'solved'
are not the problem any more, but the mind set still lingers.
Git was designed from the bottom up to be fully distributed using the secure
hash codes for content verification. There is no Master (there can be many
master copies)
So far so good. The other problem with the old system was the 'everything in
one big storage repo' philosophy (remember about the need to protect the
'master', so keep them all in the one safe zone). With Git, because hash code
verification is so strong one is now encouraged to keep each project in a
separate repo.
Git also allows, even favours, having many branches for the separate lines of
development (aka feature branches), which can be then merged back into the
master branch when each is ready. It sounds as if you may need to use these two
latter features so that independant project are placed in separate repos, and
then you can also run separate branches as required. You would push and pull
the relevant branches from your development machines (with working trees) to
your server (bare) as required.
Philip
- Original Message -
From: jayka...@gmail.com
To: git-users@googlegroups.com
Sent: Wednesday, July 03, 2013 2:05 PM
Subject: [git-users] Re: How to deal with concurrent changes in a project
Just to be clear:
- I am not using github
- I have set up a git server on a local machine. It works fine.
- I have a single repository on the server.
- There are currently 5 clients (mix of windows, linux and osx)
Thanks for the suggestions but they do seem to be quite complex given that
this surely must be a common situation. I'm much more used to subversion where
it's completely under the control of the user which files are checked in to the
repository.
Am I doing the wrong thing by having a single working directory on the
client? I did it that way because I have a lot of projects that are dependent
on a common set of libraries. So I'm treating the entire database as a single
mega project.
I just feel I'm using git in the wrong way. All the tutorials I can find
concentrate on simple examples so it's difficult to know.
--
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.
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3345 / Virus Database: 3204/6458 - Release Date: 07/02/13
--
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.
