Gitflow Design
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 490 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/46982 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 202074 / 490
4
7
9
10
14
15
16
25
26
29
31
33
34
35
37
40
41
42
43
45
46
47
50
51
52
53
54
58
60
64
65
66
67
70
71
72
74
75
76
77
78
82
83
84
86
89
90
93
94
95
96
98
100
101
105
106
109
110
116
118
123
124
130
135
137
141
142
144
146
151
154
157
159
164
166
167
169
172
174
178
182
184
185
186
187
189
190
191
192
193
194
195
200
202
203
204
205
206
207
208
211
212
214
218
222
225
228
230
232
233
235
236
240
242
244
249
250
251
253
254
258
261
262
266
267
268
271
273
274
275
278
280
281
282
283
284
285
286
288
289
290
291
293
295
296
297
298
301
302
303
305
306
307
310
311
315
317
318
319
328
333
350
353
354
356
359
360
361
370
372
373
374
375
379
380
381
383
385
386
387
388
391
393
394
395
397
398
399
401
409
410
411
414
420
421
422
423
424
425
427
429
430
434
438
439
444
449
450
454
457
458
459
460
461
464
465
466
468
469
470
471
472
480
484
486
487
489
490
00:00
Open sourceDataflowOpen sourceGoodness of fitProjective planeFocus (optics)BitDataflow
00:35
DataflowSign (mathematics)EmailMultiplication signLaceSoftwareProjective planeSlide ruleTwitterDigital rights management
01:06
Open sourceProcess (computing)Open sourceProjective planeSoftware developerFlow separationBitComputer animation
01:43
Ideal (ethics)FamilyComputer animation
02:10
DataflowSocial softwareWebsiteReading (process)Web pageRepository (publishing)Electronic program guideLink (knot theory)WebsiteWeb browserSoftware developerOnline helpProjective planeCASE <Informatik>Focus (optics)HypermediaWeb pageComputer animation
02:48
DataflowDrop (liquid)WhiteboardTelecommunicationProjective planeSign (mathematics)Touch typingPoint (geometry)1 (number)Open sourceFrictionCASE <Informatik>Goodness of fitBitComputer animation
03:56
Lattice (order)Point (geometry)FrictionDataflowLine (geometry)Drop (liquid)Computer animation
04:17
File formatClosed setSoftwareGoogolPoint cloudDrop (liquid)Local ringUniform resource locatorCuboidComputer filePoint (geometry)Vapor barrierControl flowDigital rights managementDrop (liquid)QuicksortSoftwarePoint cloudComputer animation
04:59
DataflowTask (computing)Process (computing)Decision theoryElectronic program guideDataflowPhysical systemProcess (computing)Projective planeComputer animation
05:43
Point (geometry)Process (computing)DivisorComputer animation
06:02
DataflowDataflowTraffic reportingProjective planeOpen source
06:42
Software repositoryDataflowSoftware developerSoftware repositoryOnline helpInformationElectronic program guideSource code
07:18
RAIDOpen setFile formatCollaborationismDataflowCollaborationismFile formatOpen setPoint (geometry)SoftwareRight angleFocus (optics)Traffic reportingSoftware developerComputer fileSoftware repositoryRepository (publishing)Source code
07:54
DataflowInformationControl flowRevision controlPhysical systemVideo trackingSource codeTorvalds, LinusBitSource codeRevision controlData storage deviceMathematicsInformationWordComputer animation
08:32
DataflowFreewareSource codeSoftware developerOpen sourceComputer fileDecision theoryComputer animationSource code
08:56
Revision controlControl flowDataflowProcess (computing)Open setPhysical systemTask (computing)Digital rights managementInformationInsertion lossDecision theoryDigital rights managementSoftware developerTraffic reportingPhysical systemProjective planeProcess (computing)DemosceneLogic gateOpen setSoftware repositoryTask (computing)Source code
09:40
Computer-generated imageryOpen sourceComputer fileFile formatOpen setDataflowUser interfaceSeries (mathematics)Pairwise comparisonRow (database)Different (Kate Ryan album)Projective planeMedical imagingData structureCommutatorMathematicsFood energyFunctional (mathematics)CASE <Informatik>FreewareFocus (optics)Identity managementSelf-organizationPoint (geometry)Commitment schemeKey (cryptography)Differenz <Mathematik>Goodness of fit
10:20
DataflowBinary fileComputer fileOpen sourceOpen setFile formatUser interfaceOrder (biology)FreewareInformationOpen sourceFocus (optics)Open setFile formatRaster graphicsSource codeSource codeProgram flowchart
10:56
DataflowHost Identity ProtocolNormal (geometry)Game controllerComputer fileRevision controlLogic gateSource codeBitOpen sourceFile formatOpen setFerry CorstenOrder (biology)Raster graphicsVector spaceSource codeComputer animation
11:23
WordCartesian coordinate systemType theoryOpen sourceRadical (chemistry)Endliche ModelltheorieBitNatural numberUser interfaceFocus (optics)DataflowAlpha (investment)Line (geometry)Data conversionINTEGRALComputer animation
12:22
DataflowTerm (mathematics)Branch (computer science)Software developerINTEGRALCommitment schemeProcess (computing)Point (geometry)Modal logicView (database)Marginal distributionComputer file
14:01
DataflowGame theoryCartesian coordinate systemUser interfaceRepository (publishing)Goodness of fitDataflowSoftware repositoryIntegrated development environmentComputer animation
14:20
DataflowLocal ringExecution unitDataflowSoftware repositoryBranch (computer science)WordMathematicsProgram flowchartSource code
14:39
DataflowDuality (mathematics)Point cloudDrop (liquid)MathematicsRepository (publishing)Computer fileVirtual machineProgram flowchartSource codeComputer animation
14:59
DataflowGame theoryWebsiteComputer fileCommutatorRange (statistics)Data storage deviceMathematicsCartesian coordinate systemOrder (biology)Different (Kate Ryan album)HalbordnungReading (process)Web pageComputer animation
15:52
DataflowOpen setComponent-based software engineeringWeb pageData storage deviceComputer filePhysical systemWeb pageComputer filePhysical systemDampingBranch (computer science)Software repositoryFreewareMultiplication signExplosionShared memoryComponent-based software engineeringData storage deviceRight angleSpacetimeArithmetic meanTraffic reportingComputer animation
17:07
EmailTwitterBinary fileComputer fileSoftware developerDataflowComputer animation
17:51
DataflowGame theoryUser interfaceComputer fileOpen setProcess (computing)Physical systemDigital rights managementTask (computing)Revision controlControl flowData structureResultantTraffic reportingType theoryComputer fileSoftware repositoryTrailPoint (geometry)File formatKey (cryptography)Open setShooting methodComputer animationSource code
18:29
DataflowRevision controlControl flowFile formatProcess (computing)Projective planeRevision controlSelf-organizationOpen sourceVapor barrierSoftware developerOpen setControl flowUser interfaceFocus (optics)Different (Kate Ryan album)Source code
21:07
DataflowOpen setDataflowComputer fileRevision controlDifferent (Kate Ryan album)Vector spaceLine (geometry)Raster graphicsMobile appBitFile formatProjective planeOnline helpResultantPoint (geometry)Boss CorporationMusical ensembleRandom matrix
22:15
Execution unitDataflowMathematicsMenu (computing)Integrated development environmentComputer fontCodeSource codeComputer animation
22:51
FacebookPoint cloudOpen source
Transcript: English(auto-generated)
00:06
Hi everyone. I'm here to talk today about Gitflow design, which is a Git workflow for design in open source projects. I think it can be a bit technical. It will depend a little bit on your knowledge of Git. I'll try to give some examples.
00:24
This is focused for designers or maybe for open source projects that want to increase their chances of onboarding designers into their projects and try to make it easier. Just a small overview of me. I'm Diogo. I'm a UX designer based in London. In my day time, I work as a UX lead for PokerStars.
00:45
On my free time, I contribute to the RTL app, which is a node manager for Bitcoin lighting network. I've also just started contributing to the Tor project, which I'm quite excited about. If you want to follow me on Twitter, Diogo R. Sergio, or if you want to send
01:00
me any emails about today's talk, you can use that email and the slides will be available online. I'll just start my talk and give you a bit of an overview of the situation in design in open source projects and what my experience has been so far over the years. This might not be true for everyone, but I think some people will relate, as it's quite a
01:24
difficult process for a designer wanting to contribute to an open source project and actually getting to do it. The whole process is a bit broken. I think it's mostly because of the separation between design and Git. Git is where all the development happens, so there's a huge gap between designers and the development teams.
01:44
Although it works, I think it's really far from ideal. That's why we see projects having difficulties finding and establishing a design team. I think everyone will benefit from having an easier way of integrating design in their projects.
02:01
Possibly having a design team, better product, happier end users. Let's have a quick look at what happens today. Usually a designer will probably start asking, how can I contribute to this project? Maybe they will go on the project page or even just quick browse social media.
02:20
Maybe just after that you open the project website, you try to find anything relating to how you can contribute to the project. In most cases, it will point you towards the Git repo, which is very much focused on development, which is not great. Usually there isn't any design guides or any kind of help on how you can contribute to these cases.
02:42
Usually you can find a link to IRC or Slack channel. Let's say if you really want to contribute, you'll go there. We are already starting to introduce a lot of friction points. For example, IRC is an example. It's quite common in open source projects as a way of communicating.
03:01
For designers, they might not know what IRC is or they don't know IRC. If you want to onboard users, this might be a drop-off point because they don't care or they want to contribute. It's so much effort that they just go away. Let's say that you really want to contribute to the project.
03:20
You actually create the account. You mentioned on the channel that you are looking to help with design work. Maybe because of different timelines, no one is there to talk to you. So you'll have to wait. Let's say on the good case that someone is there. They might point you into another channel, maybe a design channel. Or they might point you to speak to a design lead who is in charge of design so they can tell you a bit more about that.
03:45
So let's say you get in touch with that person or you join the channel. And probably, again, you'll have to wait because it's a communication. We are depending on humans and it's not always easy to coordinate. So I think by this point, people might be tired of waiting.
04:00
It's quite a complicated flow. Join IRC, waiting for someone. And if the stars do not align and everything goes smoothly, this can be another drop-off point. So you're already having a lot of friction points. But let's say that the designer managed to speak with the designer in charge or join the channel. Then comes another barrier.
04:21
You'll need to give an introduction of how things work. Tell you the location of the design assets. If you are lucky, they will be using some sort of cloud storage, Dropbox, Google Drive. If you are unlucky, probably they are using local files. So you need to ask the designers for files, which is another break-off point.
04:41
And then when you finally get the files, you end up seeing that they are from proprietary software. You don't have license to use that software. So you'll have to ask maybe for someone to export the files to you. And that's just more issues. But let's say you get all these, you get the files, and you speak with the design manager.
05:05
And you kind of think, okay, I'm set. So you think. The next step is you trying to understand how do you start. Usually there isn't a standard workflow. You just need to talk with people. What needs to be done? What is the team working on?
05:20
Is there a roadmap? Is there a ticketing system? If TS is usually outside Git, so another headache. Is there any style guides or guidelines that you can use or that you can follow? What's the review process? Who does it? When does it happen? Can you see the history, all the decisions made until now about the project?
05:40
So I think it's quite difficult. And I mean, there has to be a better way of doing this. And I think the main issue with this is that the design process is not self-starting. You are depending on a lot of factors. And he has quite a few human dependencies, so you'll need to wait for them. And I think that can be a point of failure as well.
06:03
So this is what I came up with. It's called Gitflow Design. I put it together when I joined an open source project which was fairly new when I was the first designer. So I thought it would be a great opportunity to set up a workflow that solves all the issues I was having and I found over the years.
06:20
The foundation is Git for this workflow. It's self-starting, so you don't need to wait for anyone. You can just go on the repo and read the documentation and start doing it. There's no human intervention before you can start contributing, and it's just there 24-7. It relies heavily on documentation and on the workflow, but I think that's a good trade-off.
06:44
So yeah, it's basically a design repo. It sits side-by-side with development, which is great. But it's tailored for design. It will have everything you need to get started. You don't have to fish information or talk to a lot of people. Everything will be there.
07:04
It has minimal dependencies. The workflow is documented on the repo help files. You will have contribution guides that will take you step-by-step on how you can do your first contribution. And everything is just there for you to start without any help.
07:21
It uses open file formats, which I think is quite crucial, so that everyone can collaborate without proprietary software. Although you can still use your Sketch and Figmas, the main focus of this workflow is using open file formats. And you can do exports to open file formats from those paid softwares.
07:41
I think it increases collaboration between design and development, because now these two Git repositories can be linked together. And yet there's no gatekeepers, there's no points of failure, so just go into the repo and start. As I mentioned, it's quite fearful for designers. The word Git, just as a quick overview.
08:01
Git is a version control system for tracking changes in source code. It was created by Lorna Storvalds, which is creator of Linux, and it was mentioned by him as a global information tracker. So you are in a good mood. It actually works for you. And the light suddenly fills the room. Or if it doesn't go your way, you've got an idiotic truckload of shit when it breaks, which can happen.
08:26
But in this flow, we are using a quite simplistic way of using Git, so you don't use all the dependencies, so it's a bit easier. So why Git? Well, it's because that's where all the development happens, and if it's possible to be in there, I think it just makes sense.
08:42
Even though it's made for source code, I will show you the benefits how we can use it for design. It's a place for everything, files, documentation, guidelines, accessible to everyone, free to use, and development can be linked together. It has controlled versioning for your design files, so no more final final.
09:02
It has auditable history, so you can just look at all the decisions taken over the year, what was the discussion, the why, and the reasons. So that's quite helpful. There's no loss of information. The review process is open to everyone. It happens in the open. Nothing goes behind the scenes.
09:20
The issue system can be linked together directly to the development repo, and vice versa. So an issue created in the development repo can trigger an issue on the design, so this creates a lot of seamless work between development and design teams. And you get all the benefits from Git, task management, and project management tools.
09:42
It relies heavily on a good folder structure when you organize a project. This is just an example of what I use, but the main focus here is just that we have the design folder, and then we have each feature that you work on as a subfolder, and then you have UX and UI, or others if you need.
10:03
Key important points is that we have the UX and UI, and we have the exports. So in the exports folder, we create export images of all, like PNGs of all your artboards, and this is so we can take advantage of Git image diffs. So once we start using Git, we can have side-by-side comparisons of what changed in those commits.
10:25
So in this case, I changed the order of the CTIs, and we take advantage of Git functionality, like having it side-by-side. You can swipe, you can see the differences, and this all comes for free. And also, another important folder is the source files.
10:41
So we keep a folder for proprietary software, because we want to keep all the information, so nothing is lost, like Sketch or PSD. But the main focus is creating these open file format folders, for example SVG, and Aura for open raster. So this is an example of open file format SVG, vector file created by Inkscape, open source.
11:05
Or Aura, for example, which is open raster files for GIMP instead of Photoshop. They are both based on XML, which means that they are essentially source code. And this means that they can be tracked in Git and used for versioning control, so what developers have for their files we can now use for design.
11:23
And you might think that it's starting to look quite complicated, but I think you have a little bit of work when you set it up, but then it just runs, and the more you do it, it becomes quite second nature. And I also think that designers can learn Git. And I dare to say that designers working for open source projects need to know Git, and it's like any other tool that you learn.
11:46
I mean, we jump from Sketch to Figma, we learn all these tools, but when the word Git comes into conversation, everyone is so scared. And I think it might be like this in the past, because Git was very command line focused, you have to go onto the terminal and type your own commands, so it was very techy.
12:04
But this day and age you have desktop applications that allow to work for you with really nice user interfaces, so I think there's no excuses not to learn it. Gitflow design is based on a branching model. This is becoming a bit technical about Git, but this is for example an overview of the workflow.
12:26
We have the master branch that records all the history, and we have the design which shows us an integration branch for all the features. So I'll just give a quick run through of the process. We start with master and design. Let's say I want to work on UX for feature one. I create a branch, I'll give it UX feature one name.
12:47
It's based off design. I'll go and start working on my files, I'll commit and push so everyone can see and give me feedback. Once I'm happy, I create a pull request. This notifies the design team. If the design team is happy with the work, they merge it onto design.
13:04
At this point, UX is done for feature one, so this means that the UI work can now start. Someone picks up the UI, they create another feature branch, UI feature one, they start working on it. They commit, they create a pull request when they want the work to be reviewed. It goes to the design team, everything was okay, it gets merged onto design.
13:25
At this point, both UX and UI for that feature were signed off, and they are on the design branch. So now the design team can create a pull request and merge it onto the master, and this means that the feature is finished. So now the development team can pick it up.
13:43
This is another overview, just saying that feature branches can start at any point and they can go up to design but then come back to be reviewed if necessary. This might be quite difficult if you think about branching and all these terms of Git.
14:01
I'll just give a quick example of GitHub in 10 steps. This is GitHub, which is an application for Git, but you can use any. The user interface they have is quite nice, and it's easy to use it. So let's say you start the application, you want to clone a repository from the internet,
14:21
you put on the URL of the repo where the Git flow is hosted, you clone it. We have no local changes, we haven't done any work. I can see that there's branches over there, so I click on branches. You can see what other people are working on, but I want to start working on my own feature so I can create a new feature.
14:41
I give it, yeah, I'm working on UX, UX, working on Lightning, give it the name. It's based off design. It's okay, no changes. I can see now that the Git repository was cloned to my machine, I can go into the folder, start to create my own, and start to create my own files and working on them.
15:00
If I go onto the application, it will show all the changes I've done, all the files that I've added. If I want to, when I'm ready to commit, I just give it a title, and I click commit to UX Lightning. It goes onto the Git. If you want to publish for other people to see your work, you can publish the branch, and it goes onto the GitHub website so everyone can see.
15:23
Let's say you continue to work on the file, it will see the differences between the changes you've made, and this is quite beneficial. You can see on the previous commits, I have, for example, an order of CTAs. Now I changed it, and when people are reviewing it, they can see it straight away on the application.
15:43
This is quite nice. When you are ready, you worked on everything you've done, and you're ready to submit the work for the design team. You just create a pull request. He opens the GitHub page. You just give it a title. You say what you've worked on, and that's it.
16:01
It seems like quite a workflow, but once you start using it, this GitHub thing, you start to see that it's quite easy to do. The more you do it, the easier it becomes. Just some things that I'm planning on working next. Using GitHub, LFS, large file storage, for example, to use for those big proprietary files, which they are
16:25
not tracked in Git, so they can become quite big and just make the repo explode in size. Ways of using shared master components, so we can use those across the design team so we can share components. We don't have to redesign everything from scratch every time.
16:40
And possibly using GitHub pages to create a design system, maybe in an automated way, that it can just pick up the files from the master branch and some documentation and create a design system automatically, and everything comes for free. And maybe also create pages for, let's say, developer end of specs, so it gives you all the CSS and all that for developers.
17:06
And that's it. It's quite a complicated flow, but I think it brings a lot of benefits because everything stays in Git, and we are trying to get design and development come close together.
17:22
So I think it's beneficial. Thank you. A couple of questions. I'm going to ask everybody to please not to leave the room and the other big questions as well, okay? Yeah. When you add a, for example, sketch file, so it's basically like a zip
17:44
file with the XML inside, so to be treated as a binary file essentially, right? Yeah. There's ways of, I think I might have an example here.
18:03
But yeah, sketch files, for example, is proprietary, although, and I explained this in the repo more in-depth in all these types of files. For example, sketch files can be unpacked, and inside is just JSON files, basically. So you can unpack sketch files, track those, and then when you want to use a sketch file, you can pack it.
18:28
Yeah. I think the issue, the key point is that if you work on sketch, you still work on sketch. When you're finished working, you just create an SVG as an open file format and include that in the folder, and you just keep sketch for yourself as well.
18:55
I use abstract actually for a couple of projects, but as you said, it's proprietary, you have to pay for it, and as the same issue, it happens outside Git.
19:03
So developers will not be aware of what's happening, and they need to install the app, they need to create accounts, so it's another barrier. Yeah, definitely. And this is where development teams can help out.
19:24
For example, this whole process can be a nice user interface, so you don't have to rely on the desktop app, it can be more design-focused. More questions? Yeah.
19:50
It's not easy, I think it's a trade-off, especially because we are using Git. We are trying to avoid a lot of conflicts between people working on the same project, so we kind of break it apart.
20:00
So we break it apart as features, so everyone works on something separate, so there's no clashes. I don't think this answers your question. Anything else? I think this process can be used by designers, you can go to an open source project and kind of pitch in this,
20:25
let's create this for your project, you can bring a lot of designers, I'm ready to do the work, or just open source organizations that want to bring more designers into their projects as well.
20:46
I can see how that works here.
21:03
Just another question, when you were showing a Git flow, it was a simple case, is it useful to do a rebase once in a while, or something like that, to resolve conflicts, or is that something that you experience? It can become quite tricky, this is where you need to have a lot of knowledge in Git.
21:25
In this example, in the Git flow, I tried to keep things easier as possible for designers to jump in, I think once they start adopting the project and working on it, and by working with Git daily, they start to learn more and more, possibly they leave the Git flow desktop app and use the command line and they start to learn a bit more,
21:41
but yeah, it's quite tricky, especially with clashes and conflicts within files. Although those open file formats like SVG and Nora, they are based on XML,
22:04
if you are not using any bitmaps inside, which can be useful, if it's just vector files, you can work quite nicely, you can even change the, you can see the differences in code, for example I changed the font, and you can see that the font changed there,
22:20
so it's just a piece of code, but yeah, it's tricky. But if you keep it simple, I think it's useful. And then we can move from there. I think it's changing the mind of designers that Git is not that hard, and we can jump in and be side by side with development, and after that we can start building on top of it.
22:43
Thank you.