Creating a Repository: Public vs Private, README, .gitignore, and License

Creating a new repository on GitHub involves a handful of upfront decisions that are easy to breeze past, but each has real consequences down the line: who can see your project, whether it starts with helpful boilerplate files, and what legal terms govern how others can use your code. This lesson walks through GitHub's 'Create a new repository' screen decision by decision.

Learning Objectives

• Create a new repository on GitHub using the web interface.
• Understand the practical difference between public and private repository visibility.
• Decide whether to initialize a new repository with a README, .gitignore template, and license.
• Choose an appropriate open-source license for a public project, at a high level.

Key Terms to Know Before Creating a GitHub Repository

• Public repository: A repository visible to anyone on the internet, viewable and clonable by anyone, though only collaborators can push changes.
• Private repository: A repository visible only to its owner and explicitly invited collaborators.
• gitignore template: A pre-built .gitignore file GitHub can automatically add during repository creation, tailored to a specific language or framework (e.g., Node, Python, Java).
• Open-source license: A legal document specifying how others are permitted to use, modify, and distribute a project's code, such as MIT, Apache 2.0, or GPL.
• Initialize with README: A GitHub option that automatically creates the repository with an initial commit containing a basic README.md file, rather than starting completely empty.

How Creating a GitHub Repository Actually Works

On GitHub's repository creation screen, the first meaningful decision is **visibility**: **public** or **private**. A public repository is visible to anyone on the internet — anyone can view its code, clone it, and read its history, though only people you explicitly add as collaborators can push changes to it. This is the standard choice for open-source projects, portfolio pieces, or anything you're comfortable sharing broadly. A private repository, by contrast, is visible only to you and anyone you specifically invite — appropriate for proprietary company code, personal projects you're not ready to share, or anything containing information you don't want publicly indexed. It's worth remembering, from Module 2's lesson on `.gitignore`, that visibility settings do **not** protect against secrets already committed to history — a private repository can still be made public later (intentionally or accidentally), so sensitive data should never rely on repository visibility alone as its only protection.

Next, GitHub offers to **initialize the repository with a README**. Choosing this creates the repository with a single initial commit containing a basic `README.md` file, rather than leaving it completely empty. This has a practical implication worth understanding: if you already have local project files ready to push (as in the practical exercise later in this module), initializing with a README creates a small mismatch — your local repository and the new GitHub repository will have different, unrelated initial commits, requiring an extra pull/merge step to reconcile them before you can push cleanly. For that reason, many developers *skip* auto-initializing with a README when they already have an existing local project to push, and instead only use this option when starting a brand-new project directly from GitHub with no local work yet.

GitHub also offers to add a **.gitignore template**, automatically populated with common ignore patterns for a specific language or framework (Node, Python, Java, and dozens of others) — a convenient starting point that saves manually writing the common patterns covered in Module 1's `.gitignore` lesson, though you can always add to or adjust it afterward.

Finally, GitHub offers to add a **license**. For a public repository, choosing a license is genuinely important — without one, default copyright law technically means others have no explicit legal permission to use, modify, or redistribute your code, even though it's publicly visible, which can create real ambiguity for anyone wanting to build on your work. Common choices include the **MIT License** (very permissive, allowing nearly any use with minimal restrictions, popular for its simplicity), **Apache License 2.0** (similarly permissive, but with additional explicit patent-related protections), and the **GPL family** (copyleft licenses that require anything built using your code to also be released under the same license terms). Choosing the specific right license for a project's goals is a deeper legal topic, but simply knowing that this decision exists — and that 'public' does not automatically imply 'free to use however you want' — is the essential takeaway for a beginner.

GitHub 'Create Repository' Screen: Visual Walkthrough

Draw a mockup of GitHub's 'Create a new repository' form with four labeled sections stacked vertically: 1) 'Repository name' (text field), 2) 'Visibility: ( ) Public ( ) Private' (radio buttons), 3) 'Initialize this repository with: [ ] Add a README file' (checkbox), 4) 'Add .gitignore: [Choose a template ▾]' and 'Add a license: [Choose a license ▾]' (two dropdowns). Add a callout arrow to the visibility radio buttons: 'Public = anyone can view/clone; Private = only you + invited collaborators.' Add a callout to the license dropdown: 'No license ≠ free to use — default copyright still applies without one.'

Public vs Private Repositories: Key Differences

Aspect	Public Repository	Private Repository
Who can view the code	Anyone on the internet	Only the owner and invited collaborators
Who can clone it	Anyone	Only those with explicit access
Typical use case	Open source, portfolios, learning projects	Proprietary company code, unpublished personal projects
Does visibility alone protect committed secrets?	No	No — history can still be exposed if made public later
License relevance	Strongly recommended to clarify usage rights	Less critical, since access is already restricted

Cloning a Newly Created GitHub Repository Locally

# After creating a repository on GitHub's website (e.g., named 'my-portfolio'),
# GitHub shows you a remote URL to connect it to a local project. Two common paths:

# Path A: Clone the new (possibly README-initialized) repo directly
git clone https://github.com/username/my-portfolio.git

# Path B: Connect an EXISTING local project to the new (empty) remote repo
cd my-portfolio        # existing local project folder
git init                # if not already a Git repo
git remote add origin https://github.com/username/my-portfolio.git
git push -u origin main

Breaking Down the New Repository Setup Example

Path A shows the simpler case: if you initialized the repository with a README on GitHub and have no existing local work yet, `git clone` is all that's needed to get a working local copy already connected to the remote. Path B shows the more common real-world case covered in this module's later lessons: connecting an *existing* local project (that wasn't created via GitHub's initializer) to a brand-new, empty remote repository, using `git remote add` (next lesson) and `git push -u` (covered in a later lesson) — this path deliberately avoids the README-initialization mismatch described above, since the remote starts completely empty.

How Repository Visibility and Licensing Are Used on Real Teams

• Open-source maintainers almost universally choose a permissive license like MIT or Apache 2.0 for libraries intended for broad adoption, since restrictive licensing can discourage companies from using the project at all.
• Companies frequently default all new internal projects to private visibility, only making specific repositories public deliberately, as part of an explicit open-source release process with legal review.
• Security incidents have occurred when a repository was made public without first auditing its commit history, exposing old commits containing credentials that were technically already 'private' but never actually removed from history (a callback to Module 1 and 2's .gitignore and git rm --cached lessons).
• GitHub's built-in .gitignore templates are frequently used as a fast starting point even by experienced developers, who then layer project-specific additions on top rather than writing an ignore file entirely from scratch.

GitHub Repository Creation Interview Questions and Answers

Q1. What is the practical difference between a public and a private GitHub repository?

A public repository is visible to anyone on the internet, who can view and clone it, though only invited collaborators can push changes. A private repository is visible only to its owner and specifically invited collaborators, making it appropriate for proprietary or unpublished work.

Q2. Why might you choose NOT to initialize a new GitHub repository with a README?

If you already have an existing local project ready to push, initializing the remote with a README creates a separate, unrelated initial commit on GitHub, causing a mismatch with your local repository's own history that requires an extra pull/merge step to reconcile before pushing cleanly.

Q3. Why does adding a license matter for a public repository?

Without an explicit license, default copyright law technically means others have no clear legal permission to use, modify, or redistribute the code, even though it's publicly visible. Adding a license like MIT or Apache 2.0 clarifies exactly what others are permitted to do with the project.

Creating a GitHub Repository Quiz: Test Your Understanding

1. What is the key difference between a public and private GitHub repository?

1. Public repositories cannot be cloned by anyone
2. Public repositories are visible to anyone on the internet; private repositories are visible only to the owner and invited collaborators
3. Private repositories cannot have collaborators
4. There is no functional difference, only a label

Answer: B. Public repositories are visible to anyone on the internet; private repositories are visible only to the owner and invited collaborators

Explanation: Visibility controls who can view and clone a repository — public repositories are open to anyone, while private repositories restrict access to explicitly invited people.

2. Why might initializing a new GitHub repository with a README cause a complication for an existing local project?

1. It automatically deletes the local project's files
2. It creates a separate, unrelated initial commit on the remote, causing a history mismatch that needs reconciling before pushing
3. README files cannot be edited after creation
4. It disables the ability to push to that repository

Answer: B. It creates a separate, unrelated initial commit on the remote, causing a history mismatch that needs reconciling before pushing

Explanation: GitHub's README initialization creates its own commit on the remote, which doesn't share history with an existing local project's commits, requiring an extra step to merge the two before a clean push.

3. Does making a repository public automatically grant others legal permission to reuse the code freely?

1. Yes, public visibility implies free use automatically
2. No — without an explicit license, default copyright still applies even to public code
3. Only if the repository has more than 100 stars
4. Only for repositories written in certain programming languages

Answer: B. No — without an explicit license, default copyright still applies even to public code

Explanation: Public visibility only controls who can view and clone a repository; it does not itself grant legal permission to reuse the code, which requires an explicit license.

Common Mistakes When Creating a New GitHub Repository

• Assuming a private repository is a sufficient safeguard for secrets, without realizing visibility can be changed later and doesn't erase already-committed sensitive history.
• Initializing a new remote repository with a README when an existing local project is about to be pushed, creating an avoidable history mismatch.
• Publishing a public repository with no license at all, leaving other potential users legally uncertain about whether they're allowed to use the code.
• Choosing a restrictive license (like a strong copyleft GPL variant) without understanding its implications, when a more permissive license would have better suited the project's actual goals.

Creating a GitHub Repository: Exam-Ready Quick Notes

• Public: visible to anyone, clonable by anyone; only collaborators can push. Private: visible only to owner + invited collaborators.
• Initializing with a README creates an initial commit on the remote — can cause a history mismatch with an existing local project.
• .gitignore templates: pre-built ignore patterns for a specific language/framework, added automatically during creation.
• No license ≠ free to use — public visibility alone does not grant legal permission to reuse code.

Creating a GitHub Repository: Key Takeaways

• Repository visibility (public/private) controls who can view and clone a project, but is not itself a substitute for properly excluding secrets from history.
• Whether to auto-initialize with a README depends on whether you already have existing local work ready to push.
• A license is an important, often-overlooked decision for public repositories, clarifying what others are legally permitted to do with your code.

Frequently Asked Questions About Creating GitHub Repositories

Q1. What is the difference between a public and a private repository on GitHub?

A public repository can be viewed and cloned by anyone on the internet, though only people you invite as collaborators can push changes to it. A private repository is visible only to you and anyone you specifically invite.

Q2. Should I initialize my new GitHub repository with a README?

If you already have an existing local project ready to push, it's usually better to skip auto-initializing with a README, since doing so creates a separate initial commit on the remote that can complicate pushing your existing history. If you're starting completely fresh with no local work yet, initializing with a README is a convenient option.

Q3. What is a .gitignore template on GitHub?

It's a pre-built .gitignore file GitHub can automatically add when creating a repository, tailored to a specific language or framework like Node.js or Python, saving you from manually writing common ignore patterns from scratch.

Q4. Do I need to add a license to my public repository?

It's strongly recommended. Without an explicit license, default copyright law technically means others don't have clear legal permission to use, modify, or redistribute your code, even though it's publicly visible on GitHub.

Q5. Does making a repository private protect any secrets I've already committed?

Not fully. While it restricts who can currently view the repository, if it's ever made public later (intentionally or by mistake), any secrets already committed to its history would be exposed. Sensitive data should always be properly excluded using .gitignore and git rm --cached, not just hidden behind private visibility.

Summary

Creating a new GitHub repository involves several meaningful decisions beyond just picking a name. Visibility determines whether the repository is public (viewable and clonable by anyone, though only collaborators can push) or private (visible only to the owner and invited collaborators) — though visibility alone never protects secrets already committed to history. Choosing whether to initialize with a README matters most when an existing local project is about to be pushed, since auto-initializing creates a separate initial commit that can complicate a clean push. GitHub's built-in `.gitignore` templates offer a convenient, language-specific starting point for ignore patterns. Finally, adding a license is important for public repositories, since without one, default copyright law leaves others without explicit legal permission to reuse the code, regardless of its visibility.