Skip to content
Newer
Older
100644 513 lines (336 sloc) 17.7 KB
97d08bb @leto [docs] How to Maintain a Fork on Github
leto authored
1 # Copyright (C) 2010-2011, Parrot Foundation.
caddb4d @leto [docs] Beginning of a Git Workflow document
leto authored
2
3 =head1 NAME
4
5 docs/project/git_workflow.pod - How to use Git to work on Parrot
6
7 =head1 DESCRIPTION
8
9 To minimize the disruption of feature development on language and tool
10 developers, all major changes to Parrot core take place in a branch. Ideally,
7713372 @chromatic Fixed some typos; linked to merge review docs.
chromatic authored
11 branches are short-lived, and contain the smallest set of changes possible. It
12 is also good practice to have "atomic" commits, in the sense that each commit
13 does one thing, so that it makes it easier to accept/revert some things while
14 keeping others. Git provides many powerful tools in the maintenance of
15 branches. This document aims to provide everything a Parrot developer needs to
16 know about Git to successfully create a branch, work on it, keep it in sync
eb3d7a9 @dbolser Edited docs/project/git_workflow.pod via GitHub
dbolser authored
17 with changes on master and finally merge the branch (or send a pull request).
caddb4d @leto [docs] Beginning of a Git Workflow document
leto authored
18
729270c @leto [docs] Add a section about cloning the parrot git repo
leto authored
19 =head2 Cloning the Git Repository
20
7713372 @chromatic Fixed some typos; linked to merge review docs.
chromatic authored
21 To get the full version history of Parrot, which is called "cloning a
22 repository", you will use the C<git clone> command. This will show how to clone
23 the repo from L<http://github.com>:
729270c @leto [docs] Add a section about cloning the parrot git repo
leto authored
24
0f4c968 @leto [doc] Improve Git Workflow
leto authored
25 git clone git://github.com/parrot/parrot.git
729270c @leto [docs] Add a section about cloning the parrot git repo
leto authored
26
27 If you have commit access to parrot.git, then you can use the read/write SSH
28 protocol
29
0f4c968 @leto [doc] Improve Git Workflow
leto authored
30 git clone git@github.com:parrot/parrot.git
729270c @leto [docs] Add a section about cloning the parrot git repo
leto authored
31
32 If you are behind a firewall that will only let you do HTTP, you can use the
33 HTTP protocol, but it is much slower and inefficient, so only use it if you
34 must:
35
0f4c968 @leto [doc] Improve Git Workflow
leto authored
36 git clone http://github.com/parrot/parrot.git
729270c @leto [docs] Add a section about cloning the parrot git repo
leto authored
37
38 Cloning a git repo automatically makes the URL that you cloned from your
39 default "remote", which is called "origin". What this means is that
40 when you want to pull in new changes or push changes out in the future,
41 "origin" is what will be used by default.
42
caddb4d @leto [docs] Beginning of a Git Workflow document
leto authored
43 =head2 Creating and Switching Branches
44
45 To create a branch and check it out, use the C<git checkout -b> command.
c9e894f @leto [doc] Info about pushing git branches and tags
leto authored
46 Please note that branches are first created locally, and then pushed
47 to any number of remotes. A branch cannot be seen by anyone else
48 until it is pushed to a remote.
49
97d08bb @leto [docs] How to Maintain a Fork on Github
leto authored
50 Branches in git are very "light-weight", i.e. they take up virtually
51 no extra space (unlike in Subversion), so please use them liberally.
52
caddb4d @leto [docs] Beginning of a Git Workflow document
leto authored
53 Current convention is to create branch names of the form username/foo.
54
0f4c968 @leto [doc] Improve Git Workflow
leto authored
55 git checkout -b username/foo
caddb4d @leto [docs] Beginning of a Git Workflow document
leto authored
56
57 You can also create a branch without checking it out:
58
0f4c968 @leto [doc] Improve Git Workflow
leto authored
59 git branch username/foo
caddb4d @leto [docs] Beginning of a Git Workflow document
leto authored
60
61 To checkout (or "switch to", as it is commonly referred to) the username/foo
62 branch:
63
0f4c968 @leto [doc] Improve Git Workflow
leto authored
64 git checkout username/foo
caddb4d @leto [docs] Beginning of a Git Workflow document
leto authored
65
7713372 @chromatic Fixed some typos; linked to merge review docs.
chromatic authored
66 If you would like to checkout a branch that already exists, first make sure to
67 get the latest commits with:
df599f5 @leto [doc] Describe how to track remote branches in elderly Gits
leto authored
68
69 git fetch
70
71 Then use this syntax to track the remote branch with a local branch:
72
f3351c3 @dbolser Isn't it cleaner (and also backwards compatible) to recommend:
dbolser authored
73 git checkout -t origin/username/foo
df599f5 @leto [doc] Describe how to track remote branches in elderly Gits
leto authored
74
75 If you are using a very old version of Git, such as 1.5.x.x or older, you will
76 want to tell it to track the remote branch:
77
20ae439 @nwellnhof [doc] Fix order of git command line options
nwellnhof authored
78 git checkout --track -b username/foo origin/username/foo
df599f5 @leto [doc] Describe how to track remote branches in elderly Gits
leto authored
79
80 Tracking remote branches is the default in Git 1.6.x.x and higher.
81
c9e894f @leto [doc] Info about pushing git branches and tags
leto authored
82 =head2 Pushing branches and tags
83
84 If you want to push your local branch user/branch to origin:
85
86 git push origin user/branch
87
88 Tags are not pushed by default. If you want to push your tags to origin:
89
90 git push origin --tags
91
92 Since origin is the default remote, this is the same as
93
94 git push --tags
95
96 =head2 Keeping branches updated
9c1a4ec @leto [docs] Add a Git Terminology document and add a section to the workfl…
leto authored
97
98 To get the latest updates:
99
0f4c968 @leto [doc] Improve Git Workflow
leto authored
100 git fetch
9c1a4ec @leto [docs] Add a Git Terminology document and add a section to the workfl…
leto authored
101
102 This copies the index from your default remote (origin) and saves it to your
2ae1da4 @leto [doc] Add clarifying sentence to git workflow
leto authored
103 local index. This does not effect your working copy, so it doesn't matter
104 what branch you are on when you run this command. To sync up your working
9c1a4ec @leto [docs] Add a Git Terminology document and add a section to the workfl…
leto authored
105 copy, you can use C<git rebase>
106
0f4c968 @leto [doc] Improve Git Workflow
leto authored
107 git checkout master # Switch to the master branch
108 git rebase origin/master # rebase latest fetched changes onto master
9c1a4ec @leto [docs] Add a Git Terminology document and add a section to the workfl…
leto authored
109
110 This is a common action, so there is also a simpler way to do it:
111
0f4c968 @leto [doc] Improve Git Workflow
leto authored
112 git pull --rebase
9c1a4ec @leto [docs] Add a Git Terminology document and add a section to the workfl…
leto authored
113
114 Whenever you don't specify a remote or branch to a git command, they default
115 to the remote called "origin" and the master branch, so the previous command
116 means exactly the same as:
117
0f4c968 @leto [doc] Improve Git Workflow
leto authored
118 git pull --rebase origin master
119
120 This is important to note when you are working with remotes other than origin,
121 or other branches.
9c1a4ec @leto [docs] Add a Git Terminology document and add a section to the workfl…
leto authored
122
5e8ba83 @leto [docs] Add section about committing to git workflow
leto authored
123 =head2 How to commit
124
7713372 @chromatic Fixed some typos; linked to merge review docs.
chromatic authored
125 Let's say you modified the file foo.c and added the file bar.c and you want to
126 commit these changes. To add these changes to the staging area (the list of
127 stuff that will be included in your next commit):
5e8ba83 @leto [docs] Add section about committing to git workflow
leto authored
128
0f4c968 @leto [doc] Improve Git Workflow
leto authored
129 git add foo.c bar.c
5e8ba83 @leto [docs] Add section about committing to git workflow
leto authored
130
2b2dc13 @leto [doc] Improve our Git workflow
leto authored
131 The command C<git add> is not only for adding new files, just keep that in
132 mind. It tells git "add the *current* state of these files to my staging
133 area." If these files change after you C<git add> them, they will need to be
134 added again.
5e8ba83 @leto [docs] Add section about committing to git workflow
leto authored
135
d2c3de0 @leto [t] Add some info about git add --force
leto authored
136 If you are trying to add files that are in .gitignore, you can do that with
137 the --force flag:
138
139 git add --force ports/foo
140
7713372 @chromatic Fixed some typos; linked to merge review docs.
chromatic authored
141 NOTE: Make sure these files should actually be added. Most files in .gitignore
b9261ad @cotto large batch of typo fixes, courtesy of pfusik++
cotto authored
142 should never be added, but some, such as some files in "ports/" will need
7713372 @chromatic Fixed some typos; linked to merge review docs.
chromatic authored
143 the --force flag.
d2c3de0 @leto [t] Add some info about git add --force
leto authored
144
7713372 @chromatic Fixed some typos; linked to merge review docs.
chromatic authored
145 Now for actually creating your commit! Since Git is a distributed version
146 control system, committing code is separate from sending your changes to a
147 remote server. Keep this in mind if you are used to Subversion or similar
148 VCS's, where committing and sending changes are tied together.
5e8ba83 @leto [docs] Add section about committing to git workflow
leto authored
149
0f4c968 @leto [doc] Improve Git Workflow
leto authored
150 git commit -m "This is an awesome and detailed commit message"
5e8ba83 @leto [docs] Add section about committing to git workflow
leto authored
151
152 If you do not give the -m option to C<git commit>, it will open your $EDITOR
153 and give you metadata which will help you write your commit message,
154 such as which files changed and if conflicts happened. Only lines that do
155 not begin with a # will be in your commit message.
156
2818298 @leto [docs] Add paragraph about commit messages to git workflow
leto authored
157 Commit messages consist of a one line "short message" and an optional long
158 message that can be as long as you like. There must be an empty line between
159 the short message and the long message. It is often a good practice to keep the
160 first line of a commit message relatively short, around 50 characters. This
161 allows for tools to succinctly display one-line commit messages with metadata.
162 It is good practice to describe *why* something was done in the long message,
163 in addition to what was done.
5e8ba83 @leto [docs] Add section about committing to git workflow
leto authored
164
5228f44 @leto [docs] Improve some git docs and formatting
leto authored
165 Instead of adding files individually, you can also tell C<git commit> that
166 you want all modified and deleted files to be in your next commit via the
167 C<-a> flag:
168
169 git commit -a -m "awesome and informative commit message"
170
2231f2f @jkeenan Correct spelling error.
jkeenan authored
171 Be careful with C<git commit -a>, it could add files that you do not mean
5228f44 @leto [docs] Improve some git docs and formatting
leto authored
172 to include. Verify that the contents of your most recent commit look sane with:
173
174 git show
175
176 Reading the man page of C<git commit> with C<git help commit> is also
177 a good idea.
178
caddb4d @leto [docs] Beginning of a Git Workflow document
leto authored
179 =head2 Maintaining a Branch
180
0f4c968 @leto [doc] Improve Git Workflow
leto authored
181 To update your local git index from origin:
182
5228f44 @leto [docs] Improve some git docs and formatting
leto authored
183 git fetch
0f4c968 @leto [doc] Improve Git Workflow
leto authored
184
7713372 @chromatic Fixed some typos; linked to merge review docs.
chromatic authored
185 If you are following multiple remotes, you can fetch updates from all of them
186 with:
0f4c968 @leto [doc] Improve Git Workflow
leto authored
187
5228f44 @leto [docs] Improve some git docs and formatting
leto authored
188 git fetch --all
0f4c968 @leto [doc] Improve Git Workflow
leto authored
189
190 Note that this command requires a recent (1.7.x.x) version of git.
191
7713372 @chromatic Fixed some typos; linked to merge review docs.
chromatic authored
192 The command C<git fetch> only modifies the index, not your working copy or
193 staging area. To update your working copy of the branch bobby/tables:
0f4c968 @leto [doc] Improve Git Workflow
leto authored
194
195 git checkout bobby/tables # make sure we are on the branch
196 git rebase origin/bobby/tables # get the latest sql injections
197
7713372 @chromatic Fixed some typos; linked to merge review docs.
chromatic authored
198 If you have a topic branch and want to pick up the most recent changes in
199 master since the topic branch diverged, you can merge the master branch into
200 the topic branch. In this case, we assume the topic branch is called
201 parrot/beak:
0f4c968 @leto [doc] Improve Git Workflow
leto authored
202
1f7b124 @leto [doc] Clarification about merging git branches
leto authored
203 git checkout parrot/beak # make sure we are on the branch
204 git merge master # merge master into parrot/beak
205
206 This same pattern can be followed for merging any branch into another
207 branch.
0f4c968 @leto [doc] Improve Git Workflow
leto authored
208
caddb4d @leto [docs] Beginning of a Git Workflow document
leto authored
209 =head2 Preparing to Merge a Branch
210
211 Post to parrot-dev@lists.parrot.org letting people know that you're about to
7713372 @chromatic Fixed some typos; linked to merge review docs.
chromatic authored
212 merge a branch. Follow the guidelines in
213 L<docs/project/merge_review_guidelines.pod>, especially:
caddb4d @leto [docs] Beginning of a Git Workflow document
leto authored
214
215 =over
216
217 =item 1
218
cc92939 @leto [doc] More tweaks to the git workflow
leto authored
219 Ask people to submit test results for their language, tool, or platform. They
220 can submit results to Smolder by typing "make smoke" on the relevant branch. If
caddb4d @leto [docs] Beginning of a Git Workflow document
leto authored
221 you don't hear back from people, it doesn't mean they ran the tests and found
222 no problems, it means they didn't bother testing the branch. If you need
223 feedback on a particular language or platform, follow up with the person
224 responsible until you hear an explicit "Yes, it's working" answer.
225
226 =item 2
227
228 Let people know what tests you ran, so they can determine if you didn't run
229 the tests for their language or tool (or, didn't run I<all> the tests for
230 their language or tool if they have some unusual testing configuration).
231
232 =item 3
233
234 Mention any significant feature changes in the branch that you particularly
235 want tested.
236
237 =back
238
8df50db @leto [doc] Add section about the amazing new merge_pull_request.pl
leto authored
239 =head2 Merging a Github Pull Request
240
241 If someone has sent the Parrot Github Organization a pull request, life is a
242 bit easier now. If pull request #123 has been sent, then type:
243
244 perl tools/dev/merge_pull_request.pl 123
245
246 and you will automatically be on a branch called pull_request_123 with all
247 commits in the pull request applied as individually signed-off commits. Now
248 you can review the code, run tests, etc and vet the code. You can even type
249
250 git checkout -b way_cooler_branch_name
251
252 if you want a more informative branch name than the autogenerated one.
253
254 If you want to merge this code to master, you then type
255
256 git checkout master
257 git merge --no-ff pull_request_123
258
259 Don't forget to close the pull request manually, since signing off on the
260 commits changes their SHA1s, which means Github can't detect the merge and
261 autoclose the pull request. That's it!
262
263
caddb4d @leto [docs] Beginning of a Git Workflow document
leto authored
264 =head2 Merging a Branch
265
e351818 @leto [docs] Add a branch merging section to git workflow
leto authored
266 When you're ready to merge your changes back into master, use the C<git merge>
7713372 @chromatic Fixed some typos; linked to merge review docs.
chromatic authored
267 command. First, make sure you are on the master branch with:
1f7b124 @leto [doc] Clarification about merging git branches
leto authored
268
269 git checkout master
270
271 Now, to merge the branch user/foo into master:
e351818 @leto [docs] Add a branch merging section to git workflow
leto authored
272
882b414 @leto [doc] Explain why we should use --no-ff when merging to master
leto authored
273 git merge --no-ff user/foo
e351818 @leto [docs] Add a branch merging section to git workflow
leto authored
274
275 If the same part of the same file has been modified in master and the branch
276 user/foo, you will get a conflict. If you get a conflict, then you need to edit
277 each file with a conflict, fix the conflict, delete the conflict markers, C<git
278 add> each conflicted file and then finally commit the result. You may find it
279 useful to type C<git commit> with no commit message argument (-m), so your
280 $EDITOR will be opened and a default commit message of "Merged branch user/foo
281 into master" with a list of conflicted files will be present, which can be left
282 alone or additional information can be added.
283
c9e894f @leto [doc] Info about pushing git branches and tags
leto authored
284 At this point you should run the test suite on the merged branch, and fix
285 any failures if possible. If these problems cannot be resolved, then
286 the results of the merge should not be pushed back to master on origin.
287 You may want to push a topic branch to allow other people to help:
288
289 git checkout -b user/foo_in_master
290 git push origin user/foo_in_master
291
cc92939 @leto [doc] More tweaks to the git workflow
leto authored
292 You can now mention the problems you ran into to parrot-dev or #parrot
293 and mention the branch.
294
882b414 @leto [doc] Explain why we should use --no-ff when merging to master
leto authored
295 Why use "--no-ff" ? This flag mean "no fast forwards". Usually fast forwards
296 are good, but if there is a branch that has all the commits of master, plus
297 a few more, when you merge without --no-ff, there will be no merge commit.
7713372 @chromatic Fixed some typos; linked to merge review docs.
chromatic authored
298 Git is smart enough to "fast forward." But for the purpose of looking at
882b414 @leto [doc] Explain why we should use --no-ff when merging to master
leto authored
299 history, Parrot would like to always have a merge commit for a merge, even
300 if it *could* be fast-forwarded.
301
302 This flag is only needed when merging branches into master. It is optional
303 for other merge cases, but it won't hurt. If it is simpler to think about,
304 you can always use "--no-ff" when merging.
305
97d08bb @leto [docs] How to Maintain a Fork on Github
leto authored
306 =head2 Maintain A Fork
307
308 If you fork Parrot on github, you will have a copy of the entire history
309 of Parrot, which you can sync with the main parrot git repo as often as
310 you want.
311
312 First Rule:
313
314 Don't Commit To Master In Your Fork
315
316 Create a branch (with git checkout -b branch) and do any development in that.
317
318 Next, you will add the main parrot.git repo as a remote called "upstream"
319
320 git remote add upstream git://github.com/parrot/parrot.git
321
322 You may call this remote anything you like, but for the purposes of this
323 document, we will always refer to is as "upstream".
324
325 We now want to get a copy of the index from upstream. If you are using
326 a recent git (1.7.x.x or higher) you can update your copy of the index
327 of all remotes with
328
329 git fetch --all
330
331 If you have an elderly git, you can give the fetch command the name of
332 the remote to fetch:
333
334 git fetch upstream
335
336 Now you need to update your working copy, and specifically, the master
337 branch, so make sure you are on the master branch of your fork
338
339 git checkout master
340
341 and then sync up with upstream master
342
343 git rebase upstream/master
344
345 There is no possibility of conflicts here *if you didn't commit to master*.
346 If you get conflicts at this step, you are doing something wrong. Stop
347 and ask someone for help.
348
349 It is in your best interest to sync up your master branch with upstream before
350 creating new branches from master, since that will minimize the possibilities
351 of conflicts when merging the branch back to master later on.
352
353 Second Rule:
354
355 Don't Rebase Branches Against Each Other
356
357 For instance, if you are on branch 'foo' and you do
358
359 git rebase upstream/master
360
361 you will be entering a world of pain. Don't do it. If you are smart
362 enough to know when it is OK to do this, you don't need this document.
363
364 This workflow to maintain a fork will make submitting pull requests
365 "Just Work" and if you plan to submit pull requests, this workflow
366 is required. If you don't want to submit pull requests, do whatever
367 ye will.
368
8efa315 @leto [docs] Add docs for merging Github pull requests
leto authored
369 =head2 Merging Code From Forks
370
559ed82 @leto [docs] Get rid of lies and add a NOTE about unofficialness
leto authored
371 NOTE: This is not official policy, and could change at any time.
372
2b2dc13 @leto [doc] Improve our Git workflow
leto authored
373 ALSO NOTE: With the introduction of the magical Github Merge Button, doesn't
374 this seem like a ridiculous amount of work to accept code from a fork? This
375 workflow is still useful if you want to run tests or do any other analysis
376 on the pull request.
377
8efa315 @leto [docs] Add docs for merging Github pull requests
leto authored
378 If you are merging code from non-core committers, Parrot would like to see
379 "Signed-off-by" lines on each commit, so it is clear that one person wrote the
380 code and someone else is taking responsibility for merging the code.
381
2b2dc13 @leto [doc] Improve our Git workflow
leto authored
382 To merge in a pull request on Github, there is the easy way or the hard way.
383 The easy way is to use tools/dev/merge_pull_request.pl like so:
384
385 perl $PARROT/tools/dev/merge_pull_request.pl N
386
387 where N is the number of the pull request. This will create a branch for the
388 pull request and plop you on it, so that tests or other analyses can be run.
389
390 This script can be used to merge a pull request for any repo in the Parrot
391 Github Organization. For instance, to merge Cardinal Pull request #4:
392
393 perl $PARROT/tools/dev/merge_pull_request.pl 4 cardinal
394
395 If you do not want the default branch name, you can specify a third
396 argument to specify one:
397
398 perl $PARROT/tools/dev/merge_pull_request.pl 4 cardinal awesome_feature
399
400 This will merge pull request #4 in the cardinal repo into a branch
401 called 'awesome_feature'.
402
403 Run C<perldoc tools/dev/merge_pull_request.pl> for more info.
404
405 The hard way: Follow the first two steps on the Github pull request page, i.e:
8efa315 @leto [docs] Add docs for merging Github pull requests
leto authored
406
407 # 1) Make a new branch to pull stuff into
408 git checkout -b someguy-newbranch master
409
410 # 2) Pull in changes from the branch of a forked repo
411 # and switch to newbranch
412 git pull https://github.com/someguy/parrot.git newbranch
413
414 Then you will follow this procedure:
415
416 # 3) let's look at a diff OPTIONAL
417 git diff master # look at a diff
418
419 # 4) let's make a patch of the difference between this branch and master
420 git format-patch master --stdout > foo.patch
421
422 # 5) Switch back to the master branch
423 git checkout master
424
425 # 6) does the patch apply? OPTIONAL
426 git apply --check gci.patch
427
428 # 7) Actually merge in the changes with Signed-Off-By lines
429 git am --signoff gci.patch
430
431 After doing this, you will the new commits in master with
432 your Signed-Off-By lines. Run the tests and if they all pass, push
433 your changes upstream. If they don't, and you want others to take
434 a look at stuff, create a new branch from your local master:
435
436 # make a new branch
437 git checkout -b my_new_branch
438
439 # push it upstream
440 git push origin my_new_branch
441
442 At this point, your local master has commits that are now in
443 my_new_branch, so you should reset master back to before you
444 applied the patch. You can do this by looking at the output
445 of C<git log> and finding the most recent SHA1 before your
446 branch, then doing:
447
448 git reset --hard $sha1
449
450 Be careful with C<git reset>! Make sure there are no untracked
451 files that you care about BEFORE YOUR RUN C<git reset>.
452
453 The use of reset can be avoided if you create a new branch
454 before applying the patch, and then merging that branch
455 to master before pushing.
456
457 Also note that you will have to manually close the Github
458 pull request, since adding Signed-Off-By lines changes
459 the SHA1's which Github uses to automatically close
460 pull requests.
461
caddb4d @leto [docs] Beginning of a Git Workflow document
leto authored
462 =head2 Announcing a Merge
463
464 Send a message to parrot-dev@lists.parrot.org letting people know that your
465 branch has been merged. Include a detailed list of changes made in the branch
466 (you may want to keep this list as you work). Particularly note any added,
467 removed, or changed opcodes, changes to PIR syntax or conventions, and changes
468 in the C interface.
469
470 If there was a specific language, tool, or platform that you wanted tested
471 before merging but couldn't get any response from the responsible person, you
472 may want to include some warning in the announcement that you weren't able to
473 test that piece fully.
474
5d25377 @leto [docs] Add a deleting branches section to git workflow
leto authored
475 =head2 Deleting a Branch
476
7713372 @chromatic Fixed some typos; linked to merge review docs.
chromatic authored
477 After merging a branch, you will have a local copy of the merged branch, as
478 well as a copy of the branch on your remote. To remove the local branch:
5d25377 @leto [docs] Add a deleting branches section to git workflow
leto authored
479
480 git branch -d user/foo
481
7713372 @chromatic Fixed some typos; linked to merge review docs.
chromatic authored
482 To remove the remote branch user/foo on the remote origin:
5d25377 @leto [docs] Add a deleting branches section to git workflow
leto authored
483
484 git push origin :user/foo
485
0f4c968 @leto [doc] Improve Git Workflow
leto authored
486 This follows the general pattern of
487
488 git push origin local_branch_name:remote_branch_name
489
7713372 @chromatic Fixed some typos; linked to merge review docs.
chromatic authored
490 When local_branch_name is empty, you are pushing "nothing" to the remote
491 branch, which deletes it.
5d25377 @leto [docs] Add a deleting branches section to git workflow
leto authored
492
95160c0 @leto [doc] How to find unmerged branches
leto authored
493 =head2 How Can I Tell If A Branch Is Merged?
494
495 To see a list of all remote branches that are not merged into branch foo
496
497 git branch -r --no-merged foo
498
499 If you leave out the last argument, it defaults to HEAD (the tip of the current
500 branch). So, to see a list of all remote branches that have not been merged
501 into master:
502
503 git checkout master
504 git branch -r --no-merged
505
506
caddb4d @leto [docs] Beginning of a Git Workflow document
leto authored
507 =cut
508
509 __END__
510 Local Variables:
511 fill-column:78
512 End:
Something went wrong with that request. Please try again.