Setting Up GitHub

Go to github.comand sign up. The free tier is all you need — it includes unlimited public and private repos, GitHub Issues, Projects, and Actions. Use your professional email. Choose a username you'd put on a resume — it's your developer identity and shows up in every project URL, commit, and contribution.

On macOS, the easiest way is through Homebrew: brew install git (install Homebrew first from https://brew.shif you don't have it). Verify with git --version. Then set your identity so commits are attributed to you: git config --global user.name "Your Name" and git config --global user.email "your@email.com". Use the same email you signed up to GitHub with — this is how GitHub links commits to your profile.

SSH keys let you push and pull code without entering your password every time. Run ssh-keygen -t ed25519 -C "your@email.com". Press Enter to accept the default file location and set a passphrase if you want extra security. Copy your public key: cat ~/.ssh/id_ed25519.pub. Then go to GitHub → Settings → SSH and GPG keys → New SSH key, paste it in, and save. Test the connection: ssh -T git@github.com— you should see a success message.

Run brew install gh, then gh auth login. Choose SSHas your protocol and authenticate through your browser. The GitHub CLI lets you create repos, open pull requests, manage issues, and check deploy status — all from your terminal. It's faster than clicking through the web UI and integrates cleanly with your development workflow.

From the terminal: gh repo create my-project --public --clone. This creates a repo on GitHub and clones it locally in one step. Or create it on github.com with a README, then clone: git clone git@github.com:username/repo.git. Either way, you end up with a local folder connected to a remote GitHub repo. The remote is your backup and your deployment source.

The daily cycle is four commands. git pull— always pull before starting work to get the latest changes. git add . — stage your changes. git commit -m "what you changed"— save a snapshot with a message explaining why. git push— upload to GitHub. Check your status anytime with git statusto see what's changed, what's staged, and what's not tracked. Run git log --oneline to see your commit history.

Go to your repo on GitHub → Settings → Branches → Add rule for main. Check Require a pull request before merging. This prevents you from accidentally pushing broken code directly to production. Every change goes through a pull request, which gives you a chance to review the diff, run automated checks, and catch mistakes before they reach your live app.

Create an issue for every feature, bug, and task. Go to the Issues tab and click New issue. Add labels like bug, enhancement, priority: high to categorize them. Reference issues in your commit messages: “fix: resolve checkout error #12”. Close them automatically from pull requests by writing “Closes #12” in the PR description. This creates a clean trail from task to code change to deployment.

Every project needs a .gitignore file that tells git which files to exclude. For a Next.js project, you need at minimum: node_modules/, .next/, .env, .env.local, and .env*.local. Never commit secrets (API keys, database URLs), dependencies (node_modules), or build output (.next). Set this up before your first commit — retroactively removing files from git history is painful. Use gitignore.io to generate templates for your stack.

Pull requests (PRs) are how you merge changes safely. The flow: create a branch git checkout -b feat/my-feature, make your changes, commit them, push the branch git push -u origin feat/my-feature, then create a PR with gh pr create. The PR shows the full diff of your changes, lets you add a description of what and why, and creates a space for review. Once you're satisfied, merge it into main. This is the professional workflow used by every engineering team.