Skip to content

Add branch tracking to development workflow instructions #28575

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jul 29, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 17 additions & 12 deletions doc/devel/development_workflow.rst
Original file line number Diff line number Diff line change
Expand Up @@ -79,19 +79,13 @@ default, git will have a link to your fork of the GitHub repo, called

git push origin my-new-feature

In git >= 1.7 you can ensure that the link is correctly set by using the
``--set-upstream`` option::
.. hint::

git push --set-upstream origin my-new-feature

From now on git will know that ``my-new-feature`` is related to the
``my-new-feature`` branch in the GitHub repo.

If you first opened the pull request from your ``main`` branch and then
converted it to a feature branch, you will need to close the original pull
request and open a new pull request from the renamed branch. See
`GitHub: working with branches
<https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches#working-with-branches>`_.
If you first opened the pull request from your ``main`` branch and then
converted it to a feature branch, you will need to close the original pull
request and open a new pull request from the renamed branch. See
`GitHub: working with branches
<https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches#working-with-branches>`_.
Comment on lines -83 to +88
Copy link
Member

@timhoffm timhoffm Jul 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know you just converted the text to a hint, which is an improvment. But reading this, it feels out of context. We're discussing making a new feature branch. Already having a PR from main means the user has gone two steps in a different direction. Also it's not really relevant to the feature branch.

I'm slightly in favor of removing this completely. Alternatively, if you think, this is still valuable (Do we expect users to find this when they need it? Is a PR from main really that bad that we need to discuss recovering from this non-standard workflow?), you can move this down to the section "Open a pull request".

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is a PR from main really that bad that we need to discuss recovering from this non-standard workflow?

So this language has been in there for a while b/c from what I remember maintainers can't easily take over a PR made to main.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok let's get this in as an incremental improvement. We can discuss this separately.


.. _edit-flow:

Expand Down Expand Up @@ -167,6 +161,17 @@ You can achieve this by using
git commit -a --amend --no-edit
git push [your-remote-repo] [your-branch] --force-with-lease

.. tip::
Instead of typing your branch name every time, you only need to type the following once to link the remote branch to the local branch::

git push --set-upstream origin my-new-feature

From now on git will know that ``my-new-feature`` is related to the
``my-new-feature`` branch in the GitHub repo. After this, you will be able to
push your changes with::

git push


Manage commit history
=====================
Expand Down