Git Workflow » History » Version 6
Alexander Watzinger, 2019-09-06 14:10
1 | 1 | Alexander Watzinger | h1. Git Workflow |
---|---|---|---|
2 | |||
3 | We are using "git":https://git-scm.com/ as a versioning system using the "Git Branching Workflows":https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows |
||
4 | |||
5 | 6 | Alexander Watzinger | h2. Main branches |
6 | 1 | Alexander Watzinger | |
7 | 5 | Alexander Watzinger | * *master* - the stable version used in productive environments. It is the latest release version which is tested and, to our knowledge, bug-free. |
8 | 1 | Alexander Watzinger | * *develop* - here the latest development branches are joined when they are finished. At a release the develop branch is merged into the master branch. |
9 | |||
10 | 2 | Alexander Watzinger | The branches in which the work (in progress) is happening have following prefixes: |
11 | 1 | Alexander Watzinger | |
12 | * *feature_* - e.g. feature_user_profile_images |
||
13 | * *fix_* - e.g. fix_map_bug |
||
14 | |||
15 | 3 | Alexander Watzinger | When work on these branches is finished they are merged into the *develop* branch. Around once a month a new version is released where the *develop* branch is merged into the *master* branch. |
16 | 1 | Alexander Watzinger | |
17 | 6 | Alexander Watzinger | When working on a new feature it's a good workflow to begin from the *develop* branch and merge it regularly to keep merge conflicts to a minimum. |
18 | 1 | Alexander Watzinger | |
19 | 6 | Alexander Watzinger | h2. Other branches |
20 | |||
21 | 5 | Alexander Watzinger | There may be some other prefixed branches which won't be merged regularly: |
22 | 1 | Alexander Watzinger | |
23 | * *try_* - if something was tried out and put aside for the moment but may be continued later |
||
24 | * *test_* - special versions that are used to test specific scenarios |
||
25 | 6 | Alexander Watzinger | |
26 | h2. Database changes |
||
27 | |||
28 | If there are database changes make sure that |
||
29 | |||
30 | * there is a comment with the issue number at the sql update script (e.g. at install/upgrade/3.12.0.sql) |
||
31 | * that the issue is noted at util/changelog.py |
||
32 | |||
33 | That way it's easier to deal with updates in the *develop* branch when dealing with multiple new features which need database updates. |