gergely/taskwarrior-2.x
1
0
Fork 0
Code Issues Actions Packages Projects Releases 1 Wiki Activity

reformat to one sentence per line

Browse Source
This commit is contained in:
Dustin J. Mitchell
2022-04-21 01:15:17 +00:00
committed by Tomas Babej
parent ade706a72e
commit b1ca5d4cf8
17 changed files with 842 additions and 1052 deletions
Download Patch File Download Diff File Expand all files Collapse all files

58
docs/contrib/branching.md
View File

@@ -2,18 +2,16 @@
title: Branching Model
---
Software development typically requires a standardized branching model, to
manage complexity and parallel efforts. The branching model can be a source of
confusion for developers, so this document describes how branching is used.
Software development typically requires a standardized branching model, to manage complexity and parallel efforts.
The branching model can be a source of confusion for developers, so this document describes how branching is used.
Taskwarrior and Taskserver use the same branching model.
## Git Branching
Git allows arbitrary and low-cost branching, which means that any branching
model can be used. A new Git repository has one branch, the default branch,
named `master`, but even this is not required.
Git allows arbitrary and low-cost branching, which means that any branching model can be used.
A new Git repository has one branch, the default branch, named `master`, but even this is not required.
[![master](/docs/images/master.png)](/docs/images/master.png)
@@ -22,9 +20,9 @@ No development occurs on the `master` branch.
## Development Branch
A development branch is created from the `master` branch, and work proceeds on
the development branch. Development branches are pushed to the server. Note that
there are no changes on `master` - all work is done on dev branches.
A development branch is created from the `master` branch, and work proceeds on the development branch.
Development branches are pushed to the server.
Note that there are no changes on `master` - all work is done on dev branches.
[![dev](/docs/images/dev.png)](/docs/images/dev.png)
@@ -33,53 +31,47 @@ All work on dev branches is pushed to the server.
## Topic Branch
A topic branch is created from a dev branch. This can be a useful way to manage
parallel efforts on a single development machine. Topic branches are also useful
for merging in submitted patches, because the patch can be merged, tested and
corrected independently of other efforts before being merged and pushed. A topic
branch is ideal for storage of changes before an eventual merge back to the
development branch.
A topic branch is created from a dev branch.
This can be a useful way to manage parallel efforts on a single development machine.
Topic branches are also useful for merging in submitted patches, because the patch can be merged, tested and corrected independently of other efforts before being merged and pushed.
A topic branch is ideal for storage of changes before an eventual merge back to the development branch.
[![topic](/docs/images/topic.png)](/docs/images/topic.png)
No topic branches are pushed to the server, they are kept local to the
development machine. They are private, and therefore hidden from the server.
No topic branches are pushed to the server, they are kept local to the development machine.
They are private, and therefore hidden from the server.
## Release
When a release is made, the development branch is merged back to the `master`
branch, and a tag is applied that indicates which commit represents the release.
When a release is made, the development branch is merged back to the `master` branch, and a tag is applied that indicates which commit represents the release.
[![release](/docs/images/release.png)](/docs/images/release.png)
Because only releases are merged back, the `master` branch always represent the
stable release.
Because only releases are merged back, the `master` branch always represent the stable release.
## New Development Branches
Immediately after a release, one or more new branches are created. Typically
after a major \'1.0.0\' release, there will be two branches created. First the
\'1.0.1\' branch is a patch development branch, intended to be used if an
emergency patch is required. It therefore sits unused until an emergency arises.
Immediately after a release, one or more new branches are created.
Typically after a major \'1.0.0\' release, there will be two branches created.
First the \'1.0.1\' branch is a patch development branch, intended to be used if an emergency patch is required.
It therefore sits unused until an emergency arises.
No work is performed on a patch development branch.
The second branch, with the higher release number is the development branch for
fixes and features. This is where all the work occurs. Any fix made on the
development branch can be cherry-picked onto the patch branch, if necessary.
The second branch, with the higher release number is the development branch for fixes and features.
This is where all the work occurs.
Any fix made on the development branch can be cherry-picked onto the patch branch, if necessary.
[![dev2](/docs/images/dev2.png)](/docs/images/dev2.png)
To address the confusion around branching, namely determining which branch is
active. the answer is that the highest numbered branch is the one that patches
should be applied to.
To address the confusion around branching, namely determining which branch is active.
the answer is that the highest numbered branch is the one that patches should be applied to.
## Old Branches
Old branches are not retained, but there are tags marking the beginning and end
of development on a branch.
Old branches are not retained, but there are tags marking the beginning and end of development on a branch.
## Rebasing