# How to Commit and Push Code to GitHub
GitHub is the hosted service; Git is the version-control tool that tracks changes in a local repository. Keeping that distinction clear makes the command line less mysterious. You create and inspect commits with Git on your computer, then push selected commits to a remote repository such as one hosted by GitHub.
The source article presents the basic initialization commands and several proxy configurations. This guide explains what those commands do, adds the checks that prevent common mistakes, and keeps sensitive details out of the workflow. Replace example names, email addresses, and repository URLs with values for your own project. Never paste an access token into a command history, README file, screenshot, or public issue.
## Check your starting point
Open a terminal in the folder that contains the project. Before initializing anything, inspect the files and make sure you are not accidentally inside a parent directory that contains unrelated work. A Git repository tracks everything beneath its top-level directory unless files are excluded. Starting in the wrong folder is one of the fastest ways to stage a private configuration file by mistake.
Set the identity Git will attach to your commits. The source includes `git config –global user.name xxx`; set both a display name and an email address that you intend to use for development. The `–global` flag affects repositories for the current user, so use it only if that identity is appropriate across projects. For a one-off repository, omit `–global` and set the values locally.
“`bash
git config –global user.name “Your Name”
git config –global user.email “you@example.com”
git config –global –list
“`
The final command is a check, not a substitute for reviewing the actual project. It shows the configuration Git sees and can reveal an old proxy or identity that may affect a new repository.
## Initialize the repository and make the first commit
In a new project folder, `git init` creates the hidden repository metadata. The source then uses `git add README.md` to stage one file. Staging is deliberate: it selects the exact snapshot that will be recorded in the next commit. `git add .` can be convenient, but it deserves a review first because it may include files you did not expect.
“`bash
git init
git status
git add README.md
git status
git commit -m “Add initial README”
“`
Use `git status` before and after staging. Read its output rather than treating it as noise. If a local settings file, private key, build artifact, or dependency directory appears, stop and add an appropriate rule to `.gitignore` before committing. A `.gitignore` prevents untracked matching files from being added later; it does not remove a file that has already been committed. If a secret has been committed and pushed, rotate the secret promptly even if you later remove it from the repository.
A commit message should say what changed in clear terms. “Update” is technically valid but becomes unhelpful after dozens of commits. A concise imperative description, such as “Configure initial project structure,” is easier for future maintainers to scan.
## Choose and name the main branch
The source uses `git branch -M main` to rename the current branch to `main`. That is a common convention, but it is not mandatory. Check the default-branch expectations for your organization or the remote repository before renaming. The capital `-M` forces a rename if necessary, so do not use it casually when a branch of the target name already has meaningful work.
“`bash
git branch -M main
git branch –show-current
“`
For daily work, create a focused branch rather than putting every change directly on the default branch. A narrow branch makes code review and rollback easier. The exact branch name matters less than a consistent team convention.
## Connect the local project to GitHub
Create an empty repository in GitHub using the organization’s normal access process. Then add it as a remote. The source uses the conventional remote name `origin`:
“`bash
git remote add origin https://github.com/OWNER/REPOSITORY.git
git remote -v
git push -u origin main
“`
The `-u` option establishes an upstream relationship, allowing later `git push` and `git pull` commands to infer the remote branch. Before the first push, inspect `git remote -v` closely. A typo can send code to the wrong project, and a URL copied from a browser may not be the protocol your team expects.
Modern GitHub authentication does not accept an account password for Git operations over HTTPS. Follow GitHub’s current documented authentication method for your account and organization, such as a credential manager, a fine-grained token handled securely, or SSH keys. Avoid commands that embed credentials directly in remote URLs. They can leak through shell history, process listings, repository configuration, or logs.
## A repeatable daily workflow
Once the remote is connected, the rhythm is straightforward: inspect, stage intentionally, commit, synchronize, and push. A useful sequence is:
“`bash
git status
git diff
git add path/to/changed-file
git diff –staged
git commit -m “Describe the change”
git pull –rebase origin main
git push
“`
The exact pull strategy depends on the team’s policy. The point is to synchronize before publishing your work and to resolve conflicts with attention, not by blindly accepting one side. Read conflict markers, understand each change, run relevant tests, and inspect the result before the final commit.
## Configure a proxy only when your environment requires one
The source gives examples for a global HTTP or HTTPS proxy, a GitHub-only proxy, and a SOCKS proxy. Proxy settings are environment-specific. The addresses and ports in examples are placeholders, not universal values. Before setting one, confirm the correct proxy protocol, host, port, and security policy with the network administrator or the tool that provides the local proxy.
A global setting affects every Git HTTP request from that user:
“`bash
git config –global http.proxy http://127.0.0.1:1080
git config –global https.proxy http://127.0.0.1:1080
“`
A GitHub-specific setting limits the scope, which is often easier to reason about:
“`bash
git config –global http.https://github.com.proxy http://127.0.0.1:1080
git config –global https.https://github.com.proxy http://127.0.0.1:1080
“`
If the proxy is no longer needed, remove the exact key you set and verify the result with `git config –global –list`. Do not leave an old proxy configured and assume a future network failure is GitHub’s fault. Review the configuration first.
## Troubleshoot without exposing secrets
When a push fails, start with `git status`, `git remote -v`, and the full non-sensitive error message. Determine whether the failure is local repository state, authentication, DNS or network access, proxy configuration, or remote permission. Test a simple read-only command such as `git ls-remote origin` only after confirming that the remote URL is correct.
Do not disable certificate verification to make a TLS error disappear. Fix the operating system trust store, proxy interception policy, or network configuration with the appropriate administrator. A successful insecure connection is not a healthy solution.
### Security and currency note
Git, GitHub, credential helpers, and organizational authentication policies evolve. Check the current GitHub documentation and your team’s requirements before configuring authentication or a proxy. The commands here are a workflow guide, not a reason to bypass access controls.
