Re: A basic question

From: James Nylen <jnylen@gmail.com>
Date: Oct 11, 2012, 18:40 UTC
Message-ID: <507712AC.7090801@gmail.com>
In-Reply-To: <002801cda7d7$4792c260$d6b84720$@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.

Show 6 quoted lines

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