| Re: [escet-dev] GitLab |
|
> The alternative is not to have strict branch naming rules.
> [...]
> I don't know about
you, but I prefer "add-synthesis-tool" above "242354" any day.
I personally prefer
to include both the issue number and some description, to have a readable name that is also traceable to the issue without having to check the commits in the branch (if there are any yet).
But I'm fine with
not having a fixed rule.
I hope we can have relatively short living branches. Then we won't have too many at the same time. As long as we can keep them apart, that is the most important thing.
> If you use gitlab to create the branch, you need to first visit gitlab, find the issue, click a button, then pull
or fetch with a possible fast-forward, select the branch again, checkout, and start doing things.
The way you describe it is how I did it
for the initial contribution, and after getting used to it a bit, it is very quick.
Note that you have to go to GitLab anyway, as you needs to assign yourself to the issue when you start working on it.
> [...] somewhat overkill, as every commit is supposed to have an issue number as
I understood
> (which I am definitely also going to forget or not know at the time, no idea yet how to manage that).
Indeed that is important, as that couples it to the issue also in GitLab, such that commits and issues are linked. This makes it possible for the community to understand
what is happening, and thus relates to the transparency principle.
Ideally we can set a commit check to reject a commit in case it doesn't match regex '^#\d+ .*' or so. We can check/ask whether that is possible.
> So yeah, something more heavy than Github flow is good.
> GitFlow is however the only more-or-less common model that's more complete than the Github model though as far as I know [...]
OK, let's use GitFlow.
We can try to approach it practically and reduce the overhead if applicable/possible.
> I typically use "project" as alias for the project repository rather than "origin", to keep things consistent between github projects,
local projects, and now gitflow-ish projects.
That's fine ofcourse. Anyone can use their own name locally.
Dennis
Van: escet-dev-bounces@xxxxxxxxxxx <escet-dev-bounces@xxxxxxxxxxx> namens Hofkamp, A.T. <A.T.Hofkamp@xxxxxx>
Verzonden: vrijdag 23 oktober 2020 08:36 Aan: escet developer discussions <escet-dev@xxxxxxxxxxx> Onderwerp: Re: [escet-dev] GitLab
Hai,
> Seems it is not yet possible to change the default names: https://gitlab.com/gitlab-org/gitlab/-/issues/21243
Pity.
> We can change the name manually when we create a branch, but I would probably forget that most of the time.
The alternative is not to have strict branch naming rules.
If you use gitlab to create the branch, you need to first visit gitlab, find the issue, click a button, then pull or fetch with a possible fast-forward, select the branch again, checkout, and start doing
things.
I typically just make a new branch label, switch to it, and and start hacking.
> Personally I don't need autocomplete.
Otherwise you'd have the same problem as me, wouldn't you?
🙂
> A benefit of starting with the number is that branches can be sorted on the numbers (more or less).
You mean most tools fail to have configurable sort criteria.
I don't know about you, but I prefer "add-synthesis-tool" above "242354" any day. To me the numbers are mostly noise, except in rare occasions where you have to link a branch back to an issue. It's also
somewhat overkill, as every commit is supposed to have an issue number as I understood (which I am definitely also going to forget or not know at the time, no idea yet how to manage that).
> all in the same environment as where development itself takes place.
I see Linux desktop as my dev environment. I also use it 100% of the time.
> original post about GitFlow: "We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state."
I know. I have read it in the past.
Like I said, they renamed "releases" branch to "master".
That quote only states what they did. It does not explain why they violate standard git convention of master being the bleeding edge development branch. Why is the thing named "develop" rather than "master"?
I understand feature branches and release branches and fix branches. It's a heavy model. We may need all those branch types at some point.
So yeah, something more heavy than Github flow is good.
> Our Oomph setup will check out 'develop' by default, so that will be our 'default' branch in that sense
Why do you start discussions about a model if the ship already sailed?
> I'm not sure if we can change the default to 'develop' in GitLab
There are default branches and protected branches that you can configure afaik.
> GitFlow seems rather standard these days and would be familiar to many contributors.
GitFlow is heavily outnumbered by Github flow or even simpler "do everything in master" would be my guess. It heavily depends on the kind of contributors.
GitFlow is however the only more-or-less common model that's more complete than the Github model though as far as I know, so we have a singleton set to choose from
🙁
> Note however, that the blog post talks about the possibility of sub teams, which share work, but don't push that to 'origin' (yet). It also talks of feature branches that exist only locally on a developers
PC and not on 'origin'.
Makes sense, with a heavy model you aim to cover all possible needs. I don't think we'll do sub-teams anywhere near soon.
I typically use "project" as alias for the project repository rather than "origin", to keep things consistent between github projects, local projects, and now gitflow-ish projects.
From: escet-dev-bounces@xxxxxxxxxxx <escet-dev-bounces@xxxxxxxxxxx> on behalf of Dennis Hendriks <dh_tue@xxxxxxxxxxx>
Sent: Thursday, October 22, 2020 17:51 To: escet developer discussions <escet-dev@xxxxxxxxxxx> Subject: Re: [escet-dev] GitLab
> According to https://nvie.com/posts/a-successful-git-branching-model/,
the original post about GitFlow [...]
Note however, that the blog post talks about the possibility of sub teams, which share work, but don't push that to 'origin'
(yet). It also talks of feature branches that exist only locally on a developers PC and not on 'origin'. This is in principle not allowed at the Eclipse Foundation.
Don't develop for a long time locally and/or with multiple people outside of the view of the community. The Eclipse Foundation principles require that we are open and transparent.
As such, commit and push often to GitLab, which is 'origin', such that the community can see what is being worked on. Also, collaborate together on branches that are visible in GitLab.
Dennis
Van: escet-dev-bounces@xxxxxxxxxxx <escet-dev-bounces@xxxxxxxxxxx> namens Dennis Hendriks <dh_tue@xxxxxxxxxxx>
Verzonden: donderdag 22 oktober 2020 17:32 Aan: escet developer discussions <escet-dev@xxxxxxxxxxx> Onderwerp: Re: [escet-dev] GitLab
> [...] As such, I'd prefer the issue number at the end, don't know if that's possible.
Seems it is not yet possible to change the default names: https://gitlab.com/gitlab-org/gitlab/-/issues/21243
We can change the name manually when we create a branch, but I would probably forget that most of the time.
Personally I don't need autocomplete. I use the Eclipse IDE with EGit for 99.9% of all Git related stuff, not a console.
It is then very easy to switch branches, commit, push, pull, see history, look at diffs, etc, all in the same environment as where development itself takes place. Took a little bit of time to get used to the first time, but I wouldn't want to use a separate
application anymore. Some super advanced stuff is not possible, but that's the stuff one hardly ever uses, and for that you can obviously still use the command line.
A benefit of starting with the number is that branches can be sorted on the numbers (more or less).
> Gitflow will likely do all we want, the one problem I have with it is that it breaks standard git semantics of "master".
For no good reason, they renamed "master" to "develop", and renamed "releases" to "master" to confuse everybody. Why?
According to https://nvie.com/posts/a-successful-git-branching-model/,
the original post about GitFlow: "We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state." I should probably use this to refer to GitFlow instead of the other link I used (which was Google's first
hit). The original post has more explanation and explains the reasoning behind the flow.
Our Oomph setup will check out 'develop' by default, so that will be our 'default' branch in that sense, and we can make
multiple streams for master/develop/etc branches.
I'm not sure if we can change the default to 'develop' in GitLab, as otherwise it would be very irritating. We may have
to ask the admin to do that if we can't do it.
We could opt for GitHub Flow (https://guides.github.com/introduction/flow/),
but that is just master and branches, which seems too simple. GitFlow seems rather standard these days and would be familiar to many contributors.
Van: escet-dev-bounces@xxxxxxxxxxx <escet-dev-bounces@xxxxxxxxxxx> namens Hofkamp, A.T. <A.T.Hofkamp@xxxxxx>
Verzonden: donderdag 22 oktober 2020 16:13 Aan: escet developer discussions <escet-dev@xxxxxxxxxxx> Onderwerp: Re: [escet-dev] GitLab
> I suggest the following for milestones:
Seems fine.
Epics are indeed topic oriented as far as I know. Mostly anything bigger than a few issues, where you need an overview ticket about
purpose, plans, and progress. Never worked with proper Epics though, until now I just used a ticket labeled "[epic] <topic>".
>
I suggest the following for issues:
Not many surprises, 2 points:
From: escet-dev-bounces@xxxxxxxxxxx <escet-dev-bounces@xxxxxxxxxxx> on behalf of Dennis Hendriks <dh_tue@xxxxxxxxxxx>
Sent: Monday, October 19, 2020 13:02 To: escet developer discussions <escet-dev@xxxxxxxxxxx> Subject: [escet-dev] GitLab
Hi all,
In another discussion, Albert mentioned:
> [...] should we discuss gitlab configuration?
> Issue tags and milestones at least I think, and probably branch usage/names/conventions?
> [...]
> In general, I think less is more here.
I suggest the following for milestones:
We have both epics and milestones. Both seem to group issues. Epics seem to be meant to group by functionality while milestones seem more focussed on what you address/finish/release
together. You could thus have funcionality in an epic that you release partly as part of one milestone and the rest as part of a next milestone. Maybe if we later have releases with multiple topics (groups of functionality) epics may become handy as well.
I suggest the following for issues:
For commits:
These are my first thoughts. Let me know what you think about them and whether you have other ideas.
Dennis
|