pivotal-github 0.5.0 → 0.5.1

Sign up to get free protection for your applications and to get access to all the features.
Files changed (3) hide show
  1. data/README.md +28 -22
  2. data/lib/pivotal-github/version.rb +1 -1
  3. metadata +1 -1
data/README.md CHANGED
@@ -1,8 +1,6 @@
1
1
  # pivotal-github
2
2
 
3
- **NOTE:** This gem is as-yet unreleased.
4
-
5
- This gem facilitates a Pivotal Tracker–GitHub workflow inspired by [Logical Reality](http://lrdesign.com/).
3
+ This gem facilitates a Pivotal Tracker–GitHub workflow inspired by [Logical Reality](http://lrdesign.com/). As per usual, there are several projects (notably [git-flow](https://github.com/nvie/gitflow) and [git-pivotal](https://github.com/trydionel/git-pivotal)) that implement similar solutions, but none met my exact needs.
6
4
 
7
5
  ## Installation
8
6
 
@@ -21,7 +19,11 @@ Or install it yourself as:
21
19
 
22
20
  ## Usage
23
21
 
24
- The `pivotal-github` gem adds several additional Git commands to the local environment.
22
+ The `pivotal-github` gem adds several additional Git commands to the local environment. There is only one non-trivial addition, `git story-commit`; the others are simple (tiny) bash scripts. (In fact, the current Ruby code looks over-engineered: there is a base `Command` class with only one derived class, `StoryCommit`. This is an artifact of history, as there used to be other commands, but I decided that the other cases were better served by plain bash scripts.) The `git story-commit` command automatically incorporates the Pivotal Tracker story id into the commit messages, while adding options to mark the story **Finished** or **Delivered**.
23
+
24
+ The `git story-commit` command makes the assumption that the first string of digits in the branch name is the story id. This means that, when the story id is `6283185`, the branch names `6283185-add-markdown-support`, `6283185_add_markdown_support`, and `add-markdown-support-6283185` all work, but `add-42-things-6283185` doesn't.
25
+
26
+ The full set of commands is as follows:
25
27
 
26
28
  ### git story-commit
27
29
 
@@ -32,6 +34,10 @@ For example, when on a branch called `6283185-add-markdown-support`, the `git st
32
34
  $ git story-commit -am "Add foo bars"
33
35
  [6283185-add-markdown-support 6f56414] [#6283185] Add foo bars
34
36
 
37
+ To mark a story as **Finished**, add the `-f` flag:
38
+
39
+ $ git story-commit -f -am "Remove baz quuxes"
40
+ [6283185-add-markdown-support 7g56429] [Finishes #6283185] Remove baz quuxes
35
41
 
36
42
  Here's the full usage info:
37
43
 
@@ -43,7 +49,7 @@ Here's the full usage info:
43
49
  -a, --all commit all changed files
44
50
  -h, --help this usage guide
45
51
 
46
- Additionally, `git story-commit` accepts any options valid for `git commit`.
52
+ Additionally, `git story-commit` accepts any options valid for `git commit`. (`git story-commit` supports the `-a` flag so that `git story-commit -am "message"` works.)
47
53
 
48
54
  ### git story-push
49
55
 
@@ -51,8 +57,6 @@ Additionally, `git story-commit` accepts any options valid for `git commit`.
51
57
 
52
58
  $ git story-push
53
59
  * [new branch] 6283185-add-markdown-support -> 6283185-add-markdown-support
54
-
55
- this usage guide
56
60
 
57
61
  `git story-push` accepts any options valid for `git push`.
58
62
 
@@ -69,12 +73,12 @@ The purpose of `git story-pull` it to prepare the local story branch for rebasin
69
73
  $ git story-pull
70
74
  $ git rebase master
71
75
 
72
- This is essentially equivalent to
76
+ (This is essentially equivalent to
73
77
 
74
78
  $ git fetch
75
79
  $ git rebase origin/master
76
80
 
77
- but I don't like having `master` and `origin/master` be different since it forces you to remember to run `git pull` on `master` some time down the line.
81
+ but I don't like having `master` and `origin/master` be different since that means you have to remember to run `git pull` on `master` some time down the line.)
78
82
 
79
83
  ### git story-merge
80
84
 
@@ -87,7 +91,7 @@ but I don't like having `master` and `origin/master` be different since it force
87
91
 
88
92
  In order to use the `pivotal-github` gem, you need to configure a [post-receive hook for Pivotal Tracker at GitHub](https://www.pivotaltracker.com/help/api?version=v3#github_hooks) for your repository. (To find your Pivotal Tracker API token, go to your user profile and scroll to the bottom.)
89
93
 
90
- The `pivotal-github` command names follow the Git convention of being verbose (it's telling that, unlike Subversion, Git doesn't natively support `co` for `checkout`), but I recommend setting up aliases as necessary. Here are some suggestions:
94
+ The `pivotal-github` command names follow the Git convention of being verbose (e.g., unlike Subversion, Git doesn't natively support `co` for `checkout`), but I recommend setting up aliases as necessary. Here are some suggestions:
91
95
 
92
96
  $ git config --global alias.sc story-commit
93
97
  $ git config --global alias.sp story-push
@@ -110,34 +114,36 @@ A single-developer workflow would then look like this:
110
114
  $ git rebase master
111
115
  $ git sm
112
116
 
113
- Note that this workflow uses `git sp` (and subsequent invocations of `git push`) only to create a remote storage backup. The principal purpose of `git story-push` is to support the integrated code review workflow described below.
117
+ Note that this workflow uses `git sp` (and subsequent invocations of `git push`) only to create a remote backup. The principal purpose of `git story-push` is to support the integrated code review workflow described below.
114
118
 
115
- ## Workflow
119
+ ## Workflow with integrated code reivew
120
+
121
+ The `pivotal-github` gem is degined to support a workflow involving integrated code review, which has the usual benefits: at least two pairs of eyes see any committed code, and at least two brains know basically what the committed code does. The cost is that having a second developer involved can slow you down. I suggest using your judgment to determine which workflow makes the most sense on a story-by-story basis.
116
122
 
117
- The `pivotal-github` gem is degined to support a workflow that involves integrated code review, which has the usual advantages: at least two pairs of eyes see any committed code, and at least two brains know basically what the committed code does. Here's the process in detail:
123
+ Here's the process in detail:
118
124
 
119
125
  ### Developer #1 (Alice)
120
126
 
121
- 1. Start an issue at [Pivotal Tracker](http://pivotaltracker.com/)
122
- 2. Create a branch in the local Git repository containing the story number and a brief description: `git checkout -b 6283185-add-markdown-support`
127
+ 1. Start an issue at [Pivotal Tracker](http://pivotaltracker.com/) and copy the story id to your buffer
128
+ 2. Create a branch in the local Git repository containing the story id and a brief description: `git checkout -b 6283185-add-markdown-support`
123
129
  3. Create a remote branch at [GitHub](http://github.com/) using `git story-push`
124
130
  3. Use `git story-commit` to make commits, which includes the story number in the commit message: `git story-commit -am "Add syntax highlighting"`
125
131
  4. Continue pushing up after each commit using `git push` as usual
126
- 4. When done with the story, add `-f` to mark the story as finished: `git story-commit -f -am "Add paragraph breaks"`
132
+ 4. When done with the story, add `-f` to mark the story as **Finished** using `git story-commit -f -am "Add paragraph breaks"` or as **Delivered** using `git story-commit -d -am "Add paragraph breaks"`
127
133
  4. Rebase against `master` using `git story-pull` followed by `git rebase master` or `git rebase master --interactive` (optionally squashing commit messages as described in the article [A Git Workflow for Agile Teams](http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html))
128
134
  4. Push up with `git push`
129
- 6. At the GitHub page for the repo, select "Branches" and submit a pull request
135
+ 6. At the GitHub page for the repo, select **Branches** and submit a pull request
130
136
  7. **(experimental)** Add a story of type Chore to Pivotal Tracker and assign it to Developer #2 (Bob)
131
137
 
132
138
 
133
139
  ### Developer #2 (Bob)
134
140
 
135
- 1. Review the pull request diffs
136
- 2. If acceptable, merge the branch
137
- 3. If not acceptable, manually change the state at Pivotal Tracker to Rejected
138
- 4. **(experimental)** If there are conflicts, make a Chore to resolve the conflicts and assign it to Alice
141
+ 1. Select **Pull Requests** at GitHub and review the pull request diffs
142
+ 2. If acceptable, merge the branch by clicking on the button at GitHub
143
+ 3. If not acceptable, manually change the state at Pivotal Tracker to Rejected and leave a note (at GitHub or at Pivotal Tracker) indicating the reason
144
+ 4. **(experimental)** If the branch cannot be automatically merged, make a Chore to resolve any conflicts and assign it to Alice
139
145
 
140
- Until Bob accepts the pull request, Alice can continue working on new stories, taking care to branch off of the current branch if she needs its changes to continue. Note that the commits will appear on the story as soon as Alice creates a remote branch (and as she pushes to it), but it won't be marked 'finished' or 'delivered' until Bob merges the pull request into `master`.
146
+ Until Bob accepts the pull request, Alice can continue working on new stories, taking care to branch off of the current branch if she needs its changes to continue. Note that the commits will appear on the story as soon as Alice creates a remote branch (and as she pushes to it), but it won't be marked **Finished** or **Delivered** until Bob merges the pull request into `master`.
141
147
 
142
148
  ## Merge conflicts
143
149
 
@@ -1,5 +1,5 @@
1
1
  module Pivotal
2
2
  module Github
3
- VERSION = "0.5.0"
3
+ VERSION = "0.5.1"
4
4
  end
5
5
  end
metadata CHANGED
@@ -1,7 +1,7 @@
1
1
  --- !ruby/object:Gem::Specification
2
2
  name: pivotal-github
3
3
  version: !ruby/object:Gem::Version
4
- version: 0.5.0
4
+ version: 0.5.1
5
5
  prerelease:
6
6
  platform: ruby
7
7
  authors: