It would be simple to just create a repository from the most recent
archive and work from there, but how do I include the history of
changes?
Pretty easy. There are two ways to approach this depending on how clean the codebase is from one ZIP archive to another: Cumulative UnZIP Commits or Clean Up After Each Commit.
Cumulative UnZIP Commits: UnZIP, Commit, UnZIP another, Commit Another, Etc…
The solution is to first create a git repository based on the oldest archive, commit it, then add the subsequent/progressively-newer stuff, commit that and so on and so on. So for example, let’s say you have three archives that are named/dated as follows:
archive_20150801.zip
archive_20150804.zip
archive_20150806.zip
Now I would begin by unZIPping archive_20150801.zip
and creating the initial git repository based on that. Then I would unZIP archive_20150804.zip
and drag/copy—or just unZIP in place—so that stuff overwrites the older archive_20150801.zip
and so on. Ditto with archive_20150806.zip
.
Clean Up After Each Commit: UnZIP, Commit, Delete, UnZIP another, Commit Another, Delete Another, Etc…
But if you want to be extra accurate in your merging of newer files with older files in each ZIP archive, I would recommend doing this:
- UnZIP an archive and commit it.
- Then after that commit is done, manually—not via
git rm
—remove all the files from the directory that contains the repo. Be sure not to remove the git-specific stuff like .git
, .gitignore
and such.
- With that done—and a relatively empty directory in place—unZIP the next archive and place it’s contents into the git repository directory.
- Now with new files in place do a
git add -A
and do a new commit.
- With that done, go back to step one for the next ZIP archive you wish to add to the mix.
The benefit of that “commit stuff, delete stuff, add new stuff, commit new stuff” method is you won’t end up with stray files that might have only existed in an early version of the code in the final repository. Each commit is a pure reflection of what that ZIP contains and not a cumulative pile of files and directories expanded on top of each other.
Keeping Commit Dates Straight
As for keeping some semblance of a date/time history, you can do some fancy footwork and force actual git commit dates to conform to actual archive dates as explained in this Stack Overflow answer. But I personally find that overly complex and risk-prone; I prefer to keep tasks like this as simple as possible. Instead I would set a commit message that clearly states what each commit is like:
Commit of 2015-08-01 ZIP release archive.
That way you can easily know what the source of the archive commit in the future by just browsing the commit comment history.
I’ve done this myself for old archives I managed via this old-school, “copy-the-directory-and-create-an-unmanaged-ZIP-archive” method and it’s a pain, but it helps in the long run to retain some semblance of a coding history for a project.