The local history from the previous module is useful on its own. Now we will connect it to a private GitHub practice repository. This lesson stops at a verified destination so that the next lesson can perform and inspect the transfer. The key habit is to check the actual owner and URL before sending project history anywhere.

Git and GitHub have different roles. Git records and compares versions locally. GitHub is a hosting and collaboration service that can hold a remote copy of those commits. A local commit does not automatically upload, and signing into a website does not automatically synchronize your working folder. Keeping these actions separate makes the workflow easier to understand.

Open GitHub in the browser and verify the account you intend to use. Choose a neutral practice repository name. Private visibility satisfies this course; there is no need to publish your project. Inspect the owner and visibility controls before creation. If you have access to several accounts or organizations, this is the point where an unnoticed selection can send work to the wrong place.

Your local project already contains a baseline and a meaningful label change. Create the remote without a generated README, license, or ignore file. The README and ignore rules already exist in local history; licensing is a separate deliberate choice. Creating separate content on the server would produce another initial history that needs reconciliation. Avoiding that unnecessary branch of work keeps the first synchronization straightforward.

If you already initialized the remote, do not panic and do not force-push immediately. Preserve both states and inspect what exists. For a disposable practice exercise, another empty private repository with a new name can be a simple deliberate restart. For a real project, the contents may matter and need integration. The correct remedy depends on what you intend to preserve.

Return to PowerShell in the local practice repository. Check the current location, Git status, and branch name. Confirm that you are looking at the history you reviewed in the previous module. A browser tab showing the right remote is not enough if the terminal is inside a different project. We verify both ends of the connection.

Run Git remote with the verbose option. If the project has no configured remotes, the output may be empty. If a remote exists, read its name and address. Origin is only a conventional label stored locally. It does not mean the server is correct, safe, current, or owned by the account you expected. The actual URL carries the destination information.

Copy the HTTPS address from the new private repository page. Use it with the remote-add command shown in the written lesson. Replace the example owner with the real selected account rather than copying the book's demonstration address. Then run the verbose remote inspection again and read the result before any push.

If Git reports that origin already exists, adding it again is not a repair. Inspect the existing value. If it is wrong and you have identified the correct destination, use the set-url operation deliberately. Record what changed. If it is already correct, leave it alone. Avoid creating several similarly named remotes just to get past an error you have not understood.

Never put a token into the remote URL. Addresses can appear in command output, shell history, logs, and screenshots. Use the supported credential flow for authentication. The exercise's evidence should show a normal repository address without any secret material. A credential embedded in a URL is not a more reproducible setup; it is private information in a place likely to be copied.

Commit identity and authentication are also separate. The author name and email recorded in a commit describe who is credited for that change. They do not grant permission to a private repository. Your browser may be signed into the intended account while the Git credential helper has a different identity. An actual Git operation will test that access in the next lesson.

When authentication is requested, complete the private sign-in process and return to the project. The course recording can show the safe entry screen and neutral post-login state with credential entry omitted. Do not show passwords, recovery codes, or a password-manager surface. A human login challenge is a private setup action, not a reason to invent a successful result for the lesson.

Before transferring history, inspect the tracked files and recent commits. The repository should contain the intended source, scripts, documentation, and synthetic fixtures. A private repository still receives whatever you upload. Also remember that deleting a sensitive file from the current tree does not necessarily remove it from earlier commits. Our supplied practice history is deliberately generic and separate from authoring history.

Write a short destination record. Include the intended repository, private visibility, current local branch, and the inspected remote address without credentials. State whether authentication has been exercised yet. Do not label configuration as successful transport. That final distinction lets the next lesson add real push and clone evidence instead of repeating an assumption.

One useful final inspection is to read the repository address from right to left: repository name, owner, then host. This is not a new security mechanism; it is a deliberate way to catch a familiar-looking typo. Compare it with the actual browser page you just created. A neutral practice name can resemble an earlier exercise, so also check whether the remote is empty as intended. Configuration should be established by those concrete observations before transport begins.

For your exercise, explain why origin's name is insufficient and how commit identity differs from access. You are ready to advance when both the local history and remote destination are the ones you intended. We will then push, inspect the hosted commit, clone into a second folder, and test whether the written setup is sufficient to reproduce the project.