Wiki source code of Development in branches
Version 8.2 by Alexander Schulz-Rosengarten on 2023/07/11 10:32
Hide last authors
| author | version | line-number | content |
|---|---|---|---|
 |
1.1 | 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 | |||
| |
7.1 | 5 | Yes, branches! This shows the KIELER branching scheme. If you want to know whatever the different classes of branches do, check [[doc:Kieler.Processes.Source Code Management.WebHome]]. |
| |
1.1 | 6 | |
| 7 | [[image:attach:branches.png]] | ||
| 8 | |||
| 9 | == Why and how to use branches == | ||
| 10 | |||
| |
7.1 | 11 | Now you should now which use the different kinds of branches have, if not, go back to [[doc:Kieler.Processes.Source Code Management.WebHome]]. |
| |
1.1 | 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 | ||
| |
3.1 | 25 | 1. Push your branch to the mainline so that Bamboo can build it |
| |
1.1 | 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! |