A GitHub account gives you an online identity, but a repository is where an actual software project begins to take shape.
A repository, often shortened to repo, contains the files that belong to a project together with the history of changes recorded for those files. On GitHub, the repository page also provides tools for browsing code, reviewing commits, managing issues, and collaborating with other people.
Creating a repository takes only a few minutes. The important part is understanding the choices GitHub presents during setup. A repository name becomes part of its URL. Visibility determines who can see it. A README explains the project. A .gitignore file helps prevent unnecessary or sensitive files from being tracked. A license tells other people what they are allowed to do with public code.
This guide explains those choices so that your first repository starts with a clear and manageable structure.
Version note: GitHub may change button names, page layouts, default branch behavior, and repository options. Before publication, compare interface-specific instructions with GitHub’s current official documentation.
What You Will Learn
By the end of this guide, you should be able to:
- explain what a GitHub repository contains;
- create a repository from your GitHub account;
- choose a clear repository name;
- decide between public and private visibility;
- understand the purpose of a README file;
- understand what
.gitignore does; - recognize when a software license is needed;
- navigate the main parts of a new repository page;
- distinguish a GitHub repository from a local project folder.
This article focuses on creating a repository through the GitHub website. We will connect local files and use Git commands in later guides.
What a Repository Actually Contains
A repository is more than an online folder.
At a basic level, it includes:
- project files;
- directories;
- documentation;
- configuration files;
- commit history;
- branches;
- repository settings.
A normal project might look like this:
first-vibe-coding-project/
├── README.md
├── index.html
├── styles.css
├── script.js
└── .gitignore
The visible files are only one part of the repository.
Git also records the history of changes. That history can answer questions such as:
- When was this file added?
- Which lines changed?
- Who made the change?
- What did the project look like before the change?
- Which branch contains a particular version?
GitHub displays this information through a web interface.
A Local Repository and a GitHub Repository
A local repository exists on your computer.
A remote repository exists on a hosting platform such as GitHub.
These can represent the same project, but they are separate copies.
A simplified relationship looks like this:
Your computer
└── Local Git repository
↕
GitHub
└── Remote repository
Changes do not automatically move between them unless a tool or workflow performs that synchronization.
Later, you will use Git commands such as push and pull to transfer recorded changes between the local and remote repositories.
For this guide, we will create only the GitHub side.
Start a New Repository
Sign in to your GitHub account.
Look for an option to create a new repository. Depending on the current interface, this may appear as:
- a New repository button;
- a plus icon with a New repository option;
- a button on the repositories page;
- a prompt on an empty account dashboard.
Open the repository creation page.
You should see fields for details such as:
- repository owner;
- repository name;
- description;
- visibility;
- initialization options.
Review each choice rather than accepting every default immediately.
Choose the Repository Owner
The owner appears before the repository name in the URL.
For a personal repository, the owner will usually be your GitHub username.
The URL will follow a pattern similar to:
https://github.com/your-username/repository-name
If you belong to one or more GitHub organizations, the page may allow you to choose an organization as the owner.
For this beginner exercise, use your personal account unless you have a specific reason to create the project inside an organization.
Organization repositories may be affected by:
- company policies;
- access controls;
- required security settings;
- naming conventions;
- visibility restrictions;
- approval workflows.
Do not place personal learning projects in an employer’s organization without permission.
Choose a Clear Repository Name
The repository name becomes part of the project’s URL, so it should be understandable and easy to type.
For this exercise, you can use:
vibe-coding-practice
A practical repository name should be:
- short enough to remember;
- specific enough to identify the project;
- written with simple lowercase words;
- separated with hyphens when needed;
- free of private or confidential information.
Examples of clear names include:
task-tracker
weather-dashboard
markdown-notes
vibe-coding-practice
Examples that may create confusion include:
project
test
new-app-final
thing2
my-code
A generic name such as project gives little context when you later have many repositories.
A name such as new-app-final may also become inaccurate. Software projects change over time, so terms such as final, latest, and new usually age poorly.
Avoid Sensitive Information in Repository Names
Repository names may be visible in URLs, browser history, screenshots, logs, and connected services.
Do not include:
- client names without permission;
- internal project codenames;
- customer identifiers;
- private company information;
- personal account numbers;
- secret values.
Even a private repository has a name that may appear in local configuration or third-party integrations.
Add a Useful Description
The repository description is a short summary displayed near the top of the project page.
For this practice repository, you might use:
A beginner workspace for learning GitHub, Git, and AI-assisted coding.
A good description answers one question:
What is this repository for?
It does not need to explain every feature.
Compare these examples:
Unclear:
My coding project.
More useful:
A simple browser-based task tracker built while learning AI-assisted development.
The description can be changed later, so it is acceptable for an early project to have a simple summary.
Choose Public or Private Visibility
GitHub normally asks whether the repository should be public or private.
Public Repository
A public repository can generally be viewed by anyone.
This is useful for:
- open-source projects;
- tutorial examples;
- public portfolios;
- shared learning resources;
- reproducible demonstrations.
Public repositories can also appear in search engines, links, forks, archives, and external tools.
Never assume you can remove every copy later. Someone may clone, fork, or archive public content before you delete it.
Private Repository
A private repository is limited to the owner and authorized collaborators or services, according to current GitHub permissions.
This is useful for:
- early experiments;
- personal projects not ready to share;
- private notes;
- unpublished book examples;
- work that requires controlled access.
Private does not mean that secrets should be stored carelessly.
A private repository can still be exposed through:
- account compromise;
- accidental permission changes;
- connected applications;
- copied files;
- screenshots;
- collaborator access;
- configuration mistakes.
Passwords, tokens, and API keys should still be kept outside tracked source files.
Which Visibility Should a Beginner Choose?
For a simple practice repository containing no personal or sensitive information, either option can work.
Choose private when you want a low-pressure workspace while learning.
Choose public when the repository is intentionally designed as a safe tutorial example and you are comfortable with anyone reading it.
Before creating a public repository, verify that the name, description, files, and account profile do not reveal information you did not intend to share.
Decide Whether to Add a README
GitHub may offer an option to initialize the repository with a README file.
For a repository created directly on GitHub, adding a README is a useful beginner choice.
A README is usually a Markdown file named:
README.md
It commonly explains:
- what the project does;
- why it exists;
- how to run it;
- which tools it uses;
- what remains unfinished;
- where to find related documentation.
GitHub normally displays the README on the main repository page.
For the practice repository, a simple README might contain:
# Vibe Coding Practice
This repository is a beginner workspace for learning GitHub, Git, and AI-assisted development.
## Current Goals
- Understand repository structure
- Learn basic version control
- Practice small, reviewable changes
You can improve it later as the project develops.
When You Might Leave the Repository Empty
If you already have a local Git repository with existing files and commit history, you may choose not to initialize the GitHub repository with a README, .gitignore, or license.
This can make the first connection simpler because the remote repository does not start with a separate commit.
However, that is not the workflow for this article.
For this beginner exercise, creating the README on GitHub gives you a visible first file and commit to explore.
Understand .gitignore
Git tracks project files, but not every file belongs in version control.
A .gitignore file lists patterns for files and directories that Git should normally leave untracked.
Common examples include:
- dependency directories;
- build output;
- temporary files;
- editor-specific files;
- operating-system metadata;
- local environment files.
A simplified .gitignore might contain:
node_modules/
.env
dist/
This tells Git to ignore:
- the
node_modules dependency directory; - a local
.env file; - the
dist build-output directory.
Why Ignore Dependency Folders?
Some package managers can recreate dependencies from a smaller configuration file.
Tracking thousands of generated dependency files can make a repository unnecessarily large and difficult to review.
Why Ignore .env Files?
A .env file often contains local configuration, including values such as:
- API keys;
- database addresses;
- service credentials;
- environment-specific settings.
Ignoring .env reduces the risk of committing it accidentally.
However, .gitignore is not a complete security system.
If a secret has already been committed, adding the file to .gitignore does not remove it from earlier history. The credential should be treated as exposed and replaced.
Should You Select a .gitignore Template Now?
GitHub may provide templates for languages and frameworks.
Select one only when you know which technology the project will use.
For a general practice repository, you can leave this option unselected and add a suitable .gitignore later.
Choosing an unrelated template can hide files you actually intended to track.
Understand Software Licenses
GitHub may also offer an option to add a license.
A software license tells other people what they may do with the code.
Without a license, publicly visible code is not automatically free for unrestricted reuse.
A license may define whether others can:
- use the software;
- copy it;
- modify it;
- redistribute it;
- include it in other projects;
- use it commercially.
Different licenses have different requirements.
Some require attribution. Some require derivative work to use the same license. Others are more permissive.
Should a Beginner Add a License?
Add a license when:
- the repository is public;
- you want others to reuse the code;
- you understand the basic terms of the license;
- the project does not contain code you lack permission to license.
You may leave the license unselected when:
- the repository is private;
- the project is only a personal exercise;
- the licensing decision has not been made;
- the repository contains third-party material that requires review.
Do not select a license at random simply because GitHub provides a list.
Licensing has legal implications. For an important project, review the official license text and seek appropriate advice when needed.
For this practice repository, leaving the license blank is acceptable.
Create the Repository
For this exercise, use the following choices:
Owner: your personal GitHub account
Repository name: vibe-coding-practice
Description: A beginner workspace for learning GitHub, Git, and AI-assisted coding.
Visibility: Public or private, based on your preference
README: Add a README
.gitignore: None for now
License: None for now
Select the button to create the repository.
GitHub should take you to the new repository page.
If a repository with the same name already exists under your account, choose another clear name, such as:
vibe-coding-practice-2026
Avoid adding a meaningless random number unless necessary.
Understand the New Repository Page
The page contains several important areas.
File List
The main section shows files and directories in the current branch.
For this repository, you should see:
README.md
Selecting the filename opens the file.
README Preview
The rendered README normally appears below the file list.
Markdown headings, lists, links, and code blocks are displayed as formatted content.
This makes the README useful as the project’s front page.
Commit Information
Near the file list, GitHub may display information about the latest commit.
Because the repository was initialized with a README, GitHub created an initial commit.
A commit records a project checkpoint.
Open the commit history if the interface provides a link. You should see the initial repository commit.
This is the first example of version history in the series.
Branch Selector
The repository page normally includes a branch selector.
A branch is an independent line of development within the repository.
The first branch may be named main, depending on current account and repository defaults.
For now, remain on the default branch.
Branches will become more useful when you want to develop a feature without immediately changing the main version of the project.
Repository Navigation
You may see sections such as:
- Code;
- Issues;
- Pull requests;
- Actions;
- Projects;
- Security;
- Insights;
- Settings.
You do not need to configure all of them.
For this series, the most relevant areas are:
- Code for files and history;
- Issues for tracking work or problems;
- Pull requests for reviewing proposed changes;
- Settings for repository configuration.
Some sections may be hidden, renamed, disabled, or unavailable depending on repository visibility and account settings.
Make a Small README Edit
To become familiar with the interface, edit the README directly on GitHub.
Open README.md and select the edit option.
Replace or expand the content with:
# Vibe Coding Practice
This repository is a beginner workspace for learning GitHub, Git, and AI-assisted software development.
## Learning Goals
- Understand how repositories organize project files
- Learn how Git records changes
- Practice reviewing AI-generated code
- Build small features one step at a time
GitHub should show an area where you describe the change.
Use a clear commit message such as:
Expand README with learning goals
Complete the commit.
Return to the repository page and confirm that the updated README is displayed.
You have now created another recorded change without using the command line.
What a Commit Message Should Explain
A commit message should summarize the purpose of the change.
Useful messages include:
Add project overview to README
Document local setup steps
Fix broken link in documentation
Weak messages include:
Update
Changes
Stuff
Final
A good message helps future readers understand the history without opening every changed file.
When AI tools begin modifying code, clear commit messages become even more valuable because they help separate one task from another.
Common Repository Setup Mistakes
Using a Generic Name
Names such as test, project, and app become confusing when your account contains multiple repositories.
Use a name that describes the project’s purpose.
Creating a Public Repository with Private Information
Check the repository name, description, README, and files before making the project public.
Do not include internal URLs, credentials, client names, or personal data.
Treating Private Visibility as Secret Management
Private repositories still require careful access control.
Do not commit secrets simply because the repository is private.
Selecting the Wrong .gitignore Template
An unrelated template may ignore files the project needs.
Choose a template only after the technology is known.
Adding a License Without Understanding It
A license affects how others may use the code.
Do not choose one only because it appears popular.
Confusing a GitHub Repository with a Local Backup Folder
The remote repository does not automatically contain every file on your computer.
Only files added through GitHub or transferred through Git workflows become part of the repository.
Editing Important Code Directly on GitHub Without Testing
Browser editing is acceptable for small documentation changes.
For source code, local editing is usually safer because you can run tests before committing.
Later articles will establish that local workflow.
Verify Your First Repository
Before finishing, confirm that:
- the repository appears under your GitHub account;
- the name is clear and correctly spelled;
- the visibility matches your intention;
- the description explains the project;
- the README is displayed;
- the repository has at least one commit;
- the default branch is visible;
- you can open the commit history;
- no personal or sensitive information is exposed;
- you can find the repository settings.
Copy the repository URL.
It should look similar to:
https://github.com/your-username/vibe-coding-practice
Open it in a signed-out or private browser window.
If the repository is public, the page should be visible.
If it is private, GitHub should not display the repository contents to a signed-out visitor.
This is a simple way to verify the visibility setting.
Conclusion
A GitHub repository combines project files with a visible history of changes and online collaboration features.
The setup choices made at creation time establish the foundation of the project. A clear name makes the repository easier to identify. Visibility controls who can see it. A README explains its purpose. A .gitignore file helps exclude unnecessary local files. A license defines reuse rights when you intentionally publish code for others.
You have now created the remote repository that will support the next part of the series.
The next article will step back from the GitHub interface and explain how version control works. We will look at the working directory, staging area, commits, branches, local repositories, and remote repositories before using Git commands in practice.
Frequently Asked Questions
Can I change a repository from private to public later?
GitHub generally allows repository visibility changes, but the consequences should be reviewed carefully.
Before making a private repository public, inspect its complete contents and history for secrets, private information, and files that were never intended for publication. Deleting a file from the latest version does not necessarily remove it from earlier commits.
Do I need a README in every repository?
A README is not technically required, but it is useful for most projects.
Even a short README can explain what the project does, how to run it, and whether it is still experimental.
Should I add a .gitignore before writing code?
It is a good idea to add an appropriate .gitignore before tools generate dependencies, build output, environment files, or editor-specific files.
The correct template depends on the project’s programming language and framework, so it is reasonable to wait until those choices are known.
Comments
Post a Comment