-
Notifications
You must be signed in to change notification settings - Fork 16
/
wiki.txt
153 lines (111 loc) · 4.3 KB
/
wiki.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
== Workflow ==
=== Branches of the same repository ===
This assumes that all developers have write access to the project repository and therefore it is suitable for smaller projects/teams.
The features, bugfixes... are implemented in separate branches, the code review is done by pull requests from branches to the master.
```bash
# checkout the project
git clone [email protected]:user_name/repository_name.git
# create a new feature branch
git review prepare
# iteratively work on the feature, commit small parts
<change the code>
git add
git commit
# integrate latest changes from the master
git checkout master
git pull
git rebase master new_feature
# optionally push the changes to GitHub (to enable co-workers to contribute).
git push origin new_feature
# initiate code review by sending a pull request
git review create
```
Alternatively, you can also just work on master and let git-review create the necessary branches for you.
Once you call ```git review create``` all commits that have not yet been pushed to remote will be moved to a new branch.
The only thing you'll have to do is provide a name for that branch.
```bash
# checkout the project
git clone [email protected]:user_name/repository_name.git
# iteratively work on the feature, commit small parts
<change the code>
git add
git commit
# integrate latest changes from the master
git pull
# initiate code review by sending a pull request
git review create
```
Now one of your co-workers should review your code:
```bash
# get a list of all open pull requests.
git review list
# review a specific pull request
git review show ID --full
# to show the pull request in the browser (and be able to add comments)
git review browse ID
# get a local copy of the code
git review checkout ID
# add an approving comment
git review approve ID
# decline patches and close request
git review close ID
# accept pull request and merge it
git review merge ID
git push
```
Once your code has been merged, you can delete obsolete branches:
```bash
# remove both local and remote branch for that review
git review clean ID
# remove all obsolete branches
git review clean --all
```
=== Different forks of a project ===
```bash
# fork the project on GitHub.
# checkout the forked project
git clone [email protected]:user_name/repository_name.git
# create a new feature branch
git review prepare
# iteratively work on the feature, commit small parts
<change the code>
git add
git commit
# integrate latest changes from the master
# NOTE: depending on your setup, you might want to add a remote for upstream and pull from there.
# future versions of git-review will provide a command to set this up for you automatically.
git checkout master
git pull
git rebase master new_feature
# optionally push the changes to GitHub (to enable co-workers to contribute).
git push origin new_feature
# initiate code review by sending a pull request to the upstream project.
git review create --upsteam
```
Alternatively, you can also just work on master and let git-review create the necessary branches for you.
Once you call ```git review create --upstream``` all commits that have not yet been pushed to remote will be moved to a new branch.
The only thing you'll have to do is provide a name for that branch.
```bash
# checkout the forked project
git clone [email protected]:user_name/repository_name.git
# iteratively work on the feature, commit small parts
<change the code>
git add
git commit
# integrate latest changes from the master
git pull
# initiate code review by sending a pull request
git review create --upstream
```
For the upstream repository, reviewing your pull request is the same as before.
== Hints ==
=== Overriding the default target branch (= master) ===
If you want to use a branch other than master to merge to, you can do so by setting an ENV variable.
```bash
TARGET_BRANCH=develop git review merge 42
```
Alternatively you can set that variable globally, of course.
Thanks go to to [https://github.com/swalberg swalberg] for this nifty little feature.
== TODOs ==
There are still a couple of TODOs on the list. If you want to contribute, feel free to work on one of these. However, it would be nice if you could tell me about it, such that we don't duplicate our work.
Check out this repo's issues section if you want to know the details of what is currently worked on or add some issues you found yourself.