Manage code, sync, and deploy inside one platform.
Topics
What's the difference between Git and GitHub?
How do I create a new repository on GitHub?
What should I include in commit messages?
How do I fix merge conflicts?
This guide provides a direct path for using GitHub. Learn to set up your account, create repositories, and use commands. Understand version control with branches and the pull request workflow for better code management and collaboration.
So, you've heard about GitHub and want to get started? Perfect timing. Whether you're building your first project or joining a development team, learning how to use GitHub is like gaining access to the modern developer's toolkit. This guide walks you through everything from creating your first repository to mastering collaboration workflows. Ready to transform how you manage code?
Think of GitHub as the home base for your project. While Git handles version control on your computer, GitHub takes it online where magic happens. You can save your work, share with others, and track every single change. Over 150 million developers use this platform for good reason.
GitHub combines Git's powerful version control with social features that make collaboration seamless and efficient. You get repositories to store source code, tools to manage different versions, and features like pull request workflows that streamline teamwork. The platform supports every programming language you can think of.
Your GitHub profile becomes your professional portfolio. Recruiters browse GitHub profiles, checking your code quality and contribution history, much like they would a resume. Public repositories showcase your skills, while private ones keep sensitive projects secure.
Getting started requires two simple steps: creating a GitHub account and installing Git on your computer. Head to GitHub.com and sign up with your email address. Please choose a username carefully, as it will become part of your GitHub profile URL. This username appears in all your repository links.
Next, install git on your operating system. Windows users can download Git for Windows. MacOS users should run’brew install git' in the terminal. Linux users can use their package manager. The installation includes Git Bash, a command-line interface that works consistently across platforms.
Configure Git with your details using basic commands:
1 2git config --global user.name "Your Name" git config --global user.email "your.email@example.com"
These settings connect your local Git work with your GitHub identity. Every commit you make will include this information, creating a clear history of who changed what.
Your Project's Container: A repository (or "repo") is a digital folder that holds everything related to your project. 📦
Complete History: It stores all your files, tracks every change, and maintains a complete history of the project's development over time.
You have two primary ways to start a repository:
1. On GitHub (The Remote-First Approach)
Click the green "New" button on the GitHub website.
Configure Your Repo:
◦ Name: Choose a short, descriptive name.
◦ Visibility: Decide if it should be Public (visible to everyone) or Private (restricted access).
◦ Add a README: It's highly recommended to initialize the repository with a README.md file. This file serves as the front page of your project, explaining its purpose, installation instructions, and how others can contribute.
2. Locally (The Local-First Approach)
Open a terminal or command prompt on your computer.
Navigate to your project's root folder.
Run the command git init
This creates a hidden .git subfolder, which turns your project directory into a Git repository and starts tracking all version control information.
This diagram illustrates the fundamental steps to get your code from your local machine to your GitHub repository.
Code snippet
In this process, you add your files to a staging area, commit them as a saved version, and then push that version to your GitHub repository.
Stop switching between your editor and GitHub just to manage code. Build, sync, and deploy your next great application entirely within DhiWise Rocket.
While there are many Git commands, your daily workflow will be built on a small, powerful set. Mastering these is the key to efficient version control.
git status- Your Project's Dashboard
◦ Purpose: Use this command to get a "health checkup" of your repository at any time.
◦ What it shows:
▪ Which files have been modified?
▪ Which files are "staged" and ready for the next commit?
▪ The current branch you are working on.
git add- Staging Your Changes
◦ Purpose: This command prepares your modified files for a commit. "Staging" allows you to select precisely which changes to include in your next saved version.
◦ How to use it:
▪ git add <filename.txt>
to stage a single, specific file.
▪ git add.
to stage all modified files in the current directory.
git commit- Saving Your Progress
◦ Purpose: A commit is a snapshot of your staged changes at a specific point in time. It permanently saves your work to the project's history.
◦ How to use it:
▪ git commit -m "Your descriptive message here"
◦ Best Practice: Always write clear and specific commit messages (e.g., "Add user authentication feature"). This explains what changed and why, which is incredibly helpful for you and your team in the future.
| Command | Purpose | Example |
|---|---|---|
| git status | Check repository state | git status |
| git add | Stage files | git add index.html |
| git commit | Save changes | git commit -m "Fix login bug" |
| git push | Upload to remote | git push origin main |
| git pull | Download changes | git pull origin main |
| git clone | Copy repository | git clone https://github.com/user/repo.git |
Let’s find out how to work with branches and handle version control in Git.
Purpose: Branches allow you to work on new features, bug fixes, or experiments in an isolated environment without affecting the main, stable code.
Main Branch: This branch (main or master) contains the stable, production-ready version of your project.
Feature Branches: These are separate lines of development created to work on a specific task. This separation prevents unstable or incomplete code from breaking your main project.
Create a New Branch: Use this command to create a new branch and switch to it immediately.
◦ git checkout -b <feature-name>
◦ (Newer syntax): git switch -c <feature-name>
Use Descriptive Names: Choose clear and descriptive names for your branches to make project navigation easier (e.g., add-payment-system, fix-navbar-bug ).
Switch Between Branches: To move from one branch to another, use:
◦ git checkout <branch-name>
◦ Each branch maintains its version of the files, allowing for parallel development.
Merging: This process combines the changes from your feature branch back into the main branch.
◦ Command:
git merge <feature-branch>
◦ Automatic Merging: Git attempts to automatically combine the changes.
◦ Merge Conflicts: Conflicts occur when the same lines of code are changed in both branches. These must be resolved manually.
Viewing History: To see a log of all previous commits and changes in your project, use:
◦ git log
Reverting to a Previous State: Version control acts as a safety net. You can revert your project to any previous commit if something goes wrong.
◦ Command: git checkout <commit-hash>
Organized Codebase: Using branches helps maintain a clean and manageable project structure, with different versions (stable, development, feature work) existing simultaneously.
Pull Requests are a core feature of GitHub, enabling the proposal and discussion of changes to a codebase.
Formal Change Proposals: They allow you to show others the changes you've made and ask for them to be merged into a different branch (usually the main branch).
Quality Assurance: The process involves reviewing contributions before they are integrated, which helps maintain code quality and facilitates team collaboration.
Isolate Your Changes:
Start by creating a new branch in your repository or by forking another person's repository.
Make all your code changes within this separate branch.
Create the Pull Request:
Push your branch to GitHub.
Open a pull request, comparing your new branch to the branch you want to merge your changes into.
The Review Process:
Visual Interface: The PR interface clearly shows all additions (in green) and deletions (in red).
Feedback Loop: Reviewers can comment on specific lines of code to ask questions, suggest improvements, or approve the changes. This is a critical step for improving code quality.
Team Approvals: Many teams require one or more approvals from other members to ensure consistency and catch potential bugs.
Automated Checks: Projects can be set up to automatically run tests on a PR to check for errors before a human reviewer even looks at it.
Provide Clear Descriptions:
Explain what you changed and why.
It's good practice to link to any relevant issues, note any significant "breaking changes," and give instructions for how to test your changes.
Merge the Pull Request:
Once your PR is approved, you can merge it directly from the GitHub interface.
You can choose from different merge strategies (like merge, squash, or rebase), which affect how the project's commit history is recorded.
A remote repository is your project's central hub hosted on GitHub's servers, separate from the local copy on your computer. The workflow involves pushing your local changes to the remote repo and pulling others' changes from it to stay in sync.
Remote Repository: This is your project's home on GitHub's servers. It acts as the central source of truth for your codebase.
Local Repository: This is a complete copy of the project that lives on your own computer, where you do your actual work.
Connecting Them: Your local copy is linked to one or more remote repositories. The default name for your main remote connection is origin.
The entire process is a cycle of communication between your local and remote repositories.
Develop Locally: You make changes, create commits, and work on your code privately on your computer for maximum speed.
git push (Upload): When you're ready to share your work, you use the git push command. This uploads your committed changes from your local repository to the remote one on GitHub.
git pull (Download): To get the latest changes made by your collaborators, you use the git pull command. This downloads their contributions from the remote repository to your local machine.
Synchronization: This push-and-pull process ensures that everyone on the team stays aligned and works with the most up-to-date version of the code.
Troubleshooting: If the workflow is interrupted, you should first check your internet connection and verify that the remote repository URLs are correct.
Authentication: GitHub now often requires Personal Access Tokens (PATs) instead of traditional passwords for better security.
Multiple Remotes: You can connect your local repository to more than one remote. A common advanced workflow involves:
◦ origin : Points to your personal fork (your copy) of a project.
◦ upstream : Points to the original repository you forked from.
◦ This setup is very useful for contributing to open-source projects.
This connection links the project folder on your computer to its central repository hosted on GitHub's servers. Establishing this link securely with proper authentication enables you to push your local work and pull updates from the team.
Git Remotes: The link between your computer (local) and GitHub (remote) is established through a "remote." This is a pointer to your repository's location on GitHub's servers.
Automatic Setup: When you use git clone to copy a repository to your machine, Git automatically sets up this remote connection for you.
Manual Setup: If you initialize a Git repository locally (git init), you must manually add the remote URL using specific commands.
Securing the connection is crucial. GitHub has moved away from simple passwords to more robust methods.
Personal Access Tokens (PATs):
◦ These are now the standard alternative to passwords for HTTPS connections.
◦ You generate a token in your GitHub account settings and use it in place of a password when prompted.
SSH Keys:
◦ This method involves creating a cryptographic key pair (a public and a private key) on your computer.
◦ You add the public key to your GitHub account.
◦ SSH connections are often more convenient and efficient for developers who push and pull frequently.
It's a good practice to test your connection to prevent errors before you start significant work.
Check Remote URLs: Verify that your local repository is configured to point to the correct remote URL.
git remote -vTest with a Push/Pull: Perform a simple operation to ensure authentication is working correctly.
git pull origin mainIf you use multiple GitHub accounts (e.g., one for personal projects and another for work) on the same machine, you'll need to perform careful configuration.
The most common solution is to use different SSH keys for each account and configure Git to use the correct key for the corresponding repository.
Here are the fundamental commands for getting started:
1 2 3 4 5 6 7 8 9 10 11# Clone a repository, which also sets up the remote connection git clone https://github.com/username/repository.git # Navigate into your new project directory cd repository # Check the remote connection you just created git remote -v # Test the connection by pulling the latest changes git pull origin main
Mastering GitHub organizes your development workflow, turning chaos into structure. By using repositories, Git commands, and pull requests, you build the essential skills for modern software development.
Your expertise will grow with consistent practice. Start with simple projects and gradually move to more complex ones. The developer community is welcoming, so feel free to ask questions, contribute to other projects, and share your work to accelerate your learning. Your journey is just beginning—stay curious, keep experimenting, and remember that every expert started from this same point.