branch strategy, har to follow commit history

[hakankvist]

It is currently hard to follow the code changes done since the history is "polluted" when the data is scraped.

To fix this I have some different proposals:

1. Create a separate git where the data is stored, this is perhaps the most clean separation.

2. Create a branch called "dev" or similar. All code changes are done on this branch and then merged to master.

3. The opposite to 2. Create a branch called "webpage-release" or similar. All code changes are done on master and then merged to webpage-release.

[PierreMesure]

Hi @hakankvist, good point! I must say I really enjoyed building it this way, there's a brutal elegance in trying to make your "infrastructure" as simple as possible, just a repo, a few scripts and an automation schedule... But definitely a barrier to understanding and there might be some side effects I haven't planned with commit inflation?

Anyway, I'm voting for 1. I think creating civictechsweden/JagVillHaVaccin-data is a good next step. I'd like to keep the commit history though, there's a wealth of information in the rate at which times are booked in each center and it's all saved in there. You can explore it through flatgithub.

I'm not sure how 2 or 3 would work, branches that merge regularly into each other necessarily share all their commit history so all branches would have all the data update commits.

[spacecowboy]

Regarding 1. you could also just have a data branch in this repo. The branch does not need to share history with the development branch. Carrying over the relevant commit history is no problem.

But, so not to break existing workflow, it migth be easier to the reverse, e.g. create a dev branch where the data-history is pruned away.

Then existing scripts could keep working and updating the master branch, while all code work is done on dev and merged to master when ready.