Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Sign up
Appearance settings

Commit 94a23af

Browse files
Initial README and docs
0 parents commit 94a23af

File tree

7 files changed

+464
-0
lines changed

7 files changed

+464
-0
lines changed

‎.editorconfig‎

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
root = true
2+
3+
[*.adoc]
4+
indent_style = space
5+
indent_size = 2
6+
charset = utf-8
7+
end_of_line = lf
8+
insert_final_newline = true
9+
trim_trailing_whitespace = true
10+
max_line_length = 80

‎LICENSE‎

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
MIT License
2+
3+
Copyright (c) 2018 Raman Gupta
4+
5+
Permission is hereby granted, free of charge, to any person obtaining a copy
6+
of this software and associated documentation files (the "Software"), to deal
7+
in the Software without restriction, including without limitation the rights
8+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9+
copies of the Software, and to permit persons to whom the Software is
10+
furnished to do so, subject to the following conditions:
11+
12+
The above copyright notice and this permission notice shall be included in all
13+
copies or substantial portions of the Software.
14+
15+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21+
SOFTWARE.

‎README.adoc‎

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,12 @@
1+
= Gitworkflow
2+
3+
The https://git.kernel.org/pub/scm/git/git.git/[git.git] project, responsible for the creation and maintenance of the
4+
https://git-scm.com/[git] tool itself, uses an amazing workflow I call "gitworkflow", in deference to its creators
5+
and the https://git-scm.com/docs/gitworkflows[man page] in which it is described.
6+
7+
I describe the advantages of this workflow, in comparison to the popular
8+
http://nvie.com/posts/a-successful-git-branching-model/[GitFlow] by Vincent Drieesen and Adam Ruka's
9+
http://endoflineblog.com/oneflow-a-git-branching-model-and-workflow[OneFlow] in a blog post titled
10+
https://hackernoon.com/how-the-creators-of-git-do-branches-e6fcc57270fb[How the Creators of Git do Branching].
11+
12+
This repository is meant to be a place in which tools and documentation related to gitworkflow can be created.

‎docs/concepts-summary.adoc‎

Lines changed: 122 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,122 @@
1+
= Gitworkflow: Concepts Summary
2+
:toc: macro
3+
4+
toc::[]
5+
6+
== Introduction
7+
8+
An earlier article described https://hackernoon.com/how-the-creators-of-git-do-branches-e6fcc57270fb[Gitworkflow]. This
9+
document expands on some of the concepts in a shorter, more digestible form.
10+
11+
== Concepts
12+
13+
=== Topic Branches
14+
15+
Topic branches, sometimes called feature branches, are where almost all development happens. Topics represent something
16+
being worked on, almost always in a branch, like a bug fix, hot fix, or new functionality.
17+
18+
Name topic branches according to some convention. A good one is your initials, a slash, the issue tracker ID, a dash,
19+
and a (very) brief description in camel-case e.g.:
20+
21+
rg/SP-1234-NewFrobnik
22+
23+
The initials ease communication by immediately identifying the owner. The issue and description are short but also
24+
provide useful context.
25+
26+
By branching from `maint` or `master`, we have the flexibility to merge the topic into branches like `next` or `pu`
27+
because those branches will share the branch point as a common ancestor).
28+
29+
If topic B depends on another topic A that has not yet graduated to `master`, topic A may be merged into topic B. This
30+
complicates interactive branch rebases so this should be avoided when possible, however if necessary, git should handle
31+
this situation without too much problem.
32+
33+
Smaller bugfixes and features may be merged directly into `maint` or `master` without going through a stabilization
34+
period in `next` or `pu`. Changes on `maint` are merged upwards into `master`, and changes on `master` are merged
35+
upwards into `next` and `proposed` (though these branches are more often simply rewound and rebuilt).
36+
37+
=== Integration Branches
38+
39+
The integration branches are described here.
40+
41+
Stable releases are cut from `master`, beta or acceptance test releases from `next`, and alpha or preview releases from
42+
`pu`. `maint` simply represents fixes to the previous release. The most stable up-to-date code is on `master`.
43+
44+
Integration branches are exactly like any other branch in git. What makes them "special" is solely in how we have
45+
defined their use.
46+
47+
==== master
48+
49+
The `master` branch is:
50+
51+
* the code that is most up-to-date and stable
52+
53+
and it has the following properties:
54+
55+
* when creating a named new release, it would come from `master`
56+
* in a continuous deployment scenario, production would always run the tip of `master`
57+
* usually deployed to production, released to users
58+
* at some point, the tip of `master` is tagged with vX.Y.0
59+
* the `maint` branch is always based on some commit on `master`
60+
* never rewound or rebased, *always safe to base topics on*
61+
** you may want to add a check in your git server to ensure force push does not happen on this branch
62+
* new topics are almost always based on `master`
63+
* usually contains all of `maint` (and must before a new release, since otherwise there are changes currently in prod
64+
that won’t be included in the new release)
65+
66+
==== next
67+
68+
The `next` branch is:
69+
70+
* the code currently being developed and stabilized for release
71+
72+
and it has the following properties:
73+
74+
* code merged to `next` is generally in fairly good shape, though perhaps there are regressions or other non-obvious
75+
issues
76+
* usually deployed to a testing environment
77+
at the beginning of every development cycle, rewound to `master`, but otherwise never rewound
78+
* contains all of `master` i.e. always based on the head of `master`
79+
* when a release is made, if a topic branch currently in `next` is not stable enough promotion to `master`, it is
80+
simply not merged to `master` -- instead, it is merged to the next iteration of `next`
81+
* may be rewound to `master` at any time -- but usually after a release
82+
* it is *never* merged into another branch
83+
* new topics are not usually based on `next`
84+
** one exception: if a topic is not expected to be stable for the next release, and the creator understands that
85+
the branch will need to be rebased when `next` is rewound and rebuilt, this is ok and may result in fewer conflicts
86+
during future rebase than if the topic started from `master`
87+
88+
==== pu
89+
90+
The `pu` branch is:
91+
* "proposed" updates for temporary analysis, experimentation, or initial testing/review of one or more features
92+
** anything else that doesn’t yet belong in `next`
93+
94+
and it has the following properties:
95+
96+
* to test / provide early warning whether the unmerged topic branches integrate cleanly -- if not, some communication
97+
to coordinate changes on topics is necessary
98+
* may be rewound to `master` at any time -- but usually once every day or every second day
99+
* it is *never* merged into another branch
100+
* new topics are not usually based on `pu`
101+
102+
==== maint (and maint-X.Y)
103+
104+
The `maint` branch is:
105+
106+
* code that is the newest maintained production release
107+
108+
The `maint-X.Y` branches are:
109+
110+
* code that are older, but still maintained, production releases
111+
112+
and they have the following properties:
113+
114+
* usually deployed directly into production, perhaps with some but not extensive testing elsewhere
115+
* after release of `vX.Y.0` is made, `maint` is set to that commit
116+
* releases of `vX.Y.n` are made from `maint` if `X.Y` is current, or `maint-X.Y` if `X.Y` is an older maintained release
117+
* never rewound or rebased, *always safe to base topics on*
118+
** you may want to add a check in your git server to ensure force push does not happen on this branch, with an exception
119+
for when the `maint` branch is moved to the new tip of `master` after a release
120+
* hotfix topics are merged to `maint` directly
121+
* new topics may be based on `maint` (or `maint-X.Y`) if the fix in the topic needs to be applied to that older release
122+
* can be merged to `master` to propagate fixes forward

‎docs/images/creating-a-topic.png‎

19.1 KB
Loading[フレーム]

‎docs/images/merge-to-pu.png‎

46.4 KB
Loading[フレーム]

0 commit comments

Comments
(0)

AltStyle によって変換されたページ (->オリジナル) /