GX-Feature #69191
Von Daniel Wu vor etwa 3 Jahren aktualisiert
Since we transformed our git workflow (end of July 2021) towards and very close to the widely used gitflow, the developers should have the possibility to use the gitflow command line tool that this workflow incorporates. It can't be used as it is, because we still have some minor differences in the workflow and also some additional requirements. Therefore we would like to write our own command line tool that serves our purpose better. This will help all developers that work with the shop to speed up the process and make it less prone to mistakes. It would enforce the developer to use the correct git workflow and make tasks like building a release package more accessible for other team members but the release managers. Currently it's quite usual that developers make some mistakes here and there, especially when it comes to changes in the workflow. With this tool we encapsule all the underlying actions with just one command. If we add changes to the workflow later and immediately change the underlying actions of the commands, the developer would not have to change anything in his workflow. He would just continue using the command line tool the same way as before. So it would be way easier to introduce changes to the workflow. The stability and speed of our package build would also benefit from such a tool. The feature is easily scalable, because new commands can be added successively. The tool should be either directly located in the repository root of the `gxdev` repository or in a seperate repository and included via composer. A suggestion for the name of the tool would be `gx`, so an example use could look like this: `gx release start v4.5.2.0_beta1`. The command line tool should be able to handle at least these actions: - Help creating `feature` branches, working with them and finishing them - Help creating `bugfix` branches, working with them and finishing them - Help creating `release` branches, working with them and finishing them - Handle patch versions for earlier versions correctly (release branch won't be merged to `main` branch and tag will be put to the `release` branch which will result in a tag on a detatched head after removing the release branch) The exact commands and also further needed commands should be identified during conceptualization. An idea for an additional feature of this tool: According to our branching strategy, `bugfix` branch names should contain the ticket number and a short description of the bug. Since it is only possible to use a certain set of characters for branch names, we currently just summarize the title of the bug ticket and make it kebab case. It would be nice, if we could just copy the bug ticket title and paste it as additional parameter to the command and convert it automatically to alphanumerical kebab case and attach it to the branch name. Example: ```bash gx bugfix start 69055 "It's not possible to apply full width backgrounds to content sections" ``` would result in a branch name like this: ``` 4.5/bugfix/69055-its-not-possible-to-apply-full-width-backgrounds-to-content-sections ``` `4.5/bugfix/69055-its-not-possible-to-apply-full-width-backgrounds-to-content-sections`