There is a commit A
(- initial commit
in this example) in a branch that we release from (master
in this example).
In the state commit A
there is cirtait state of code and the version is 1.0.0-SNAPSHOT
.
We assume there was release candidate built and deployed, let's say to DEV
by CI/CD triggered by the commit A
.
After cirtain period of time (needed to check the RC and to decide to ship it), the shipit
manual CI/CD step is triggered.
This process needs to:
- set version to the release version (
1.0.0
in this example) - commitS1
(- setting release version
in this example) - tag the source base with a release tag (
v1.0.0
in this example) - bump and set version to snapshot (
1.1.0-SNAPSHOT
in this example) - commitS2
(- setting next snapshot version
in this example) - incorporate these changes into
master
Aditional complication that we want to care about, is that between commit A
and shipit
step there was another
commit that happenned on master
branch, commit B
that modified the code (- updated code
in this example).
We have to make sure that the state of the master
after shipit
step finishes, satisfies the following:
- the tag
v1.0.0
marks the state of the code as ofA
and version1.0.0
master
at commitS1
has the code as ofA
(not updated code fromB
) and version1.0.0
master
at commitS2
has the code as ofA
(not updated code fromB
) and version1.1.0-SNAPSHOT
master
at commitB
includes the updated code and next snapshot version1.1.0-SNAPSHOT
rebase
master ontoshipit
-
- see the result in the
mater-rebased
- see the result in the
-
- looks exactly what we need
-
- drawbacks - rebasing
master
is wrong
- drawbacks - rebasing
merge
shipit
intomaster
-
- see the result in the
mater-merged
- see the result in the
-
- looks exactly what we need
-
- drawbacks - extra merge commit, no other nopticed