Wiki source code of Development in branches
Last modified by Alexander Schulz-Rosengarten on 2023/09/05 10:52
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | In the KIELER project we use Git. We like Git. We want to get the maximum out of Git. We want branches, many branches. | ||
| 2 | |||
| 3 | == Branches? == | ||
| 4 | |||
| 5 | Yes, branches! This shows the KIELER branching scheme. If you want to know whatever the different classes of branches do, check [[doc:KIELER.Development.Processes.Source Code Management.WebHome]]. | ||
| 6 | |||
| 7 | [[image:attach:branches.png]] | ||
| 8 | |||
| 9 | == Why and how to use branches == | ||
| 10 | |||
| 11 | Now you should now which use the different kinds of branches have, if not, go back to [[doc:KIELER.Development.Processes.Source Code Management.WebHome]]. | ||
| 12 | |||
| 13 | Ok, now nearly everything should be clear. We want to implement everything in features. The master branch should always be release-ready. For developers this means: | ||
| 14 | |||
| 15 | 1. Break down development into small features. Implement large Features incrementally in smaller Features | ||
| 16 | 1. Make a feature branch for each feature you develop | ||
| 17 | 1. Regularly merge changes from the master branch into your feature branch | ||
| 18 | 1. Keep track of your development tasks in Jira, it helps others to know what you are working on | ||
| 19 | |||
| 20 | == When is my feature considered as done? == | ||
| 21 | |||
| 22 | So you took heed to the branching guidelines. There is a little more, you do not know yet when your feature is ready to be merged back into the master branch: | ||
| 23 | |||
| 24 | 1. All planned functionality must be implemented and working | ||
| 25 | 1. Push your branch to the mainline so that Bamboo can build it | ||
| 26 | 1. The code has to be well commented; especially Javadoc comments have to be complete | ||
| 27 | 1. The code must not contain any warnings, including FindBugs and Checkstyle warnings. If single warnings cannot be avoided, leave a comment in the source | ||
| 28 | 1. The code should be well covered by unit tests | ||
| 29 | 1. The code should have been reviewed | ||
| 30 | |||
| 31 | == But my feature is sooooo tiny, do I always have to open a new branch? == | ||
| 32 | |||
| 33 | Well, at least you should. If your feature is really small it is ok to push it directly to master. Remember, do not break the build! |