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
restraint.
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 > 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
