Akira: Create the git backend for akira files

[Philip-Scott]

Expected Behavior

We want to give the users a way to move back to previous versions of the file without any external tools.

Possible Solution

@albfan said we can use libgit2 for this without having to require the use of git commands!

[Philip-Scott]

So here's an interesting side effect, @Alecaddd do designers use Github at all? it would be interesting if as a designer you could "push" your changes to a git repo online and doing so pushes the unzipped version of the Akira files :thinking: You could also "clone" projects as well but doing things such as deleting all the history of the file wouldn't be possible any longer when pushing to git

[Alecaddd]

As far as I know, whenever I talk with a designer about Git or opening the terminal, they start shaking :smile:
Jokes aside, I'd love to use this approach for the future Akira cloud.
Basically, allowing users to sign up to create an account on a server that will generate a remote repo and hook up its origin to the local git repo of any file saved by that user.
Offering a UI to do a remote git push to have your files saved in the cloud with all your history of saved states.

[abienz]

I've been using Abstract with a group of designers recently (https://www.goabstract.com), it's been an interesting workflow using it, but ultimately has brought more frustration than managing a regular file-system.

• The primary issue is we've had is lots of conflicts, this is strange because we don't even work on the same branches/files.
• The conflicts often occur when a new version of Sketch and/or Abstract is released and not all designers are on the same version.
• It's extremely slow, we have complex files and some of them quite large with images and fonts imported I'm sure this adds overhead, this means that when you use Abstract you're often waiting for the UI to catch up and process the files.
• This brings me onto my final point that it's a non intuitive workflow for designers, you can open files untracked, but that's just for viewing really, but everything starts with you having to create a branch and name it before you can work, then you have save your file, commit the changes with a comment, and then merge back into master and hope you don't get a conflict.
  
  
  
  • Ok as I wrote that I realised that I've just explained the same workflow that anyone using Git goes through, but take this from the perspective of a designer that is forced to use a UI, all that clicking and wading through windows and popups!
  
  
• Oh and one more is you don't really know where the files are stored on your machine, it's all handled by Abstract in their Library, so if everything goes wrong you don't really have a handle on your local copy.

Abstract has some great features too, such as preview, collections and inspect mode, but I wanted to highlight the problems with a git based solution here.

Another design tool I have used with version control is Atomic (atomic.io) I'm not sure if you can still use it as they've grandfathered their tool to create something else, let me know if you need screenshots as I still have an account.

Atomic is another cloud based design-in-browser prototyping tool such as Invision and Figma (More like Figma).

Atomic handles version control by having a special scroll bar at the bottom of the screen that steps back through time as you drag the slider to the left. I never interacted with this feature much, it was like an interactive undo function, but if you could create 'milestones' or branches with it, I thought it would be quite a useful tool.

Hope you find this helpful.

[Philip-Scott]

@abienz Thank you for sharing your experience! Since it's going to be an in-file git repo, i don't think we would hit the problems with conflicts, since you wouldn't be "merging" anything. But you bring a good point with having to deal with conflicts within the app in a way that's user friendly. conflicts with just text are a pain, so i can't imagine how bad it could get if we don't do it properly.

I'd imagine that our "conflict resolution" could be having a side-by-side of the two files, so you could move things from each other and keep the one you like.

We also need to think if we would give the normal user full "git" power (Branches, merges, diffs, tags, etc...) or just make it like a timeline (one branch only, and only commits) to keep things simple for the user

[abienz]

@Philip-Scott Yes good point, the issue here is to create a git backend for akira files, but will the frontend need to reveal all functionality to the user?

[Alecaddd]

I think users shouldn't be even aware that a Git repository is inside the saved file.
The experience must be seamless and designers shouldn't worry about git, merging, creating branches, etc. As @Philip-Scott said, in case of merging issues, we will need to offer a visual interface to select which version of the file to keep.

As a first version, I'd say we should only focus on one single branch, doing commits at every save, and allowing users to visually see the history of commits to revert back to a previously saved state.

The wording is also very important. We should avoid to mention git, or rebase, or commit, or head reset, or anything like that. These are all alien terms for designers and we should avoid them at all cost.