Smoothing out local git experience with GH Sync

Something to think about later

The local git experience with GH sync is a bit annoying.

• commit locally
• push to GH
• deploy action runs to update app - great!
• deploy make another commit with updated state - trouble starts
• My local branch is now 1 commit behind origin, and is likely to come into conflict UNLESS I remember to pull

This is less of a problem if you're working on a branch - because you'll merge the PR and update main and never touch the branch again, so it doesn't matter that it's one commit out of date.

But in the GH sync v2 world, with long running branches and sandboxes, we might start hitting more friction here.

I have a feeling there's a solution in gitattributes. We should be able to set the merge strategy on those tracked files so that the remote is always favoured, and thus there's never a conflict.

Handling forked_from in openfn.yaml might be harder though. Another reason I think that openfn.yaml isn't working and needs breaking up into two files

Start by tracing the GH Sync deploy flow and how it updates the local branch, then inspect the tracked state files and the openfn.yaml handling mentioned in the issue. Review the proposed gitattributes approach and identify the required behavior for long-running branches; done requires an agreed, validated solution that avoids avoidable local divergence and conflicts.