Jason Garber wrote:
Hello,
Time is valuable, so any of it is appreciated. I'm looking for sound
advice on a good strategy for maximizing git's branching and merging
capabilities to assist us in frequent web-app deployments.
-- I am running a project (in git) that has ~20,000 source files and
several full-time developers making changes constantly. The project
is a web-app, so the files are a mix of textual source code and
(usually) small binary files.
We were using Subversion for some time, but eventually the
deficiencies (like "svn status == 90 seconds" and no merge tracking)
caused me to look for a better solution. After a lot of research, I
ended up here, and we are in the process of moving all of our
projects to git. Thanks, by the way!
We have always maintained three copies of each project -
[Development, Preview, Production]. Changes were typically made in
Development sites and tested. Then (manually) copied to the Preview
sites and tested. Finally, they would be manually copied to the
Production site.
It becomes very difficult to tell (manually) who changed what line of
what file for each task that needs to be moved into Production. Some
tasks are long-running, some are short, but in general, it's a mess.
This is quite different from traditional software development where
releases are done on a more "predictable" basis. Unfortunately in
our case, releases are done on a sub-daily basis (yes, I'm working on
that). We need a lot of agility in whatever strategy we choose.
-- Here are some requirements: - Separate change-sets. Keep track of
the changes introduced by each task separately. - Have changeset ABC
stay in the Preview level for a variable amount of time. - Create,
Preview, and move to Production changeset DEF while changeset ABC
sits in the Preview level. - Developer sanity :)
Here are some intents: - To maintain a branch called "Production"
which represents what is in production - To maintain a branch called
"Preview" which represents what is being previewed
Any help is greatly appreciated.
It sounds like you could use the following strategy:
Have a primary Development branch. When a developer needs to add a
feature, he forks a "topic branch" from Development, and implements the
feature. When the feature is complete and tested, the topic branch is
merged back into Development. Since forking and merging is one of git's
strengths, it should be quite possible to have multiple "topic branches"
in progress at any one time, obviously modulo interdependencies.
Once the Development branch has been tested with all the merged topics,
the Development branch can be pulled/pushed into Preview for further
testing, and finally pulled/pushed into Production.
The machine used for Preview could have its own copy of the git
repository, as could the machine(s) used for production. Just make sure
that they are configured to not serve the .git/ directory.
Hope this helps.
Rogan
-
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
