GitHub’s core innovation wasn’t version control; it was making distributed version control accessible and collaborative for everyone.
Let’s see what this looks like in practice. Imagine you’re working on a new feature for a project.
First, you need a place to store your code and track changes. This is a repository, or "repo."
# On your local machine, navigate to your project directory
cd /path/to/your/project
# If you haven't already, initialize Git
git init
# Create a new repository on GitHub's website (e.g., named 'my-awesome-project')
# Then, link your local repo to the remote GitHub repo
git remote add origin https://github.com/your-username/my-awesome-project.git
# Add your existing project files to be tracked
git add .
# Commit your changes with a descriptive message
git commit -m "Initial commit of project files"
# Push your local commit to the remote GitHub repository
git push -u origin main
Now, your code is on GitHub. If you want to work on a new feature, you create a branch. This is like a parallel universe for your code, so you don’t mess up the main working version.
# Create a new branch named 'new-feature' and switch to it
git checkout -b new-feature
You make your changes, add new files, delete old ones.
# Example: create a new file
echo "print('Hello, new feature!')" > feature.py
# Add the new file and any other modified files
git add feature.py
# Commit your changes on this branch
git commit -m "Add initial code for the new feature"
When you’re ready to merge your feature back into the main project, you create a pull request (PR). This is a formal request to "pull" your changes into another branch. It’s also where the collaboration happens.
On GitHub, you’d navigate to your repository, and you’ll likely see a prompt to create a pull request for your recently pushed branch. You’d click that, select main as the base branch (where you want to merge into) and new-feature as the compare branch (the one with your changes).
This PR page is crucial. It shows you exactly what changed. You can write a description explaining your feature, and critically, other team members can review your code, leave comments, and suggest improvements directly on the PR.
Think of issues as tasks, bugs, or feature requests for your project. They provide a centralized place to discuss and track work.
You can create an issue for a bug: "Fix login button alignment on mobile." Or for a new feature: "Implement user profile page."
On GitHub, go to the "Issues" tab and click "New issue."
Title: Fix login button alignment on mobile
Description: The login button on the homepage appears misaligned on smaller screen sizes. It needs to be centered.
Labels: bug, frontend
Assignees: your-username
When you create your pull request for the new-feature branch, you can link it to an issue. For example, by typing "Fixes #12" in the PR description, where #12 refers to issue number 12. This automatically closes the issue when the PR is merged.
The real power comes from the interplay: an issue defines the work, a branch isolates the development, and a pull request facilitates review and integration.
The git push command, when used with -u for the first time on a new branch, sets up a tracking relationship between your local branch and the remote branch. This means future git pull and git push commands on that branch will automatically know which remote branch to interact with, simplifying your workflow.
The next step is understanding how to manage merge conflicts when your branch has diverged significantly from the base branch.