Create a branch from an issue, with pull/merge request #20226

Open ygoe opened 2 years ago

Feature Description

There is a workflow that uses issues to define tasks to do and then work branches to do the issue's work in. When the work is done, the branch will be merged into master/main. It saves a lot of manual work if the Git tool already creates a work branch from an issue and also a merge/pull request for it with the corresponding "Closes issue ..." message.

GitLab does this and I'm using it a lot. GitHub also does this but that's not (yet?) reflected in Gitea's feature comparison.

It has been asked before but was closed. Not sure why because it was neither implemented nor rejected and can't be reopened for some reason. Here's a second try.

Screenshots

GitHub

grafik

GitLab

grafik

grafik (Clicking the button, not its dropdown menu, would immediately create the branch and MR)

I was just thinking the same thing :)

If we could allow the branch name to be templated that would be a +1 on gitlab/hub

It would be great to see this and it's probably a template/UI change with maybe a setting in the repo settings to provide the template for the branch name.

Also, I wouldn't want to create a branch until the ticket was assigned, so some automation here would be great to see. A repo settings checkbox perhaps to "create issue branch on assignment", "create on label added " etc

The MVP would be just to add in the create branch option inside the issue and allow for manual branch name.

Also, I wouldn't want to create a branch until the ticket was assigned,

I would recommend to look at the dev.azure.com. they have done it very nicely.

Development has not been started:

Branch created:

PR created (merge conflicts):

PR has been completed:

So literally there is a Development section. You can link commit hash, branch or pr (many of them). Within the branch name and link you have a small button Create pr. When you create a pr the branch label changes into PR. Along the PR name you have a status and the validation check state. Eg if it is failed (merge conflicts or build/tests failed) it is shown as red otherwise it is green, and merged/completed gray.

It is very useful cos when I am looking at particular issue I can see the development state of it:

If I see nothing and the issue is assigned, it means somebody working on defining requirements and estimations
If I see branch, it means somebody started working on code changes
If I see PR green, it means code is awaiting for review/ approval
If I see PR red, it means the are some problems with approval/merge
If I see PR gray, it means the PR has been merged

When PR is being approved you have an option (checkbox) to close the related issue ones it is merged.

BTW. I cannot see why do I need to create a branch and a PR at the same time as Gitlab does. The PR means the work is done and ready for review and approval - while when I create a branch I have no any code changes at all. The reviewer would be confused with many empty or not completed PRs. PR should be created when code changes has been completed and ready for review.

Anyone who working on this?

@fairking

BTW. I cannot see why do I need to create a branch and a PR at the same time as Gitlab does. The PR means the work is done and ready for review and approval - while when I create a branch I have no any code changes at all. The reviewer would be confused with many empty or not completed PRs. PR should be created when code changes has been completed and ready for review.

This is just a different development model, and I appreciate it. The major points about the GitLab model is:

The PR is opened with a "WIP:" prefix. There is a conceptual and functional difference between WIP and non-WIP PRs, and you can filter them accordingly.
The PR has a button that lets you auto-remove the WIP prefix and mark it as "ready".
When you're creating a work branch, you almost certainly will want a PR anyway eventually, so it's one less action to just get it out of the way at the beginning.
If you have testing CI that runs on PRs, this lets you more easily work with it as you develop. I think you can even prevent marking a WIP PR as ready until tests pass, but I'm not certain (might be an EE only feature).
It lets you more easily see the actual work associated with an issue. An issue can have multiple branches associated with it, and some people branch while working on a single issue, and might end up uploading those branches, not to mention other release branches and things that aren't associated with specific issue or PR work. It also lets people more easily leave comments on ongoing work in the PR rather than digging through branches, which can be extra helpful if you happen to have multiple people working on one PR at a time.

From my perspective, if an issue will definitely need at least one branch and at least one PR associated with that branch, it's a productivity gain to just make them both, all linked together and to the issue, with one action. GitHub and Azure's model involves more effort for no real extra gain in power or flexibility, and Gitea's is all manual at the moment. I also thought the GitLab way was weird at first, but it does save some busywork.

I think the feature would be very nice from people migrating over from gitlab.

I work on a self-hosted gitlab instance in my company, and I am not happy about how slow it runs. Many developers share this opinion, but the above described workflow is something that my company (and all the project managers etc.) are used to. People like me cannot pitch gitea to those people.

Please have mercy with me and all the others and consider implementing this feature :pray: :pray: :pray: Free us from the shackles :chains: of slow loading issue pages and a bloat interface.

( :wink: )

But srsly though: The feature would be nice IMHO.

My only hope, Gitea won't become overcomplicated like others. I wish I can still have a small cup of tea 😉

@fairking I agree. This is actually something that I've been handling client-side. I have a custom git command called issue-pr (warning: very rough-and-ready undocumented alpha-quality code) that uses the gitea API to do the same process client side. Running git issue-pr $issue_number will create a branch for the issue and a WIP PR and link them all together.

A browser extension or userscript could probably do the same thing, now that I think of it. (edit: I have since turned berx into a Userscript)

Edit: Another thing that occurs to me, looking at my command, is that there's a lot of busywork in creating a branch for an issue, opening the PR, linking the branch, and also giving the PR the same assignee+labels+due date+etc as the issue. There aren't a lot of situations I can think of that a PR and its associated issue should differ on labels or assignee, or most of the other metadata like project and milestone when they're linked one-to-one. At least on PR creation, copying the issue's metadata is a nice convenience.

An obvious requirement is to create a branch from an issue. The PR does need to be created after the branch is completed. Perhaps an additional function to create a PR on the current issue can be provided.

hello, is this feature still being developed ?

Nobody are working on this issue.

Hi guys, I just would like to bring to attention this topic again.

I had a chance to work with gitea recently (v. 1.21.2) and I was very confused with the option to create a new issue from PR. Please have a look at the screenshot bellow:

So literally gitea team thinks that the code changes needs to be done first, and then an issue is created. I am completely confused by it and it completely makes my brain hurt. Please someone could help me to understand what is the actual flow of working on the code with gitea.

In my 20 years of experience this first thing you do is to gather user requirements and draw an issue/feature first, discuss it with users, and then you write the code (by creating a branch), and then you create a PR for approval. Not the other way around.

I don't think (IMHO) gitea is going into good direction. If someone writes code first, and then defines an issue/spec is very very bad idea. 👎

P.S. I also just realized, the gitea repo code changes in 99% are just pure PRs, so nobody solves user issues, but works on something else. In my case is unacceptable. The PR should close an existing issue, not open a new one. But again I may be wrong.

The Code of conduct of some of the big open source project:

Code changes without community discussion...

This is not PR first and issue later. It means, you can create a new issue from an issue/pr/comments if you find it related to another problem but you don't want to discuss/resolve in the same place. And that's another feature that is not the same as the current.

And I think your suggestion is great to require an issue before sending a PR.

Hi, I worked in the last half year on a massive software project and they used Gitlab with a workflow like the threadopener mentioned. And it worked really well. In my own I have smaller projects but want also use this workflow. So I installed gutes because it had not so the overhead like gitlab. Gitlab had a lot of functions I don't need. But yesterday I had find out that this perfect workflow us not possible in Gitea and I can't it understand because it is a perfect process workflow with a logic base.

So will it come or should I use Gitlab?

Best

Hi, I worked in the last half year on a massive software project and they used Gitlab with a workflow like the threadopener mentioned. And it worked really well. In my own I have smaller projects but want also use this workflow. So I installed gutes because it had not so the overhead like gitlab. Gitlab had a lot of functions I don't need. But yesterday I had find out that this perfect workflow us not possible in Gitea and I can't it understand because it is a perfect process workflow with a logic base.

So will it come or should I use Gitlab?

Best

I'm interested in sending a PR to implement that.

31899 supports creating branches and pull requests from the new sidebar section `development`. Linking branches and pull requests will be the next step.

go-gitea / gitea