githole 0.0.1 → 1.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/README.md +162 -13
- data/lib/githole/version.rb +1 -1
- metadata +1 -1
checksums.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
SHA1:
|
|
3
|
-
metadata.gz:
|
|
4
|
-
data.tar.gz:
|
|
3
|
+
metadata.gz: d40bd64feb01ac2601dcf3442887f3e4f67f4ed7
|
|
4
|
+
data.tar.gz: d7ad9808c2201625cf138bd5a4037068b80d848a
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: f5ae0055a3d4405ae43a54e332b1edd8bdaa454ca0d1183408bc599c83095e4d03923853109bf7cb048223c299c9606a6e4d6abd3580cd4df0b04c2d5c3ac5ea
|
|
7
|
+
data.tar.gz: d30b5e7202523c448096f4769956c7acd57d06236dff503031b3eb33f5cf2fe20a87d9a8f20bd59adec3a999178dd6469a084f45b1228ac82b07067aa95f74ac
|
data/README.md
CHANGED
|
@@ -1,28 +1,177 @@
|
|
|
1
|
-
|
|
1
|
+
Githole
|
|
2
|
+
================
|
|
2
3
|
|
|
3
|
-
|
|
4
|
+
Githole is a command line script that serves as a wrapper for several git
|
|
5
|
+
commands, which serve my git workflow.
|
|
4
6
|
|
|
5
|
-
|
|
7
|
+
The Workflow
|
|
8
|
+
----------------
|
|
6
9
|
|
|
7
|
-
|
|
10
|
+
The workflow is designed to help you develop on several, concurrent
|
|
11
|
+
develop/release branches.
|
|
8
12
|
|
|
9
|
-
|
|
10
|
-
|
|
13
|
+
I'm working on an article to better explain this. In the meantime, here's an
|
|
14
|
+
overview.
|
|
15
|
+
|
|
16
|
+
The workflow is similar to [Vincent Driessen's popular git branching
|
|
17
|
+
model](http://nvie.com/posts/a-successful-git-branching-model/), with a few key
|
|
18
|
+
differences:
|
|
19
|
+
|
|
20
|
+
### 1: No `develop` Branch
|
|
21
|
+
|
|
22
|
+
There is no `develop` branch. Instead, the idea of develop, release and hotfix
|
|
23
|
+
branches are rolled into one. In other words, every remote branch (other than
|
|
24
|
+
master) reflects the bleeding edge relevant to the version after which that
|
|
25
|
+
branch is named.
|
|
26
|
+
|
|
27
|
+
### 2: No Merging to Master
|
|
28
|
+
|
|
29
|
+
There should be no commits to the master branch. Ever.
|
|
30
|
+
|
|
31
|
+
Instead, version branches get merged into master (via a pull/merge request) and
|
|
32
|
+
then deleted. You'll need to use a git application (like
|
|
33
|
+
[GitHub](https://github.com/), [Bitbucket](https://bitbucket.org/),
|
|
34
|
+
[GitLab](https://about.gitlab.com/), etc.) to use this method.
|
|
35
|
+
|
|
36
|
+
Pull/merge requests are nice because they encourage you to look through your
|
|
37
|
+
code one more time before bringing into the stable (production-ready) branch.
|
|
38
|
+
|
|
39
|
+
### 3: Keeping History Clean
|
|
40
|
+
|
|
41
|
+
To bring a feature branch up to date (required before you merge into version
|
|
42
|
+
branch), you need to bring in changes from master and the remote version branch
|
|
43
|
+
that you might not have.
|
|
44
|
+
|
|
45
|
+
Instead of *merging* these branches, I *rebase* them. This keeps your commit
|
|
46
|
+
history nice and clean (it's not littered with all these *Merged branch ...*
|
|
47
|
+
commits).
|
|
48
|
+
|
|
49
|
+
Installation
|
|
50
|
+
----------------
|
|
51
|
+
|
|
52
|
+
Since you're likely to use Githole globally on your machine, you'll want to
|
|
53
|
+
install it globally.
|
|
54
|
+
|
|
55
|
+
```text
|
|
56
|
+
$ gem install githole
|
|
11
57
|
```
|
|
12
58
|
|
|
13
|
-
|
|
59
|
+
Usage
|
|
60
|
+
----------------
|
|
14
61
|
|
|
15
|
-
|
|
62
|
+
A `githole` command looks like this:
|
|
16
63
|
|
|
17
|
-
|
|
64
|
+
```text
|
|
65
|
+
$ githole [action] [version]
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
The actions are explained below. For the version, I recommend you use
|
|
69
|
+
[Semantic Versioning](http://semver.org/). You'd simply pass the version you
|
|
70
|
+
want as your second argument.
|
|
71
|
+
|
|
72
|
+
Here's an example:
|
|
73
|
+
|
|
74
|
+
```text
|
|
75
|
+
$ githole add 1.4.1
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
### Add
|
|
18
79
|
|
|
19
|
-
|
|
80
|
+
`add` sets up your version and feature branches. It will check for local
|
|
81
|
+
version branches and figure out if it needs to pull or not.
|
|
20
82
|
|
|
21
|
-
|
|
83
|
+
Let's say you're going to work on v1.4.1. You would set it up by running:
|
|
22
84
|
|
|
23
|
-
|
|
85
|
+
```text
|
|
86
|
+
$ githole add 1.4.1
|
|
87
|
+
```
|
|
88
|
+
|
|
89
|
+
This creates a *version branch* -- `v1.4.1` -- and a *local feature branch* --
|
|
90
|
+
`local-v1.4.1`.
|
|
91
|
+
|
|
92
|
+
> **This workflow is specifically designed so you do not work in feature
|
|
93
|
+
> branches. You only merge into them.**
|
|
94
|
+
|
|
95
|
+
This command runs the following commands:
|
|
96
|
+
|
|
97
|
+
```text
|
|
98
|
+
$ git checkout -b v1.4.1
|
|
99
|
+
$ git pull origin v1.4.1 # if remote branch already exists
|
|
100
|
+
$ git push origin v1.4.1
|
|
101
|
+
$ git checkout -b local-v1.4.1
|
|
102
|
+
```
|
|
103
|
+
|
|
104
|
+
> There are a few checks worked in here so we don't try to create branches that
|
|
105
|
+
> already exist.
|
|
106
|
+
|
|
107
|
+
### Update
|
|
108
|
+
|
|
109
|
+
You should run update if you want to bring in changes that others have pushed
|
|
110
|
+
to origin.
|
|
111
|
+
|
|
112
|
+
While you can run this command at any time, I recommend at least doing it when
|
|
113
|
+
you begin a dev session.
|
|
114
|
+
|
|
115
|
+
```text
|
|
116
|
+
$ githole update 1.4.1
|
|
117
|
+
```
|
|
118
|
+
|
|
119
|
+
This runs the following commands
|
|
120
|
+
|
|
121
|
+
```text
|
|
122
|
+
$ git checkout master
|
|
123
|
+
$ git pull origin master
|
|
124
|
+
$ git checkout v1.4.1
|
|
125
|
+
$ git pull origin v1.4.1
|
|
126
|
+
$ git rebase master
|
|
127
|
+
$ git checkout local-v1.4.1
|
|
128
|
+
$ git rebase v1.4.1
|
|
129
|
+
```
|
|
130
|
+
|
|
131
|
+
> There are a few checks worked in here to ensure these branches exist before
|
|
132
|
+
> we try to do anything with them.
|
|
133
|
+
>
|
|
134
|
+
> If they don't exist, we create and update them. In that way, it also
|
|
135
|
+
> encompasses `add` (but don't use it as a replacement).
|
|
136
|
+
|
|
137
|
+
### Push
|
|
138
|
+
|
|
139
|
+
Push first runs the update action, then pushes up to origin. Therefore, *you
|
|
140
|
+
don't have to run `update` before you run `push`.*
|
|
141
|
+
|
|
142
|
+
```text
|
|
143
|
+
$ githole push 1.4.1
|
|
144
|
+
```
|
|
145
|
+
|
|
146
|
+
In addition to the update commands, we run:
|
|
147
|
+
|
|
148
|
+
```text
|
|
149
|
+
$ git checkout v1.4.1
|
|
150
|
+
$ git merge local-v1.4.1
|
|
151
|
+
$ git push origin v1.4.1
|
|
152
|
+
$ git checkout local-v1.4.1
|
|
153
|
+
```
|
|
154
|
+
|
|
155
|
+
### Remove
|
|
156
|
+
|
|
157
|
+
Remove will simply delete your local branches when you're done. I suggest you
|
|
158
|
+
delete remote branches through your app's UI, just so you can use it as another
|
|
159
|
+
way to check yourself.
|
|
160
|
+
|
|
161
|
+
```text
|
|
162
|
+
$ githole remove 1.4.1
|
|
163
|
+
```
|
|
164
|
+
|
|
165
|
+
The remove action runs these commands:
|
|
166
|
+
|
|
167
|
+
```text
|
|
168
|
+
$ git checkout master
|
|
169
|
+
$ git branch -D v1.4.1
|
|
170
|
+
$ git branch -D local-v1.4.1
|
|
171
|
+
```
|
|
24
172
|
|
|
25
|
-
|
|
173
|
+
Contributing
|
|
174
|
+
----------------
|
|
26
175
|
|
|
27
176
|
1. Fork it ( https://github.com/[my-github-username]/githole/fork )
|
|
28
177
|
2. Create your feature branch (`git checkout -b my-new-feature`)
|
data/lib/githole/version.rb
CHANGED