Why from your first project?
"It's just a tiny project, I don't need Git..."
Wrong. Use Git from day 1, even for a 10-line script. Why?
| What you think | What actually happens |
|---|---|
| "It's too simple" | It grows more than expected |
| "I'll remember everything" | In 2 weeks you won't remember why you changed something |
| "I have backup on Drive" | Drive doesn't tell you what changed between versions |
| "I'll set it up later" | "Later" never comes, and when you need it, it's too late |
๐ค Git saves you from AI
This is critical if you use code assistants like Cursor, Claude Code, or Copilot:
| Situation | Without Git | With Git |
|---|---|---|
| AI misunderstood your prompt and deleted important code | ๐ฑ Lost | git checkout -- . |
| The agent "improved" something that worked and now it won't compile | ๐ฑ Rewrite it | git diff to see what changed |
| You asked for a small change and it modified 15 files | ๐ฑ Chaos | git stash and start over |
| After 5 prompts, everything is worse than before | ๐ฑ Frustration | git reset --hard HEAD~5 |
โ ๏ธ Reality: AI agents are powerful but make mistakes. An ambiguous prompt can result in destructive changes. Git is your safety net.
Recommended workflow with AI:
# BEFORE asking the AI for something
git add . && git commit -m "Checkpoint before AI changes"
# If the AI breaks something
git diff # See what changed
git checkout -- file.js # Revert one file
git reset --hard HEAD # Revert EVERYTHING to last commit
Our recommendation:
git initis the FIRST command in any project. Before writing code, before installing dependencies. Git first.
Git โ GitHub: The fundamental difference
Before looking at commands, understand this:
| Git | GitHub | |
|---|---|---|
| What is it? | Software on your computer | Website / cloud service |
| Where does it live? | Local (your machine) | Remote (internet) |
| Who created it? | Linus Torvalds (2005) | Microsoft (acquired 2018) |
| Cost? | Free, open source | Free + paid plans |
| Do they need each other? | Git works without GitHub | GitHub needs Git |
Analogy: Git is your personal journal where you write every day. GitHub is the bank's safety deposit box where you keep a copy.
What are they really for?
Git (local) allows you to:
| Use | Example |
|---|---|
| ๐ธ Complete history | See exactly what changed, when, and why |
| โช Go back in time | "It worked yesterday, what did I break today?" |
| ๐ Experiment fearlessly | Create branches to try crazy ideas |
| ๐ Find bugs | "Which commit introduced this error?" |
| ๐ Document decisions | Commit messages are documentation |
GitHub (remote) allows you to:
| Use | Example |
|---|---|
| โ๏ธ Cloud backup | If your laptop gets stolen, your code is safe |
| ๐ฅ Collaborate | Multiple devs working on the same project |
| ๐ Code review | Pull Requests to review before merging |
| ๐ Portfolio | Your profile shows your activity and projects |
| ๐ Auto deploy | GitHub Actions, Vercel, etc. |
When do you only need Git?
โ Git alone is enough when:
- You work solo on your machine
- The project is personal/experimental
- You don't need remote backup (but you should...)
- You're learning
When do you need GitHub?
โ Add GitHub when:
- You want backup (always recommended!)
- You work in a team
- The project is open source
- You want to showcase your work (portfolio)
- You need CI/CD (automated tests, deploy)
Real scenario: Your laptop gets stolen ๐ป๐
| Situation | Without GitHub | With GitHub |
|---|---|---|
| Your code | Lost forever | git clone and continue |
| History | Lost | Intact in the cloud |
| Time lost | Weeks/months of work | 5 minutes to clone |
Moral: Local Git + remote GitHub = peace of mind.
Installation
| System | Command |
|---|---|
| macOS | brew install git |
| Linux | sudo apt install git |
| Windows | winget install Git.Git |
Initial setup
# Identity (appears in every commit)
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
# Default branch
git config --global init.defaultBranch main
# Editor for long messages
git config --global core.editor "code --wait"
Key concepts
| Concept | What it is | Analogy |
|---|---|---|
| Repository | Folder with Git history | Photo album |
| Commit | Snapshot of current state | Dated photo in album |
| Branch | Alternative development line | Draft of a chapter |
| Merge | Join two branches | Integrate draft into book |
| Remote | Connection to GitHub/GitLab | Cloud copy |
| Clone | Download remote repo | Copy album from bank |
| Push | Upload commits to remote | Take new photos to bank |
| Pull | Download commits from remote | Get photos others uploaded |
Workflow
Git only (local)
# Create repository
git init my-project
cd my-project
# Work...
echo "# My Project" > README.md
# See what changed
git status
# Add to staging
git add README.md # specific file
git add . # all changes
# Create commit
git commit -m "Initial: add README"
# View history
git log --oneline
Git + GitHub (local + remote)
# Connect to GitHub (once)
git remote add origin https://github.com/your-user/your-repo.git
# Push your code
git push -u origin main
# After each work session:
git add .
git commit -m "Describe what you did"
git push
Branches: Experiment fearlessly
# Create branch for new feature
git checkout -b feature/login
# Work on the feature...
git add .
git commit -m "Add login form"
# Go back to main
git checkout main
# Integrate the feature
git merge feature/login
# Delete branch (no longer needed)
git branch -d feature/login
GitHub CLI (gh)
# Install
brew install gh
# Authenticate (opens browser)
gh auth login
# Clone repo
gh repo clone user/repo
# Create repo from current folder
gh repo create my-project --public --source=.
# Create Pull Request
gh pr create --fill
Emergency commands
# "I messed up, I want to go back to last commit"
git checkout -- .
# "I want to see how it was 3 commits ago"
git checkout HEAD~3
# "Who wrote this line?"
git blame file.js
# "Which commit broke it?"
git bisect start
git bisect bad # current is bad
git bisect good abc123 # this commit was good
# Git finds the culprit automatically
Visual summary
YOUR COMPUTER GITHUB (CLOUD)
โโโโโโโโโโโโโ โโโโโโโโโโโโโโ
๐ Working Directory
โ
โ git add
โผ
๐ฆ Staging Area
โ
โ git commit
โผ
๐ Local Repository โโโโ git push โโโโถ โ๏ธ Remote Repository
โโโ git pull โโโโ
๐ .gitignore: Your shield against leaks
The .gitignore file tells Git which files to NEVER track. This is CRITICAL for security.
โ ๏ธ Real danger: AI and your secrets
AI assistants (Cursor, Claude Code, Copilot) can accidentally:
| Dangerous situation | Consequence |
|---|---|
Add .env to commit | Your API keys become public |
| Create file with hardcoded credentials | Anyone can see them on GitHub |
| "Improve" code by moving secrets to new files | .gitignore doesn't cover them |
๐จ True story: Thousands of AWS API keys leak every day on GitHub. Bots scan public repos looking for credentials. Your account can be hacked within minutes.
Essential .gitignore file
Create this at the root of EVERY project:
# .gitignore
# Environment variables (SECRETS!)
.env
.env.local
.env.*.local
*.env
# Credentials
credentials.json
*-credentials.json
*.pem
*.key
secrets/
# Dependencies (reinstallable)
node_modules/
venv/
__pycache__/
# Build (regeneratable)
dist/
build/
.next/
.output/
# IDE
.vscode/
.idea/
*.swp
# OS
.DS_Store
Thumbs.db
# Logs
*.log
npm-debug.log*
Useful commands
# See what Git is ignoring
git status --ignored
# If you already committed a file with secrets ๐ฑ
git rm --cached .env
git commit -m "Remove .env from tracking"
# IMPORTANT: The file is still in history!
# Change ALL credentials that were leaked
# Verify before push
git diff --staged # See what you're about to push
Golden rule
NEVER put credentials directly in code. Use environment variables (
.env) and make sure.envis in.gitignoreBEFORE the first commit.
๐ผ GitHub as a professional portfolio
Your GitHub profile is more important than you think:
| Situation | What they look at |
|---|---|
| Job applications | Recruiters check your GitHub before interviews |
| Freelancing | Clients want to see real working projects |
| Contract bids | Companies evaluate code quality and documentation |
What makes a repo "professional"?
my-project/
โโโ README.md # โญ CRITICAL: What it does, how to install, screenshots
โโโ LICENSE # MIT, Apache, etc.
โโโ .gitignore # Clean, no node_modules or .env
โโโ docs/ # Architecture, technical decisions
โ โโโ ARCHITECTURE.md
โโโ src/ # Organized code
โโโ tests/ # โญ Tests demonstrate professionalism
โโโ .github/
โโโ workflows/ # CI/CD shows you know DevOps
Portfolio repo checklist
- README with clear description and screenshots/GIFs
- Installation instructions that WORK
- Tests (even basic ones)
- Clean code with comments where needed
- No secrets or credentials (check the history!)
- Commits with descriptive messages (not "fix", "update")
๐ก Tip: 3-5 well-made public repos impress more than 50 abandoned ones.
Your GitHub profile
Create a repo with your username (e.g., alannreyes/alannreyes) with a README.md that appears on your profile:
# ๐ Hi, I'm [Your Name]
๐ญ Currently working on...
๐ฑ Learning...
๐ฌ Ask me about...
๐ซ Contact me: your@email.com
๐ณ Practice: Your first repository
Ready to apply all this?
โ My First Repository โ Create and push your first repo to GitHub step by step
๐ Next level
โ Advanced Git & Collaboration โ PRs, merge conflicts, rebases and teamwork
Useful links
- ๐ Git - Official documentation
- ๐ Learn Git Branching (interactive)
- ๐ GitHub Docs
- ๐ gitignore.io โ Generate .gitignore for your stack
- ๐ฅ Git in 15 minutes (video)