githole 0.0.1 → 1.0.0
Sign up to get free protection for your applications and to get access to all the features.
- 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