Let me try to clarify, as I agree, the reasoning is important to making the 
right decision.

For one, let me say that the application is an ASP.NET Web Site (as opposed 
to a Web Application), so it's not like a traditional compiled project 
where I can put code in the project that is not accessible in the release 
version.  For example, in a traditional project I can create a class, but 
as long as I don't call or reference that class in production, 
user-accessible code that class will never be run in a production 
environment.  In a Web site if I have the markup and code files on the 
server then it will be compiled during the site's run-time compilation and 
could potentially be discovered and accessed by users.  So NOT having these 
files on the production server is the most secure option.

Having said that, the types of files can be grouped into a few categories: 
admin tools and prototypes.  So there is a subfolder on the site that is 
called "admin_tools" and it has several administrative tools that we ONLY 
want on the internal development server.  These files tend to data 
management tools that we allow internal, non-developers access to update 
data associated with the site.  These tools we DEFINITELY don't want 
discovered on production, as it would allow users to update data without 

There is also a folder called "prototypes" where we may prototype a feature 
(again, on the internal development server for employees only) that we want 
to proof-of-concept.  It has merit on the internal development server and 
the prototype may evolve over time by various developers (hence the desire 
for being in the repository) but since they are not fully fleshed features, 
discovery by a user could again be disastrous to the site.

Does this help to answer your question?

I should also clarify how our development process is planning on changing 
with Git being involved.  Currently our development process looks something 
like this:
1. Developers access code directly on Test server to make changes
2. Testers look at site on Test server to validate changes
3. Developers push code to Production Server 
4. Testers re-validate changes just after code publishing

With Git involved the plan is to do the following:
1. Developers alter code and test on their machines and push stable changes 
to repo
2. Several times a day the code from the repo will be updated to Test 
server and Testers will validate code changes
3. Once the Test server code is stable and ready for production use, the 
code will be tagged and pushed to a Staging server
4. Once the code is re-validated on the Staging server, the code will be 
scheduled and updated to the Production server

Again, hope this clarifies some of our processes and reasoning and allows 
you to help me more effectively.  

On Wednesday, June 10, 2015 at 9:42:26 AM UTC-7, Konstantin Khomoutov wrote:
> On Wed, 10 Jun 2015 09:29:04 -0700 (PDT) 
> David VanKirk <kri...@gmail.com <javascript:>> wrote: 
> [...] 
> > That being said, I'm not sure the best practice for getting our 
> > existing code into Git.  We currently have a Test server and 
> > Production server, so we have two copies of the code and the 
> > developers access the code directly on the Test server and make 
> > changes there.  Because of this, we have code files on the Test 
> > server that I want in the repository, but in most cases I do not want 
> > these files to ever make it to the Production server.  So on to my 
> > actual question, how can add ALL the code on the Test server to the 
> > repository, but only have a subset of that code identified to deploy 
> > to the Live server? 
> > 
> > I've thought about making the Test code the master branch and 
> > creating a "production" branch where the Production code subset would 
> > live, but when i think through the process of merging master changes 
> > into the production branch it would see that, without a ton of 
> > effort, the "test-only" files would come along for the merge, which 
> > is not desired. 
> What do you mean by «"test-only" files»? 
> Here's why I'm asking: A complicated project usually undergoes certain 
> code churn which produces a number of commits, each or which is 
> "imperfect" in the sense the state of the project at it can't yet be 
> sensibly used in production.  At some point, the code base stabilizes 
> and the process resolves in a commit which can be deemed as fit for 
> production usage.  (More complicated project might involve several 
> stages for this, like forking a stabilization branch at some point and 
> only allowing bugfixes on it, and hence the production version is cut 
> from that branch.)  The key point here is that "imperfect" history 
> leads to a "perfect" commit.  And so here's my question: do you refer 
> to the contents of the commits from such "development" history as "test 
> files"?  Or do you wanted to tell that developers create on the test 
> server some files which exist on the filesystem only during development 
> and must not exist on the filesystem on the production server? 
> That's a crucial difference, and hence I'd like to see some 
> clarification before we move forward. 

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/d/optout.

Reply via email to