Using version-control to collaboratively work on Penpot

Hello Penpotters :smiling_face:

The use of SVG as a format for Penpot files opens the door to a topic that is very close to my heart. Developers and designers often work together, and this close collaboration gives us the invaluable opportunity to get to know (and borrow!) each other’s tools.

It was love at first sight for Git, and there are at least two things that as a designer I find extremely useful and would like to have in my Penpot:

  • Having access to the history of a graphic document (and of the single components). This has already been partially implemented with the History panel. Is there a plan of further development for this feature?

  • Working with a “framework” similar to that we use for development. I am referring in particular to pull/merge requests, the creation of different branches and the test and review system while keeping somehow a trace of the contributions.

I don’t know how many times I have needed to show the many iterations that led to the development of a certain version, or to compare and test many different versions of the same board. One always has to find intricate solutions to do this, and usually the result is not immediately understandable to those who wish to collaborate.

Ok, let’s dream for a second: I would also love to have all this synced on the git repository together with code and documentation of a project. I am aware that the way Git works (line-based diffs) makes this idea a bit cumbersome, but maybe there is already some project in this regard or someone has a strong opinion on this point. There may be version-control systems more fit to work with XML than GIT. That is an area where development might be needed. I would like to know what you think.

3 Likes

HI @val . I must confess that, since we decided to use svg format, we were as excited as you with the possibility of doing some kind of git-style version control.

Of course, this has huge implications and complexities, so it’s quite a long term wish. But it can be phased. For now, we have a story about implementing file version history, that you can follow:

1 Like

GitHub has support for SVG diff:

There’s a discussion with a list of tools for SVG diff here:

2 Likes

Thanks! We can take interesting ideas from those tools. I’ve added this to the user story in Taiga.

It’s true: you can always export manually your penpot files to svg and store it in a git repo. This way you have a version control, but unlinked with Penpot.

The issue would be to do some kind of automatic link, but this is what requires a lot of thinking and design.

What if I could give penpot access to a GitHub repo and it can commit the changes to it instead (or in addition to) of storing it to a file on the penpot server? Or you can mark “snapshots” which will be “milestones” you want to keep in your git(hub) history. Of course that will still take a lot of effort to be handled in detail.

Yes, those are the kind of ideas that have been boiling inside our heads for a long time. But there are many derivatives, alternate ways and side-effects that must be considered. Keep watching, and thanks again for your suggestions.

If I’m not mistaken: isn’t this how draw.io works when connected to GitHub?

Thank you for sharing @alexzeitler! The discussion on OSD really offers many insights, in particular I find GSVG - Git-friendly SVG very clean and interesting.

3 Likes

@val I’m looking forward to my first penpot SVG Diff in GitHub or penpot :wink:

2 Likes