After this lesson, you will understand how to save changes to GitHub through commits, how to write meaningful commit messages, and how to use branches to work on different versions of your project. You will understand what pull requests are and how to use them for managing changes, and you'll be familiar with collaboration workflows that allow multiple people to work on the same project effectively.
You should have a GitHub account and have created at least one repository from Lesson 06. Understanding the basic GitHub interface and repository structure is necessary before learning workflow concepts.
A commit is a snapshot of your project at a specific point in time. When you make changes to files in your repository and save those changes, you create a commit that permanently records:
Commits are the building blocks of version control, allowing you to track your project's evolution and return to previous versions if needed.
Commits work like save points in a video game. Each time you make meaningful progress or complete a task, you create a commit that saves the current state of your files.
If you make a mistake later or want to see how your project looked at an earlier point, you can:
This differs from regular file saving because commits include a description of what changed and create a permanent historical record that can't be accidentally overwritten.
Commit messages are descriptions you write to explain what changed and why. Good commit messages help you and others understand the project's history at a glance.
When you view a repository's commit history, you see a list of messages that tell the story of how the project developed. Clear messages make it easy to:
Learn more about writing good commit messages in GitHub's commit message guidelines.
Effective commit messages follow a few guidelines:
1. Use Present Tense
Write in the present tense, describing what the commit does rather than what you did:
"Add responsive navigation styles""Added responsive navigation styles""I added responsive navigation styles"2. Be Concise but Descriptive
The message should be:
# Good short commit message
Fix typo in navigation link
# Good longer commit message
Add responsive navigation styles
- Implement mobile hamburger menu
- Add flexbox layout for desktop navigation
- Ensure accessibility with proper ARIA labels
Common commit message patterns include starting with action words:
"Add contact form to homepage""Fix navigation links on mobile""Update color scheme to blue palette""Remove unused CSS styles""Refactor navigation CSS for better organization"Following these patterns makes commit histories more readable and professional. See Conventional Commits for more detailed guidelines.
You can make commits to your GitHub repository directly through the web interface without installing any additional software. This approach is perfect for beginners and works well for HTML and CSS projects where you're making changes through the browser.
To edit a file and commit changes, navigate to your repository and click on the file you want to modify. You'll see a pencil icon in the top right of the file view. Clicking this icon opens the file in GitHub's built-in editor, which provides a text editing interface similar to a basic code editor. Make your changes to the file - you can modify HTML, CSS, or any text-based content directly in this interface.
After making changes, scroll down to the "Commit changes" section at the bottom of the page. Here you'll see two fields: a commit message field and an optional extended description field. The commit message field is required and should contain a brief description of your changes. For example, if you updated the color scheme of your website, you might write "Update color scheme to use blue palette" in the commit message field.
GitHub offers two options for how to commit: you can commit directly to the main branch, or you can create a new branch for the commit and start a pull request. For simple projects where you're working alone, committing directly to the main branch is fine. For learning purposes or when you want to review changes before they go live, creating a branch and pull request provides a safer workflow. We'll cover branches and pull requests in more detail later in this lesson.
Once you've written your commit message and chosen where to commit, click the green "Commit changes" button. GitHub saves your changes and creates a new commit in your repository's history. You can see this commit in the repository's commit history, which is accessible from the repository's main page. The commit includes your message, the exact changes made, and a timestamp showing when the commit was created.
This web-based workflow is accessible and straightforward, making it ideal for beginners. As you become more comfortable with GitHub, you might choose to use desktop applications or command-line tools that provide more advanced features, but the web interface remains a powerful and convenient way to manage your repositories.
Branches in Git and GitHub allow you to work on different versions of your project simultaneously without affecting the main version. Think of branches like alternate timelines - you can experiment with new features, try different approaches, or work on multiple tasks in parallel, all while keeping your main branch stable and functional.
The main branch (typically called "main" or "master"), represents the primary, stable version of your project. This is the version that's:
When you first create a repository, it starts with just the main branch. As your project grows, you might want to experiment with new features or redesigns without risking your stable main version. Branches let you create copies of your project where you can make changes safely.
Learn more about branches in GitHub's branches documentation.
When you create a new branch, you're creating an independent line of development that starts from the current state of your main branch. Changes you make on this new branch don't affect the main branch until you decide to merge them together.
This means you can:
Your main project remains unchanged and stable throughout this process.
Branches are especially useful when working on larger changes or multiple features simultaneously.
Example workflow:
"redesign-header" to work on updating your website's header"add-contact-form" to work on a new contact pageThis allows you to work on multiple features at once without conflicts or confusion.
Naming branches clearly helps you remember what each branch is for. Good branch names are:
Good examples:
fix-navigation-bug ✓add-responsive-images ✓update-color-scheme ✓Some teams use naming conventions like starting with prefixes:
feature/add-contact-formfix/navigation-mobileexperiment/new-layoutFor personal projects, clear descriptive names are sufficient. Choose a style that works for you and be consistent!
Understanding branches becomes increasingly valuable as projects grow. Even for simple websites, branches provide:
The ability to work on changes independently, test them thoroughly, and then merge them only when ready creates a professional workflow that scales from personal projects to large team collaborations.
Creating a branch on GitHub is straightforward through the web interface. You can create branches to experiment with changes, work on new features, or try different approaches to your design without affecting your main branch.
To create a new branch, navigate to your repository and look near the top left where you'll see a dropdown or button showing your current branch name, typically "main". Clicking this opens a branch selector interface. You'll see an option to create a new branch, or you can type a new branch name in a search field. When you type a branch name that doesn't exist, GitHub offers to create it for you.
After creating or switching to a branch, you'll see that branch name displayed where the branch selector was. Any commits you make now will go to this branch instead of main. The branch starts as an exact copy of main at the point you created it, so all your existing files and their current state are present. You can now make changes, edit files, and create commits on this branch without affecting main.
When working on a branch, the workflow is the same as working on main - you edit files, write commit messages, and save changes. The difference is that these changes exist only on your branch until you merge them. You can view your branch's commit history separately from main, seeing exactly what changes you've made. This isolation lets you experiment freely, knowing your main branch remains unchanged.
When you're ready to incorporate your branch's changes into main, you merge the branch. Merging combines the changes from your branch into main, bringing those commits and file modifications into the main branch. GitHub provides a simple interface for merging through pull requests, which we'll discuss next. After merging, your branch's changes become part of main, and you can continue working from there or create new branches for future features.
Pull requests, often abbreviated as PRs, are proposals to merge changes from one branch into another. While the name might suggest requesting someone else to pull your changes, pull requests are valuable even when working alone because they provide a structured way to review, discuss, and merge changes before they become part of your main branch.
When you create a pull request, you're proposing that changes from a branch should be merged into another branch, typically from a feature branch into main.
The pull request shows exactly what would change:
This preview allows you to review changes before they're merged, ensuring everything looks correct and works as intended.
Learn more in GitHub's pull requests documentation.
Pull requests include several important components:
"Update color scheme to green palette"This visual representation makes it easy to review changes before merging.
When working alone, pull requests serve as a review checkpoint. Before merging changes into main, you can:
This practice:
In collaborative projects, pull requests become essential communication tools. Team members can:
The pull request author can make additional commits to address feedback, and all of this discussion is preserved in the project history.
Even for solo projects, using pull requests:
For guidance on creating effective pull requests, see GitHub's creating pull requests guide.
This example demonstrates a complete workflow from creating a branch through making changes and merging them via a pull request. Following this process shows how branches and pull requests work together to create organized, reviewable changes to your project.
Start with an existing repository that has some HTML and CSS files. You want to update the color scheme of your website, but you want to experiment with this change without affecting your current working version. Begin by creating a new branch called "update-colors" using the branch selector in your repository interface.
After creating and switching to the new branch, edit your CSS file through GitHub's web interface. Make your color changes - perhaps updating the primary color from blue to green, or changing the background color scheme. Save these changes with a commit message like "Update color scheme to green palette". This commit exists only on your "update-colors" branch; your main branch remains unchanged.
Continue working on this branch if needed. You might realize you also want to adjust font sizes to work better with the new colors, so make another commit with those changes. Each commit builds on the previous one, and all of them exist only on your branch until you merge.
Once you're satisfied with your changes and want to incorporate them into main, create a pull request. Navigate to the "Pull requests" tab in your repository and click "New pull request". GitHub will ask you to select which branches to compare - choose your "update-colors" branch as the source and "main" as the destination. GitHub shows you a preview of what would change if you merge the pull request.
Write a clear title for your pull request, such as "Update website color scheme to green palette". In the description, explain what changed and why. For example, "This PR updates the color scheme from blue to green to better match the project's theme. Also includes font size adjustments to improve readability with the new colors." This description helps you remember the reasoning later and serves as documentation.
Review the changes GitHub shows in the diff view. Make sure all modifications look correct and that nothing unintended was changed. If you notice something that needs adjustment, you can make additional commits to your branch, and they'll automatically appear in the pull request.
When you're ready, click the "Merge pull request" button. GitHub merges your branch into main, incorporating all your commits and changes. After merging, you can delete the "update-colors" branch since its changes are now in main. Your main branch now contains your updated color scheme, and your website reflects these changes.
This workflow - create branch, make changes, create pull request, review, merge - might seem like extra steps for simple changes. However, it creates organized, reviewable changes and establishes habits that scale well as projects grow. Even for solo projects, this process helps catch mistakes and creates clearer project history.
GitHub's collaboration features allow multiple people to work on the same project simultaneously without conflicts or lost work. Understanding how collaboration works prepares you for working with others, whether on open-source projects, team assignments, or future professional development work.
When collaborating, each person works on their own copy of the repository, which they can modify independently. Contributors typically create branches for their work, make changes and commits on those branches, then propose merging those changes through pull requests. The repository owner or maintainers review pull requests and merge them when changes are approved. This workflow prevents conflicts and allows multiple people to work on different parts of the project simultaneously.
To collaborate on someone else's repository, you typically fork the repository, which creates your own copy linked to the original. You can make any changes you want in your fork without affecting the original repository. When you're ready to contribute your changes back, you create a pull request from your fork to the original repository. The repository owner reviews your pull request and can merge it if they approve your changes.
Alternatively, repository owners can add collaborators directly, giving them permission to create branches and pull requests within the same repository. This is common for team projects where everyone has equal contribution rights. Collaborators work on separate branches, create pull requests to propose changes, and review each other's work before merging.
GitHub's issue system complements collaboration by tracking bugs, feature requests, and tasks. Issues can be assigned to contributors, linked to pull requests that address them, and organized with labels. This creates a clear record of what work needs to be done and how it progresses through development.
Understanding these collaboration workflows prepares you for real-world development scenarios. Even when working alone, practicing with branches and pull requests develops skills that translate directly to professional environments where collaboration is essential. The ability to work effectively with version control and code review processes is highly valued in software development careers.
Practice the complete GitHub workflow by creating a branch in one of your repositories, making a small change such as updating colors or adding content, committing the change with a clear message, then creating a pull request to merge it back into main. Review the pull request to see how GitHub displays your changes, then merge it. After merging, verify that your changes appear in the main branch and delete the feature branch you created.
Create multiple commits on a branch to see how the commit history builds up. Make related changes across multiple files, committing each logical group of changes separately with descriptive messages. Observe how the pull request shows all commits and changes together, giving you a complete view of what would be merged before you finalize it.
Commits are snapshots of your project that record changes with descriptive messages, creating a permanent history you can review or return to. Branches allow you to work on different versions simultaneously, enabling experimentation without affecting your main branch. Pull requests provide a structured way to review and merge changes, serving as both a safety checkpoint and a record of what changed and why. Collaboration workflows use these tools to allow multiple people to work on projects simultaneously while maintaining code quality and clear project history.
These GitHub workflow concepts form the foundation of professional software development practices. Understanding commits, branches, and pull requests prepares you for both solo projects and team collaboration. The habits you develop - writing clear commit messages, using branches for features, and reviewing changes through pull requests - scale from simple websites to complex applications. These skills demonstrate professional competency and align with industry-standard development workflows.
Now that you understand GitHub workflows, Lesson 08 covers deploying your HTML and CSS websites to the internet using GitHub Pages. You'll learn how to publish your websites for free so anyone can visit them online.
GitHub. "Understanding the GitHub Flow." GitHub Guides. https://guides.github.com/introduction/flow/
GitHub. "About Pull Requests." GitHub Docs. https://docs.github.com/en/pull-requests/collaborating-with-pull-requests
Pro Git Book. "Git Branching." Pro Git. https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell
Atlassian. "Git Branching Tutorial." Atlassian Git Tutorials. https://www.atlassian.com/git/tutorials/using-branches