Git & GitHub

Creating and Managing Repositories

13 min Lesson 19 of 35

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 ![Build Status](https://img.shields.io/badge/build-passing-brightgreen) ![Version](https://img.shields.io/badge/version-1.0.0-blue) # Screenshots ![Screenshot](docs/screenshot.png) # 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:

  1. Create a new public repository called "my-first-repo"
  2. Initialize it with a README, .gitignore (choose a template), and MIT license
  3. Edit the README to include:
    • Project title and description
    • Installation instructions
    • Your contact information
  4. Add 3-5 relevant topics/tags to the repository
  5. Clone the repository to your local machine
  6. Create a new file locally, commit it, and push to GitHub
  7. Explore the repository settings
  8. 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!