Update Git push instructions with branch switch and upstream tracking

[TDila]

Why:

The update clarifies the steps for pushing changes to a remote repository by ensuring users are on the correct branch and properly setting the upstream tracking. This prevents confusion and potential mistakes when working with feature branches.

Closes: #34282

What's being changed (if available, include any code snippets, screenshots, or gifs):

• Added instructions to switch to the correct feature branch before pushing.
• Updated the git push command to include -u origin BRANCH_NAME, which sets the upstream tracking branch.
• Improved the documentation to provide a clearer, step-by-step guide for pushing changes to the remote repository.

Check off the following:

• I have reviewed my changes in staging, available via the View deployment link in this PR's timeline (this link will be available after opening the PR).

  • For content changes, you will also see an automatically generated comment with links directly to pages you've modified. The comment won't appear if your PR only edits files in the data directory.

• For content changes, I have completed the self-review checklist.

[welcome]

Thanks for opening this pull request! A GitHub docs team member should be by to give feedback soon. In the meantime, please check out the contributing guidelines.

[github-actions]

Automatically generated comment ℹ️

This comment is automatically generated and will be overwritten every time changes are committed to this branch.

The table contains an overview of files in the content directory that have been changed in this pull request. It's provided to make it easy to review your changes on the staging site. Please note that changes to the data directory will not show up in this table.

---

Content directory changes

You may find it useful to copy this table into the pull request summary. There you can edit it to share links to important articles or changes and to give a high-level overview of how the changes in your pull request support the overall goals of the pull request.

Source	Preview	Production	What Changed
get-started/exploring-projects-on-github/contributing-to-a-project.md	fpt ghec ghes@ 3.14 3.13 3.12 3.11 3.10	fpt ghec ghes@ 3.14 3.13 3.12 3.11 3.10

---

fpt: Free, Pro, Team
ghec: GitHub Enterprise Cloud
ghes: GitHub Enterprise Server

[nguyenalex836]

@TDila Thanks so much for opening a PR! I'll get this triaged for review ✨

[subatoi]

Hi @TDila and thanks for your interest in the GitHub Docs—

Unfortunately, we can't accept this submission. The article you've proposed to modify specifically relates to forking (and likely does need some updates, but we'd need to do that separately), and it's assumed the audience will be a beginner reader for whom these updated instructions wouldn't be relevant and may instead be confusing. If the instructions haven't worked, then we'd need to look at that separately, too, and make changes to the whole article or link out to e.g. https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/configuring-a-remote-repository-for-a-fork

We encourage contributors to raise issues first before submitting pull requests, to give us time to verify proposals. For example in this case, if you've followed the article and found a problem, it'd be helpful if you could raise an issue so we can make a judgement about whether to recommend specific changes, direct you to GitHub Support, or decide to take changes in-house.

You're also very welcome to look at any issues marked help wanted.

Thanks again for your interest in our docs.