@@ -63,10 +63,15 @@ what the changes in the branch are for. For example ``add-ability-to-fly``, or
63
63
git branch my-new-feature upstream/main
64
64
git checkout my-new-feature
65
65
66
+ If you started making changes on your local ``main `` branch, you can convert the
67
+ branch to a feature branch by renaming it::
68
+
69
+ git branch -m <newname>
70
+
66
71
Generally, you will want to keep your feature branches on your public GitHub
67
72
fork of Matplotlib. To do this, you ``git push `` this new branch up to your
68
- GitHub repo. Generally ( if you followed the instructions in these pages, and by
69
- default) , git will have a link to your fork of the GitHub repo, called
73
+ GitHub repo. Generally, if you followed the instructions in these pages, and by
74
+ default, git will have a link to your fork of the GitHub repo, called
70
75
``origin ``. You push up to your own fork with::
71
76
72
77
git push origin my-new-feature
@@ -79,6 +84,12 @@ In git >= 1.7 you can ensure that the link is correctly set by using the
79
84
From now on git will know that ``my-new-feature `` is related to the
80
85
``my-new-feature `` branch in the GitHub repo.
81
86
87
+ If you first opened the pull request from your ``main `` branch and then
88
+ converted it to a feature branch, you will need to close the original pull
89
+ request and open a new pull request from the renamed branch. See
90
+ `GitHub: working with branches
91
+ <https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches#working-with-branches> `_.
92
+
82
93
.. _edit-flow :
83
94
84
95
The editing workflow
0 commit comments