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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html