Re: A basic question

[James Nylen <jnylen@gmail.com>]

On 10/11/2012 1:38 PM, Jim Vahl wrote:
> For the sake of argument, I'll assume that a committing a change implies
> that the file has passed the testing process.  So my questions are:
You should not assume this.  You / your developers should commit far 
more frequently than you test and release versions.  For example, I 
usually try to commit after a day's work at most.

Instead, you should mark a tested version using tags (the git tag 
command). Here is a workflow that seems like it would work well for you:

1. Commit 1
2. Commit 2
3. Commit 3 - TAGGED as release-v0.1
4. Commit 4
5. Commit 5 - TAGGED as release-v0.2
6. Commit 6
7. Commit 7

In this scenario, you reviewed the code after Commit 3 was entered and 
it passed your tests.  You then tagged this version of the code as 
version 0.1.  Tagging is just a convenient way to associate a name (for 
example, "release-v0.1") with the code tree as of a certain commit.  
Similarly with Commit 5 and version 0.2.

Commits 6 and 7 represent changes made to the code for features that are 
in progress, bug fixes, etc.  They have not been reviewed yet.  For the 
purpose of releasing versions, you don't care about these commits.

For the purpose of releasing versions, you also don't care about the 
state of files in the git repository (whether they are modified, or some 
or all changes are staged).  These features exist to help you prepare 
commits and understand what changes you are committing, not as a way of 
managing versions of the software.

Many people use git in more complex ways that involve non-linear 
development histories (branches).  For example, you can have multiple 
developers working on different features simultaneously, each committing 
their own changes, and you can use git to help you reconcile the changes 
later.  You can also have a "release" branch which stores only the 
released versions, and separate "development" branches where code 
changes occur.  These workflows are harder to wrap your head around, though.

> 1) Does git have a built-in way to get a list of all of the "most recently
> committed" files only at a given point in time, thus automatically recording
> the revisions of all of the component files of a release?   This implies
> that for files which are being modified or which have been staged but not
> committed, that git would go back to find the "predecessor" file which had
> been committed.
Let's replace "committed" with "tagged as a released version". Then 
yes.  The person who wants to release a version would do:

git checkout release-v0.1

At this point their working folder will contain all of the files for the 
v0.1 release.  You can run tests, run the build process and generate 
executables, or whatever other kind of deployment process needs to be done.

Another option is to create a zip file containing all the code as of 
version 0.1:

git archive release-v0.1 -o release-v0.1.zip

>   2) Does git have a way of creating and exporting a list of the "most
> recently committed" files only?
There are many ways to list and manipulate the files stored in the 
repository, as of any commit that you want.

> 3) If the answer to the above questions is "No", then what is the normal way
> for a programming shop which is using git to extract/assemble the list of
> approved files for building a release?

The first step, which git will help you with, is to ensure that you are 
working with the right version of the code and development files (the 
version you tested, that you intend to release).  From there, extracting 
and deploying the files necessary for a release is up to you.