In addition to what Dale said, I have some basic questions.

Do the developers have a unique UNIX UID which is tracked as the "owner" of 
the files in the JEE subdirectory? If so, then perhaps the simpliest thing 
to do is to stop using a "git add .", but instead do something like:

git add $(find . -uid $(id -u) -type f | egrep -v '^\.\.git/')

You could simplify the above by enclosing it in a shell script. What it 
does is scan the directory looking for file (-type f) belonging to the 
executing user ( -user $(id -u) ). It puts all those files into the add. 
Which is overkill, but doesn't cause any problems.
Doing this means that the git add is only done on files owned by the 
executing user. Then do the git commit as you currently do.


Note that I agree with Dale that this is not "goodness". But it does 
directly address the question asked. What you might do is more like what 
you indicated you wanted. Make a bare repo which is your production repo. 
Have each developer do a git clone from it. Now, instead of doing their 
thing in the master branch, have each do something like:

git clone url-to-production-bare-repo
git checkout -b my-name #Replace my-name with the user's real name or logon 
id maybe
# develop in the "my-name" branch.
# Now I want to commit!
git fetch #get any updates in the bare repo.
git checkout master #switch to the master branch
git merge  my-name #merge in my changes into master
git branch -d my-name #wipe out my-name branch
#git tag some-unique-name #may want to do this so you know where you're at
git push #push updated master up to the bare repo
git branch -b my-name #and reinstate my-name branch

We don't use Tomcat, but we have a test / quality assurance / production 
level of testing. At this point, someone, perhaps the developer, would go 
into the "test" subdirectory and do a "git pull" to merge in your just 
pushed changes. I don't know your environment, but you might even want to 
do a "git tag" before you do the "git push". Once things are checked out in 
test, then you could do a "git pull" or "git pull some-unique-name" to move 
your changes to QA. This allows someone to git push into test and you can 
still only merge in your changes to QA. Repeat for production from QA.

You could have 3 Tomcat instances running on the same box simply by using 
different ports for each. You could even allow each developer to have a 
Tomcat instance on their desktop (Linux or Windows) by pointing that Tomcat 
instance to their individual developer subdirectory (whether local to the 
desktop or NFS/Samba mounted from the Linux server). I can't think of any 
reason not to have a Tomcat for each developer for their own testing. I 
would hope you don't upgrade Tomcat often. And they could even run using 
the same Tomcat run-time directory so they don't need to maintain their own 
Tomcat executables.

Just some weird thoughts on how I would approach the problem. Not 
necessarily the best, but I think workable.

On Sunday, January 27, 2013 2:18:18 AM UTC-6, wrote:
> I have a git repo installed in my unix for version tracking our JEE 
> website.
> I have currently run into issues not in the usage of git but the way in 
> which I am suppose to use it which is explained below.
> I work in a team of 3 developers which contribute to the website 
> development.
> Initially when I installed Git in our server I directly created a repo of 
> our webapps directory which contains the actual work files and ran into the 
> foll problems.
> 1)While committing the changes into the repo one of us would genrally do a 
> git 
> add . and commit it to the repository which would commit not only the 
> files the commiter changed but would also commit the changes of other 
> developers.
> When we faced this issue we decided that we needed to create separate 
> non-bare repos for each one of us in the same server in different 
> directories which would house the entire code.The basic work stucture we 
> are following is hown below:
> <>
> As shown above in the image we have created a bare repo which would have 
> the website contents pushed by the webapps which in the image is the Work 
> Directory.
> The basic workflow here is:
> 1) Create n number of non-bare repos for each and every developer.
> 2) Get the entire website work files from pulling from that bare repo
> 3) After making changes to our own repo push to the bare repo
> 4) The bare repo being configured with a post-receive hook would actually 
> update the Work Directory.
> This setup is working fine but we are facing a lot of issues as shown 
> below:
> 1) Each developer having his own contetnts in a separate directory is not 
> able to test the code before pushing it to the bare repo which would update 
> the Work Directory- Coz of these steps even for say one jsp file change I 
> end up doing 20 commits until it starts working properly without bugs since 
> we have tomcat pointing to only the original work directory.
> This has become the most troubleseme issue here.
> How can we improve this scenario where using GIT in out prject seems 
> benefitial.
> Can anyone suggest any ways for improving the same.

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

Reply via email to