Doubs about workflow GIT -> Plastic

[Nefisto]

I'm migrating from git and currently, I'm reading ur book about plastic, and want to share two doubts about workflow.

 

1. About repositories: I'm an indie dev, so I'm starting a lot of small projects, some for prototype something, some for game jams, some to create a lesson, and so on. Some of those projects I work alone, some in teams/groups, and some with friends. My doubt is: in git, I do this by having multiple directories with different contributors, what works perfect for my case, but here I don't found a similar solution, because if I understand it right all that I can have is different groups inside my organization, but this really does not seem right. Am I don't getting something, how can I organize projects in a more modular way here in plastic?

 

2. About flow: In git I normally use git-flow, and there I have a stable branch that is a deployment branch, so I only pull/push to this branch when some features as ready or when sprints end, but in your book, you're suggesting short live branches that will merge all in the main branch and that I can make a label to identify what version is deployable. My doubt is: if I have, for instance, deployed my v1.0 in let's say Monday, and worked all week along with several short live branches in the week, so I have some snapshots that come after v1.0 but is not public yet so I don't update my version yet, and someone has found a bug in v1.0, so I need to work on a hotfix that in my branch need to comes after v1.0 generate a v1.1 but before my week snaps so when I ready to launch v1.2 I'll pull from v1.1 before a push to production. If I only create a snap from v1.0 I can create a label to this hot-fix and deploy it, but I can not merge in the main branch just before v1.2 come to play, and this does not sound right, is I misunderstand something?

[psantosl]

Quote

1. About repositories: I'm an indie dev, so I'm starting a lot of small projects, some for prototype something, some for game jams, some to create a lesson, and so on. Some of those projects I work alone, some in teams/groups, and some with friends. My doubt is: in git, I do this by having multiple directories with different contributors, what works perfect for my case, but here I don't found a similar solution, because if I understand it right all that I can have is different groups inside my organization, but this really does not seem right. Am I don't getting something, how can I organize projects in a more modular way here in plastic?

Are you sure you use different directories in Git? Or do you mean you use different repositories? When you say Git you mean GitHub or GitLab, correct?

In Plastic you should achieve this doing the same as in Git, different repositories. It is also possible to achieve it with directories, but AFAIK, this is not really possible in Git.

While you can do it using permissions in Plastic, I strongly recommend you to use different repositories for your case.

 

Quote

2. About flow: In git I normally use git-flow, and there I have a stable branch that is a deployment branch, so I only pull/push to this branch when some features as ready or when sprints end, but in your book, you're suggesting short live branches that will merge all in the main branch and that I can make a label to identify what version is deployable. My doubt is: if I have, for instance, deployed my v1.0 in let's say Monday, and worked all week along with several short live branches in the week, so I have some snapshots that come after v1.0 but is not public yet so I don't update my version yet, and someone has found a bug in v1.0, so I need to work on a hotfix that in my branch need to comes after v1.0 generate a v1.1 but before my week snaps so when I ready to launch v1.2 I'll pull from v1.1 before a push to production. If I only create a snap from v1.0 I can create a label to this hot-fix and deploy it, but I can not merge in the main branch just before v1.2 come to play, and this does not sound right, is I misunderstand something?

This is a very good question.

Git-Flow is somehow considered outdated these days because it is an overcomplicated solution. You could implement exactly the same thing with Plastic if you want, no limitations, but I don't recommend it.

Task branches + trunk based development is a much faster way to work, and much simpler.

You can keep merging branches back to main during the entire week, then release at the end of the week if needed. OR, you could now release more often.

Regarding the v1.0 fix: why don't you simply create a new version with the fix at the current stable state and release it? This is entirely possible. Just do the fix based on the latest on main, merge it back, release. Yes, the user will get some improvements too, but that's not an issue 🙂

In case you really, really want to fix on top of v1.0:

- You can create a branch out of v1.0
- Fix it there.
- Label the cset in that branch accordingly and release it.
- Merge the fix branch back to main too, so the fix also goes into the next release.

Hope it helps,

pablo

[Nefisto]

18 hours ago, psantosl said:

Are you sure you use different directories in Git? Or do you mean you use different repositories?

My bad, I meant repository

18 hours ago, psantosl said:

When you say Git you mean GitHub or GitLab, correct?

My bad again, I was referring to Github whenever I said git

18 hours ago, psantosl said:

In Plastic you should achieve this doing the same as in Git, different repositories.

How I can achieve this? I try to find this in the dashboard, but I found only how to add ppl to my organization and in plastic, I only found how to change permission.

19 hours ago, psantosl said:

I strongly recommend you to use different repositories for your case.

Can u show me how to share only the repo? And another one, does I need to invite ppl to my organization to share repo? Will be amazing if I don't need to

 

19 hours ago, psantosl said:

Task branches + trunk based development is a much faster way to work, and much simpler.

I've saw recommendations about this in your book, I'll certainly try to study a little more about it, I've never heard about it before.

 

19 hours ago, psantosl said:

Regarding the v1.0 fix: why don't you simply create a new version with the fix at the current stable state and release it? This is entirely possible. Just do the fix based on the latest on main, merge it back, release. Yes, the user will get some improvements too, but that's not an issue 🙂

You're right, this is a good solution, now that u say an answer this question seems some kind of silly one 😒 haha
 
It really helped, thanks a lot

[calbzam]

Quote

How I can achieve this? I try to find this in the dashboard, but I found only how to add ppl to my organization and in plastic, I only found how to change permission.

If you want to assign different permissions per repository, you can customize it in the Plastic GUI --> Repositories list --> right-click a repo --> Permissions. All the users accessing the cloud repos need to be invited first to the cloud organization. After they belong to the cloud organziation, you can customize the permissions for them. You can allow access to the desired users and to the desired repos.

https://www.plasticscm.com/documentation/security/plastic-scm-version-control-security-guide

Plastic also has a fature that allows to reuse existing repos as part of other projects: Xlinks. It's the equivalent to git submodules. From your previous comment, I'm not sure if you are using them

https://www.plasticscm.com/documentation/xlinks/plastic-scm-version-control-xlinks-guide

Projects often need to reuse existing components that have been developed and are actively used as part of other projects. Plastic SCM encourages using separate repositories for different projects and components, and access shared components by "mounting" them in the project repository through Xlinks. This chapter will introduce what are Xlinks and how to use this powerful feature to share components among projects that evolve in parallel.

Regards,

Carlos.

[psantosl]

Remember to create repos you have to use the GUI, there is not support for that from the web dashboard. I bet this will ring a bell

[Nefisto]

On 10/6/2020 at 12:18 PM, calbzam said:

All the users accessing the cloud repos need to be invited first to the cloud organization.

That's what I was afraid of.

But anyway thanks for help guys, I'll get used to change permissions and try to implement this in my workflow 😜