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?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
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.
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
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.