Creating and Managing Repositories
A repository (or "repo") is the foundation of any GitHub project. It contains all your project files, tracks their history, and enables collaboration. In this lesson, we'll learn how to create repositories on GitHub, configure them properly, and manage important repository settings.
Creating a New Repository on GitHub
There are multiple ways to create a repository on GitHub:
Method 1: GitHub Web Interface
1. Log in to GitHub.com
2. Click the "+" icon in top right corner
3. Select "New repository"
4. Fill in repository details:
- Repository name (required)
- Description (optional but recommended)
- Public or Private
- Initialize with README (optional)
- Add .gitignore (optional)
- Choose a license (optional)
5. Click "Create repository"
Method 2: GitHub CLI
# Create public repository
gh repo create my-project --public
# Create private repository
gh repo create my-project --private
# Create with README and clone locally
gh repo create my-project --public --clone
# Interactive mode (asks questions)
gh repo create
Naming Convention: Use lowercase letters, numbers, and hyphens. Avoid spaces and special characters. Examples: my-awesome-project, portfolio-website, react-todo-app
Repository Initialization Options
When creating a repository, you have several initialization options:
Initialize with README:
- Creates README.md file automatically
- Recommended for new projects
- Allows immediate cloning
- Provides a starting point for documentation
Add .gitignore:
- Template-based ignore rules
- Language-specific templates (Node, Python, Java, etc.)
- Prevents committing unwanted files
- Select based on your project type
Choose a license:
- Defines how others can use your code
- Required for open source projects
- Common licenses: MIT, Apache 2.0, GPL v3
- Can be added later if unsure
README.md Best Practices
The README is the first thing people see when visiting your repository. Make it count:
Essential README Sections:
# Project Title
Brief description of what the project does
## Features
- Feature 1
- Feature 2
- Feature 3
## Installation
```bash
npm install my-project
```
## Usage
```javascript
const project = require('my-project');
project.doSomething();
```
## Contributing
Guidelines for contributors
## License
MIT License - see LICENSE file
## Contact
Your name - [@twitter](https://twitter.com/handle)
Advanced README elements:
# Badges


# Screenshots

# Table of Contents
- [Installation](#installation)
- [Usage](#usage)
- [API](#api)
# Code Examples
Detailed examples with syntax highlighting
# FAQ Section
Common questions and answers
# Acknowledgments
Credits and thanks
Markdown Tip: README files use Markdown formatting. Learn basic syntax: headers (#), lists (-), code blocks (```), links, images, and tables for professional documentation.
Choosing the Right License
Licenses protect you and inform others how they can use your code:
MIT License:
- Most permissive and popular
- Allows commercial use
- No liability for the author
- Great for open source projects
Apache License 2.0:
- Similar to MIT
- Includes patent grant
- Requires attribution
- Used by Apache Foundation projects
GNU GPL v3:
- Copyleft license
- Derivatives must be open source
- Ensures software freedom
- Used by Linux kernel
No License:
- Default: all rights reserved
- Others can't legally use your code
- Not recommended for public repos
- Private repos don't need a license
Quick Guide: Want simple and permissive? Use MIT. Want to ensure derivatives stay open? Use GPL. Building a library? Consider Apache. Visit choosealicense.com for detailed guidance.
.gitignore Templates
The .gitignore file tells Git which files to never track:
Node.js .gitignore example:
# Dependencies
node_modules/
npm-debug.log
# Environment variables
.env
.env.local
# Build outputs
dist/
build/
*.min.js
# IDE files
.vscode/
.idea/
*.swp
# OS files
.DS_Store
Thumbs.db
# Testing
coverage/
*.test.js.snap
Python .gitignore example:
# Byte-compiled files
__pycache__/
*.py[cod]
*$py.class
# Virtual environments
venv/
env/
ENV/
# Distribution
dist/
build/
*.egg-info/
# Testing
.pytest_cache/
.coverage
htmlcov/
# IDE
.vscode/
.idea/
*.swp
Important: Never commit sensitive information like API keys, passwords, database credentials, or private keys. Add them to .gitignore immediately.
Repository Settings
After creating a repository, configure important settings:
General Settings (Settings → General):
Repository name:
- Can be changed later
- Will break existing clone URLs
- Updates all GitHub features automatically
Description:
- Appears on repository page
- Helps with search and discovery
- Can include emojis
Topics (tags):
- Add relevant keywords
- Improves discoverability
- Examples: javascript, web-development, react
Features:
☑ Issues - Track bugs and features
☑ Projects - Organize work
☐ Wiki - Additional documentation
☑ Discussions - Community conversations
Branch Protection Rules:
Protect main branch:
- Require pull request reviews
- Require status checks to pass
- Require branches to be up to date
- Restrict who can push
- Require signed commits
Navigate to: Settings → Branches → Add rule
- Branch name pattern: main
- ☑ Require pull request before merging
- ☑ Require approvals (1-6 reviewers)
- ☑ Require status checks to pass
Making Repositories Public or Private
You can change repository visibility at any time:
Public Repositories:
✓ Visible to everyone on the internet
✓ Appears in search engines
✓ Anyone can clone and fork
✓ Great for open source
✓ Builds your portfolio
✗ Code is publicly accessible
Private Repositories:
✓ Only visible to you and collaborators
✓ Hide code from public view
✓ Suitable for commercial projects
✓ Free with GitHub Free plan
✗ Doesn't build public portfolio
✗ Limited collaborators on free plan
Change visibility:
Settings → Danger Zone → Change visibility
⚠ Be careful! Making public can't be easily undone
GitHub Free: Offers unlimited private repositories with unlimited collaborators. No need for paid plans unless you need advanced features.
Transferring Repository Ownership
Sometimes you need to transfer a repo to another user or organization:
Transfer Repository:
1. Go to repository Settings
2. Scroll to "Danger Zone"
3. Click "Transfer ownership"
4. Enter new owner's username or organization
5. Type repository name to confirm
6. Click "I understand, transfer this repository"
What gets transferred:
✓ Repository code and history
✓ Issues and pull requests
✓ Releases and tags
✓ Wiki and discussions
✓ GitHub Actions workflows
What doesn't transfer:
✗ Stars and watchers
✗ Forks (remain under original owner)
✗ Deploy keys and secrets
✗ Webhooks
Archiving Repositories
Archive old projects that you no longer maintain:
Archive a Repository:
Settings → Danger Zone → Archive repository
Effects of archiving:
- Repository becomes read-only
- No new issues, PRs, or commits allowed
- Existing content remains visible
- Can still be forked and cloned
- Banner shows "This repo is archived"
- Can be unarchived later
When to archive:
- Project is complete and won't be updated
- Deprecated projects
- Superseded by newer version
- Historical reference only
Deleting Repositories
Permanently delete repositories you no longer need:
Delete a Repository:
Settings → Danger Zone → Delete this repository
⚠ Warning: This action is PERMANENT!
- All code and history lost forever
- Cannot be recovered by GitHub Support
- All issues and PRs deleted
- All forks become independent
- Releases and assets deleted
Before deleting:
1. Export/backup if you might need it
2. Notify collaborators
3. Check for dependencies
4. Consider archiving instead
5. Type repository name to confirm
Critical: Repository deletion is permanent and irreversible. Always create a backup before deleting. Consider archiving instead if you're unsure.
Cloning Your New Repository
After creating a repository on GitHub, clone it locally:
# Clone via HTTPS
git clone https://github.com/username/repo-name.git
# Clone via SSH (recommended)
git clone git@github.com:username/repo-name.git
# Clone to specific directory
git clone git@github.com:username/repo-name.git my-folder
# Clone specific branch
git clone -b develop git@github.com:username/repo.git
# Verify remote connection
cd repo-name
git remote -v
Connecting Existing Local Repo to GitHub
If you already have a local Git repository:
# Create empty repository on GitHub first (no README/license)
# Add GitHub as remote
git remote add origin git@github.com:username/repo-name.git
# Verify remote was added
git remote -v
# Push your code to GitHub
git push -u origin main
# If you have a different branch name:
git branch -M main # Rename current branch to main
git push -u origin main
Hands-On Exercise:
Create and configure a repository:
- Create a new public repository called "my-first-repo"
- Initialize it with a README, .gitignore (choose a template), and MIT license
- Edit the README to include:
- Project title and description
- Installation instructions
- Your contact information
- Add 3-5 relevant topics/tags to the repository
- Clone the repository to your local machine
- Create a new file locally, commit it, and push to GitHub
- Explore the repository settings
- Set up a branch protection rule for the main branch
Summary
In this lesson, you learned:
- How to create repositories on GitHub using web interface or CLI
- README.md files should be comprehensive and well-structured
- Choose appropriate licenses based on how you want code used
- .gitignore files prevent unwanted files from being tracked
- Repository settings control visibility, features, and protections
- Repositories can be transferred, archived, or deleted
- Connect local Git repositories to GitHub as remote
Next Up: In the next lesson, we'll explore GitHub Issues - a powerful system for tracking bugs, features, and project tasks!