Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stories of good collaboration workflows with Kactus #100

Open
xuv opened this issue May 26, 2018 · 4 comments
Open

Stories of good collaboration workflows with Kactus #100

xuv opened this issue May 26, 2018 · 4 comments

Comments

@xuv
Copy link

xuv commented May 26, 2018

Sorry, this is not a technical issue per se, but we are assessing the tool at the moment in our team and we are struggling a little bit trying to figure out what would be the good way to use Kactus in a multi-designer/dev team. And because I could not find any other discussion board relative to Kactus, I'm hoping this issue could serve as a placeholder for a broader discussion regarding good workflows using Kactus

So our trouble comes around merging and branching. We are working with a series of Artboards representing different screens of our application. One of our designer created a branch and added a new Artboard to the list. While at the same time, another designer created his own branch, modified one of the existing Artboards and added another one. We merged the first designer's branch in master without problem. But when merging the second branch, there was, as expected, a merge conflict. The option offered was to choose between keeping the repo unchanged or erase the merge from the first branch and replace it with a merge from the second branch. This is not what we hoped for to solve the merge conflict. In the end we solved this manually by copy pasting things in between sketch files. But maybe we could adopt a better workflow and Sketch file organization that would prevent this impossible merge conflict?

@mpaiva
Copy link

mpaiva commented May 31, 2018

Hi @xuv - I can tell you what has worked for my team. We have a similar structure and we solved these issues in 3 steps:

  1. Created a library of sketch symbols to the atomic level, such as color variables, typography elements, form elements and icons
  2. Trained the designers to create branches to work on atomic level elements only - think of these as individual sketch files containing only a small group of symbols (i.e.: 1 file for colors, 1 sketch file for buttons, etc.)
  3. If a file is changed, it is pushed to the Sketch Library repository containing the atomic elements/symbols being used to create the multiple views/artboards in question.

Hope this helps.

@xuv
Copy link
Author

xuv commented May 31, 2018

Hello @mpaiva. Thanks for sharing your experience. Does it mean that you are only using Kactus for the sketch symbol library file, not for the main design files? Did I understood you correctly?

@mpaiva
Copy link

mpaiva commented May 31, 2018

Our team keeps the components Library in a separate repo. As we work on the different areas of the product those would have separate repositories. Each repository has other sketch files containing the views.

@mpaiva
Copy link

mpaiva commented May 31, 2018

This link may help you understand a bit more.
https://sketchapp.com/docs/libraries/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants