Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitcabfb97

Browse files
committed
WIP
1 parent7ad9bbd commitcabfb97

File tree

1 file changed

+36
-41
lines changed

1 file changed

+36
-41
lines changed

‎doc/devel/development_workflow.rst‎

Lines changed: 36 additions & 41 deletions
Original file line numberDiff line numberDiff line change
@@ -9,8 +9,9 @@ Development workflow
99
Workflow summary
1010
================
1111

12-
In what follows we'll refer to the upstream Matplotlib ``main`` branch, as
13-
"trunk".
12+
To keep your work well organized, with readable history, and in turn make it
13+
easier for project maintainers (that might be you) to see what you've done, and
14+
why you did it, we recommend the following:
1415

1516
* Don't use your ``main`` branch for anything. Consider deleting it.
1617
* When you are starting a new set of changes, fetch any changes from ``main``,
@@ -23,10 +24,6 @@ In what follows we'll refer to the upstream Matplotlib ``main`` branch, as
2324
`discourse<https://discourse.matplotlib.org>`__.
2425
* Ask for a code review!
2526

26-
This way of working helps to keep work well organized, with readable history.
27-
This in turn makes it easier for project maintainers (that might be you) to see
28-
what you've done, and why you did it.
29-
3027
..note::
3128

3229
It may sound strange, but deleting your own ``main`` branch can help reduce
@@ -35,21 +32,19 @@ what you've done, and why you did it.
3532

3633
.. _deleting main on github:https://matthew-brett.github.io/pydagogue/gh_delete_master.html
3734

38-
.. _update-mirror-trunk:
35+
.. _update-mirror-main:
3936

40-
Update the mirror oftrunk
41-
==========================
37+
Update the mirror ofmain
38+
=========================
4239

4340
First make sure you have done:ref:`linking-to-upstream`.
4441

45-
From time to time you should fetch the upstream(trunk)changes from github::
42+
From time to time you should fetch the upstream changes from github::
4643

4744
git fetch upstream
4845

4946
This will pull down any commits you don't have, and set the remote branches to
50-
point to the right commit. For example, 'trunk' is the branch referred to by
51-
(remote/branchname) ``upstream/main`` - and if there have been commits since
52-
you last checked, ``upstream/main`` will change after you do the fetch.
47+
point to the right commit.
5348

5449
.. _make-feature-branch:
5550

@@ -69,17 +64,17 @@ what the changes in the branch are for. For example ``add-ability-to-fly``, or
6964

7065
::
7166

72-
# Update the mirror oftrunk
67+
# Update the mirror ofmain
7368
git fetch upstream
74-
# Make new feature branch starting at currenttrunk
69+
# Make new feature branch starting at currentmain
7570
git branch my-new-feature upstream/main
7671
git checkout my-new-feature
7772

7873
Generally, you will want to keep your feature branches on your public GitHub
7974
fork of Matplotlib. To do this, you ``git push`` this new branch up to your
80-
github repo. Generally (if you followed the instructions in these pages, and by
81-
default), git will have a link to yourgithub repo, called ``origin``. You push
82-
up to your ownrepo on github with::
75+
GitHub repo. Generally (if you followed the instructions in these pages, and by
76+
default), git will have a link to yourfork of the GitHub repo, called
77+
``origin``. You pushup to your ownfork with::
8378

8479
git push origin my-new-feature
8580

@@ -89,7 +84,7 @@ In git >= 1.7 you can ensure that the link is correctly set by using the
8984
git push --set-upstream origin my-new-feature
9085

9186
From now on git will know that ``my-new-feature`` is related to the
92-
``my-new-feature`` branch in thegithub repo.
87+
``my-new-feature`` branch in theGitHub repo.
9388

9489
.. _edit-flow:
9590

@@ -174,55 +169,55 @@ To see a linear list of commits for this branch::
174169

175170
git log
176171

177-
.. _rebase-on-trunk:
172+
.. _rebase-on-main:
178173

179-
Rebasing ontrunk
180-
-----------------
174+
Rebasing onmain
175+
----------------
181176

182177
Let's say you thought of some work you'd like to do. You
183-
:ref:`update-mirror-trunk` and:ref:`make-feature-branch` called
184-
``cool-feature``. At this stage trunk is at some commit, let's call it E. Now
185-
you make some new commits on your ``cool-feature`` branch, let's call them A, B,
186-
C.Maybe your changes take a while, or you come back to them after a while. In
187-
the meantime,trunk has progressed from commit E to commit (say) G:
178+
:ref:`update-mirror-main` and:ref:`make-feature-branch` called
179+
``cool-feature``. At this stage, ``main`` is at some commit, let's call it E.
180+
Nowyou make some new commits on your ``cool-feature`` branch, let's call them
181+
A, B,C. Maybe your changes take a while, or you come back to them after a
182+
while. Inthe meantime,``main`` has progressed from commit E to commit (say) G:
188183

189184
..code-block::none
190185
191186
A---B---C cool-feature
192187
/
193-
D---E---F---Gtrunk
188+
D---E---F---Gmain
194189
195-
At this stage you consider mergingtrunk into your feature branch, and you
190+
At this stage you consider merging``main`` into your feature branch, and you
196191
remember that this here page sternly advises you not to do that, because the
197192
history will get messy. Most of the time you can just ask for a review, and not
198-
worry thattrunk has got a little ahead. But sometimes, the changes in trunk
199-
might affect your changes, and you need to harmonize them. In this situation
200-
you may prefer to do a rebase.
193+
worry that``main`` has got a little ahead. But sometimes, the changes in
194+
``main``might affect your changes, and you need to harmonize them. In this
195+
situationyou may prefer to do a rebase.
201196

202-
rebase takes your changes (A, B, C) and replays them as if they had been made to
203-
the current state of ``trunk``. In other words, in this case, it takes the
204-
changes represented by A, B, C and replays them on top of G. After the rebase,
205-
your history will look like this:
197+
``rebase`` takes your changes (A, B, C) and replays them as if they had been
198+
made tothe current state of ``main``. In other words, in this case, it takes
199+
thechanges represented by A, B, C and replays them on top of G. After the
200+
rebase,your history will look like this:
206201

207202
..code-block::none
208203
209204
A'--B'--C' cool-feature
210205
/
211-
D---E---F---Gtrunk
206+
D---E---F---Gmain
212207
213208
See `rebase without tears`_ for more detail.
214209

215210
.. _rebase without tears:https://matthew-brett.github.io/pydagogue/rebase_without_tears.html
216211

217-
To do a rebase ontrunk::
212+
To do a rebase on``main``::
218213

219-
# Update the mirror oftrunk
214+
# Update the mirror ofmain
220215
git fetch upstream
221216
# go to the feature branch
222217
git checkout cool-feature
223218
# make a backup in case you mess up
224219
git branch tmp cool-feature
225-
# rebase cool-feature ontotrunk
220+
# rebase cool-feature ontomain
226221
git rebase --onto upstream/main upstream/main cool-feature
227222

228223
In this situation, where you are already on branch ``cool-feature``, the last
@@ -237,7 +232,7 @@ When all looks good you can delete your backup branch::
237232
If it doesn't look good you may need to have a look at
238233
:ref:`recovering-from-mess-up`.
239234

240-
If you have made changes to files that have also changed intrunk, this may
235+
If you have made changes to files that have also changed in``main``, this may
241236
generate merge conflicts that you need to resolve - see the `git rebase`_ man
242237
page for some instructions at the end of the "Description" section. There is
243238
some related help on merging in the git user manual - see `resolving a merge`_.

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp