Getting Oriented: Version Control, Accounts, and Essential Commands
Why Git Exists and How It Works
If you’ve ever kept files named brand_guide_v2, brand_guide_final, and brand_guide_FINAL_actually, you understand the problem version control solves. Git tracks every change to your files over time, recording what changed, when, and why. It lets you revisit earlier versions on demand, eliminating the need for those “final” file folders.
Git operates across three zones: the working directory where you edit files, the staging area where you review what’s ready, and the local repository that stores your saved history. Three commands move work through these zones — git status, git add, and git commit. When someone says “push your code,” they mean uploading your local commits to GitHub using Git.
Securing Your GitHub Identity
Your GitHub account is your developer identity, so protect it accordingly. Two-factor authentication adds a second layer of defense against phishing and password reuse; enable it from Settings → Password and authentication.
You should also create a profile README as a living portfolio. Create a public repository matching your username, add a README, and anything you write displays on your profile page. Download your recovery codes and store them in a password manager — they’re your only way back if you lose your device.
The Commands That Matter
You don’t need to memorize all of Git. A small set covers the daily workflow of nearly every developer:
| Command | What it does |
|---|---|
| git config –global user.name “…” | Set the name attached to your commits |
| git init | Turn the current folder into a Git repository |
| git clone <url> | Make a local copy of a remote repository |
| git status | See what’s changed in your local environment and what’s staged |
| git add . | Stage all your changes for the next commit |
| git commit -m “message” | Save a snapshot of your staged changes |
| git switch -c <branch> | Create a new branch and switch to it |
| git push | Upload your local commits to GitHub |
| git pull | Download and merge the latest changes from GitHub |
| git merge <branch> | Integrate another branch into your current one |
Building Your First Project
Creating a Repository
A repository, or “repo,” is a project folder that tracks changes, stores history, and enables collaboration. From your dashboard, click the green New button, name your repo, choose public or private, and add a README — the front door visible to every visitor.
You can also add a .gitignore and a license. The .gitignore file tells Git to ignore automatically generated files: system files, downloaded dependencies, and temporary build output. Keeping these out of version control keeps your repository focused on code that actually matters.
Markdown Fundamentals
Markdown is a lightweight formatting language for plain text. It’s how READMEs, issues, pull requests, and comments are written across GitHub, using simple symbols that render into clean documentation.
The GitHub Flow
The GitHub flow is the repeatable loop for adding work to a shared project: clone, branch, commit, push, pull request, merge. This rhythm applies to any content in a repository, not just code. For example, if your team maintains shared AI prompts, you can rework one on a branch, open a pull request for a colleague to check, and merge once approved — teammates who refresh the repo automatically get the improvement without announcements or email attachments.
Give branches descriptive names like fix-login-bug or add-dark-mode so their purpose is visible at a glance.
Collaborating With Others
Pull Requests and Merging
A pull request proposes merging changes from one branch into another with a space for discussion. It shows a visual diff and lets reviewers comment. Write a clear title and description, link related issues, and review your own work first to catch obvious mistakes. Smaller pull requests are easier to review, less likely to introduce bugs, and produce clearer history.
Merging integrates reviewed changes into your target branch — usually a single click on Merge pull request. A merge conflict occurs when two branches edit the same lines and Git can’t decide which version wins. GitHub marks the conflicting sections; you use the browser editor or VS Code to choose what to keep, mark it resolved, and merge.
Tracking Work With Issues and Projects
Issues track individual tasks, bugs, and ideas — assignable, labelable, and discussable. Projects organize those issues onto a Kanban-style board for an at-a-glance status view. Every issue receives its own number, shown as a hashtag followed by digits.
You can link a pull request to an issue with a closing keyword in the description: “Closes #42,” “Fixes #42,” or “Resolves #42.” GitHub links the two, and merging the pull request automatically closes the issue, moving it to “Done” on any project board that contains it. This habit keeps code changes and task tracking in sync without extra effort.
Automating Work: GitHub Actions and Pages
GitHub Actions
GitHub Actions is a CI/CD and automation platform built into GitHub that automatically runs tasks (e.g., tests, deployments, labeling) when events happen in your repository. Instead of manually repeating routine work, you define a workflow as a YAML file in .github/workflows/, specify the triggering event, and outline the steps. GitHub then executes those steps automatically every time the event occurs.
GitHub Pages
For portfolio sites, project pages, or documentation, GitHub Pages offers free hosting at username.github.io/repo-name with no server management. Enable it via Settings → Pages, select deployment from a branch, and your site goes live within minutes. Notably, private repositories can also publish a public site, which is useful when you want to showcase work without exposing the underlying code.
Securing Your Repositories
Security practices should be integrated throughout development, not applied at the end. GitHub Advanced Security is a built-in suite that automatically identifies and helps resolve vulnerabilities. It includes secret scanning, Dependabot, and CodeQL code scanning, and it is free for public repositories.
- Secret scanning detects API keys and other credentials accidentally committed to your code.
- Dependabot monitors your dependencies for known vulnerabilities and automatically opens pull requests to update them.
- CodeQL analyzes data flow through your codebase to identify risky patterns and provides explanations for fixes.
All of these can be activated from your repository settings. Remember that importing a library into your project means you inherit any risk from that dependency, even if you didn't write the vulnerable code yourself.
Contributing to Open Source
Open source software has freely available code that anyone can study and improve. To find a suitable project, look for ones with a clear README, a CONTRIBUTING.md, an open source license, and issues tagged good first issue, which signals that maintainers welcome beginners.
A safe way to contribute is through a fork—your personal copy of someone else's repository where you can experiment freely, then propose changes back via a pull request. Forking differs from branching in an important way: a branch is a parallel workspace inside a repository you already have permission to change, while a fork copies the entire repository into your own account. This distinction matters because most open source projects don't grant direct write access. A common workflow combines both: fork the project, create a branch in your fork for your changes, and open a pull request back to the original repository.
