-
Notifications
You must be signed in to change notification settings - Fork 5
/
lifecycle.txt
155 lines (112 loc) · 5.81 KB
/
lifecycle.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
autosub development lifecycle (DLC)
============================================
1. General
2. Branches
3. How to use autosub
4. How to contribute
5. Concerning Feature Branches
============================================
1. General
----------
The following describes the development lifecycle that is used for autosub, in
order to allow developers to work collaboratively. We are basing our lifecycle
on the lifecycle described in
https://nvie.com/posts/a-successful-git-branching-model/ .
The livecycle_model.png gives you a good first overview.
The repository is hosted at GitHub, you can clone it without having an account:
git clone https://github.com/autosub-team/autosub
If you want to contribute, you will need to have an account, there are several
ways to push into a GitHub repository, please refer to GitHub help. In example
for ssh everything is described in detail here:
https://help.github.com/articles/generating-an-ssh-key/
2. Branches
-----------
Since the number of developers is rather small, we stick with a simple
development lifecycle (DLC), which consists of 2 major branches:
-) master : is the stable branch, this is the version that shall currently be
used for deployment, as it is well tested and stable.
-) autosub_devel : thats the development branch, this is the version
developers may directly push smaller changes or merge feature branches
after the feature is working. If you are an outside contributor, this is the
branch to base your pull requests on.
Other branches with limited lifespan:
-) feature branches: developers shall (based on their own judgement) create
feature branches in which they work on larger changes. Only after the whole
feature is developed, the feature branch is merged into autosub_devel, so it
can be tested by all developers. Feature branche are usally just locally
on your machine and not pushed to the autosub repository.
Naming convention: feature-foobar
Branches of from: autosub_devel
Merges into: autosub_devel
-) release branches: Release branches support preparation of a new production
release. They allow for last-minute dotting of i’s and crossing t’s.
Furthermore, they allow for minor bug fixes and preparing meta-data for
a release (e.g updating the static docs, providing a migration script for
autosub instances to the new version). Release branches are merged into
master once the release is ready, the commit tagged in master, and then the
release branch is deleted.
Naming convention: release-X.0
Branches of from: autosub_devel
Merges into: master (squash) , autosub_devel
-) hotfix branches: Hotfix branches are very much like release branches in
that they are also meant to prepare for a new production release, albeit
unplanned. They arise from the necessity to act immediately upon an
undesired state of a live production version. When a critical bug in a
production version must be resolved immediately, a hotfix branch may be
branched off from the corresponding tag on the master branch that marks
the production version. Once the hotfix is ready it is merged into master
and autusub_devel. Additionally the commit is tagged in master with the
minor version number being incremented.
Naming convention: hotfix-X.Y
Branches of from: master
Merges into: master, autosub_devel
Changes minor version number +1
3. How to use autosub
---------------------
The first step is to clone the repository:
$ git clone https://github.com/autosub-team/autosub
After cloning, you are by default on the master branch. If you want to deploy
autosub that is fine, and you may now look at the user manual located in doc_pdf
and start configuring.
4. Contributing
---------------
If you want to contribute to the autosub development fork the autosub repository.
Development is done on the autosub_devel branch.
To get your changes into autosub, commit them to the autosub_devel branch,
commit and push it to your forked repository and send a pull request. A good
tutorial concerning how to do a pull request is:
https://www.thinkful.com/learn/github-pull-request-tutorial/#Time-to-Submit-Your-First-PR
If you find an issue with autosub, feel free to open an issue in the autosub
repository.
5. Concerning Feature Branches
------------------------------
If you are doing bigger changes (more commits, new feature, longer development
time, etc.) please do not commit parts of that bigger change over time, but
create a feature branch that is then merged into autosub_devel after you have
tested everything. The following is way to do exactly that. Assuming you
currently are on branch autosub_devel, please start with a
$ git pull
to assure you start with the current development version.
$ git checkout -b feature-bla autosub_devel
If you want to check if you are on that new branch, just ask git:
$ git branch
autosub_devel
master
* feature-bla
Please note, that branch names should have descriptive names that give an idea
on why that branch was created. So bla should be replaced.
If you want to make your feature branch available to everyone on GitHub you
may do a:
$ git push -u origin feature-bla
This not mandatory though but may be of advantage if you want someone else to
review your experimental changes, or if you are working on several machines
and want all of them to have access to you latest developments.
Now you may work on your feature branch as you are used to (git commit, git push,
git log, etc.).
Once your feature is finished and tested, you want to feed it back into
autosub_devel by merging the feature branch:
$ git checkout autosub_devel
$ git merge feature-bla
Since autosub_devel may have changed in the meantime, it may be necessary to
resolve some conflicts, a detailed description may be found here:
https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#Basic-Merge-Conflicts