I have a project folder that has multiple duplicate files that are named slightly differently to create "backups". So I have "file1.txt" and "file1 backup.txt". Is there a preferred method to capture the old history when I make the folder into a git repository?
With out a lot of messing about, the simplest option is to just commit the full project folder as the first commit, then delete all of the backup files and finally commit your 'cleaned up' copy. That way you can access the copies of the old files any time you want, but they don't normally clutter up your working directory.
- Massaging Hunks: The Awesome Power of git add -p (p89).
Don't put them in at all! I don't know the exact way in Git, but in SVN you just don't add them to the repository. With a version control system you don't need another history - it just adds complexity.
You should alway commit to source control as soon as possible. Generally this is as soon as you have working code. The more often you commit, the less likely those other history files will be needed.
If you know what backups were taken when, you can do the following (manually
- Create a git repo and commit the first version of the file(s)
- Copy the next newer backup version of the file(s) over the original(s) and commit those.
- Continue until you're at the latest version.
Cons: takes a long time if you have many files
Pro's: you can draw your history as you seem fit. Multiple file updates can be in one commit, or each file can have its own commit to update it, and everything in-between. You get a clean, condensed, complete history and all the backup versions are stored neatly in source control. You can do exactly what @Mark suggests in his answer, but that's even more fine-grained than file/backup based commits.