-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathREADME
127 lines (91 loc) · 5.53 KB
/
README
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
git series create 1.1
git series
git release 1.1
git release 1.1
- automatically determine the next release and tag it
git release 1.1 -n 4 (skip a micro)
git release 1.1 [commit] - where to put the tag
git series delete
git series rename
git series propagate 1.1 1.2
-u propagate unreleased commits
invariants:
- newer releases should be descendants of older releases
- newer series should be descendants of older series (or unrelated)
why no git-flow?
- master screws things up
- need to be able to support older released versions (releases)
- cleaner git history... better support for parallel development
git series propagate <from-series> <to-series>
- no noop argument because it can cause problems (maybe allow only the first one to use the noop flag, that way
the merges can still pick up unpropagated changes on the intermediate series)
Think about adding "next" or "develop" branch instead of current series.
When creating a release, attempt to propagate the changes to all downstream series. Once that's complete, apply the tag.
If it fails, refuse to put the tag.
propagate is idempotent. When the user runs into a merge conflict or anything like that, the process will have to stop.
They should be able to run the same command again and the work that they already did should automatically fly by, getting
them to where they left off.
Propagate always cascades to downstream releases (i.e., 1 -> 2, 2 -> 3, 3 -> 4 instead of 1 -> 2, 1 -> 3, 1 -> 4)
Have a way to propagate from a specific commit down (i.e., leave some commits unpropagated)
Best Practices
- propagate asap so that the guy who comes along behind you doesn't have to figure out if your changes should be propagated
- don't put older releases as descendants of newer releases
Propagation needs to go from release branch to all open successor release branches, then to the series branch, then
do the same for each successor series (propagate to the open release branches from oldest to newest, then to all the
series).
What about creating PRs for propagations instead of just merging them automatically?
Propagate interactive? Like rebase interactive. Show the user all open successor branches (eligible for propagation)
and then allow them to choose
1) propagate (merge the changes onto this branch)
2) exclude (do a null merge of these changes onto this branch)
3) defer (do no merge to this branch - someone will have to do it later or it will just get more confusing)
Define sort order of branches: release in order, then series branch
The artifact version
- when on a branch:
- "develop" - the next implied series + SHA + "SNAPSHOT"
- release - the release version + SHA + "SNAPSHOT"
- series - the series version + SHA + "SNAPSHOT"
- when on a commit with a release tag:
- the release version
- when on any other commit
- oldest branch + distance + SHA + "SNAPSHOT"
- "oldest branch" is the first branch in sorted order that has the current commit as an ancestor
- is "distance" actually useful here? Gives you an idea of how old it is at a glance, but does that matter?
- if not on a commit: "0.1-SNAPSHOT"
release open 3.4.5 (create a release branch at this location)
- series 3.4 must be an ancestor
- release 3.4.5 must not exist
- release 3.4.4 should exist and be an ancestor
release close 3.4.5 (create a tag at the head of the release branch and delete the branch - or specified)
- release branch 3.4.5 should exist
- release branch 3.4.4 should be an ancestor (this means propagations are up-to-date and is recursive)
- release branch should not have any open topic branches against it
release tag 3.4.5 (create a release tag for this version at the head of the release branch - or specified)
- requires all of the requirements of open and close (since it's essentially one right after the other)
release list
- lists all known releases
Topic branches are created on any valid branches (series or release) and will be merged back into the same branch.
Changes will also be propagated to all successive branches. You should do the work on the oldest series that will
receive the changes.
topic open 3.4 blah (create a topic branch 'blah' for series 3.4 at the head or specified location)
topic close 3.4 blah (merge the topic branch 'blah' back into series 3.4)
topic open 3.4.5 blah (create a topic branch 'blah' on release branch 3.4.5)
- there must be a release branch 3.4.5 (release 3.4.5 must be open)
- there must not already be a topic branch with the same name on the same release
topic close 3.4.5 blah (merge the topic branch 'blah' into release branch 3.4.5 and delete it)
- release branch 3.4.5 must exist
- topic branch 3.4.5 must exist
NO: topic release delete - just use "git tag -d" (not recommended)
NO: topic abort 3.4.5 blah (delete the topic branch) - just use "git branch -D"
git propagate
usage: git propagate [-d] [-n] [-c from-commit] [-t through-series] <from-series>
Propagate changes from an older series to one or more newer series.
Options:
-c the commit to propagate from (must be on the "from" series, defaults to the series itself)
-d skip develop (defaults to propagating to the develop branch after all series, if it exists)
-n no-op propagation (exclude the series commits from future series, only affects the first merge)
-t the series to propagate through to before stopping (defaults to fully propagating)
topic get 3.4.5 blah (get the ref for the specified topic branch, if it exists)
git series rename
- can not be done if there are any closed releases
- renames all open releases + topics + the series itself