The Git & Github Bootcamp Part 5 - Master on essentials and the tricky bits: rebasing, squashing, stashing, reflogs, blobs, trees, & more!

GitHub Grab Bag: Odds & Ends

GitHub Repo Visibility: Public Vs. Private

• Public repositories are visible to everyone on the internet, and anyone can contribute to your project.
• Private repositories are hidden from the public and only accessible to you and the people you choose to share access with.

Adding GitHub Collaborators

To collaborate with others on private projects, you need to add them as collaborators:

1. Go to your repository on GitHub.
2. Click on “Settings” > “Manage access” > “Invite a collaborator.”
3. Enter their GitHub username and send the invite.

GitHub Collaboration Demo

After adding collaborators, they can clone the repository, make changes, push commits, and create pull requests. This workflow allows you to review and discuss changes before integrating them into the main project.

What are READMEs?

A README file provides information about your project, such as what it does, how to install or use it, and how to contribute. It’s the first thing people see when they visit your repository, making it an essential tool for communicating with potential users and contributors.

A Markdown Crash Course

READMEs are often written in Markdown, a lightweight markup language with plain-text formatting syntax. Here are some basics:

• # for headings
• * for bullet lists
• ``` for code blocks
• [title](URL) for links
• ![alt text](image URL) for images

Adding a README To A Project

1. Create a new file named README.md in your project root.
2. Use Markdown to add sections like Introduction, Installation, Usage, and Contributing.
3. Commit and push the README.md to your GitHub repository.

Creating GitHub Gists

Gists are a great way to share code snippets, files, and full applications. To create a gist:

1. Go to gist.github.com.
2. Enter your code or text, add a filename, and choose whether the gist will be public or private.
3. Click “Create secret gist” or “Create public gist.”

Introducing GitHub Pages

GitHub Pages allows you to host a website directly from your GitHub repository. It’s perfect for project documentation, personal portfolios, and small websites.

GitHub Pages Demo

To create a GitHub Pages site for your project:

1. Go to your repository on GitHub.
2. Navigate to “Settings” > “Pages.”
3. Choose a source branch (usually main or gh-pages) and a folder (root or /docs).
4. Click “Save,” and GitHub will provide you with a URL to access your site.

Through these topics, you’ve enhanced your “SampleProject” with informative documentation, collaboration capabilities, code sharing through gists, and even set up a website using GitHub Pages. These tools not only make your project more accessible and easier to use but also open up avenues for collaboration and sharing your work with the world.

In the context of our “SampleProject” hosted on GitHub, let’s dive into various Git collaboration workflows. These workflows are fundamental to working on shared projects efficiently and safely, ensuring code integrity and facilitating teamwork.

Git Collaboration Workflows

1. The Pitfalls Of A Centralized Workflow

A centralized workflow involves all collaborators committing directly to a single branch (usually main or master). While simple, this can lead to conflicts and issues with code quality, especially as the team size increases.

2. Centralized Workflow Demonstration

In a small team or solo project, you might work directly on the main branch, committing changes as you go. However, this simplicity comes at the cost of potential merge conflicts and difficulty in tracking features or bug fixes.

3. The All-Important Feature Branch Workflow

The feature branch workflow involves creating a new branch for each new feature or bug fix, isolating these changes from the main codebase until they’re ready to be merged. This allows for more organized development and easier code review.

4. Feature Branch Workflow Demo

For “SampleProject”:

1. Create a new branch for your feature: git switch -c feature-x.
2. Make changes and commit them to feature-x.
3. Push the feature branch to GitHub: git push -u origin feature-x.

5. Merging Feature Branches

Once a feature is complete and tested, it can be merged into the main branch. This is usually done after a code review process.

git switch main
git merge feature-x

6. Introducing Pull Requests

Pull requests (PRs) on GitHub are a way to propose changes from one branch to another (usually from a feature branch to main). PRs facilitate code review, discussion, and additional changes before the code is merged.

7. Making Our First Pull Request

1. Push your feature branch to GitHub.
2. On GitHub, navigate to your repository and click “Pull requests” > “New pull request.”
3. Select your feature branch and the base branch (usually main).
4. Fill in the details and create the pull request.

8. Merging Pull Requests With Conflicts

If your PR has conflicts with the base branch, GitHub will alert you. Resolve these conflicts by checking out the feature branch, merging the base branch into it, resolving the conflicts locally, committing the changes, and pushing. Then, you can merge the PR on GitHub.

9. Configuring Branch Protection Rules

To ensure the integrity of your main branch, configure branch protection rules:

1. In your repository settings on GitHub, go to “Branches.”
2. Add a branch protection rule for main, specifying requirements like PR reviews before merging.

10. Introducing Forking

Forking is creating a personal copy of someone else’s repository, allowing you to make changes without affecting the original. It’s commonly used for contributing to open-source projects.

11. Forking Demonstration

1. On GitHub, navigate to a repository you want to contribute to.
2. Click the “Fork” button to create a copy under your GitHub account.
3. Clone your fork, make changes, and push them.

12. The Fork & Clone Workflow

After forking a repository, clone it to your local machine, create a new branch for your changes, and then push the branch back to your fork. You can then create a pull request to the original repository.

13. Fork & Clone Workflow Demonstration

1. Clone your fork: git clone <your-fork-url>.
2. Create a new branch: git switch -c improvement-x.
3. Make changes, commit, and push them to your fork.
4. Create a pull request from your fork to the original repository on GitHub.

Through exploring these workflows, “SampleProject” demonstrates the flexibility of Git and GitHub for solo and collaborative development, highlighting practices that maintain code quality and ease contribution processes.

Let’s delve into the topic of rebasing with our “SampleProject,” exploring why some might find it intimidating and how it compares with merging. Rebasing is a powerful Git feature that can streamline your project’s history but requires careful use to avoid complications.

Rebasing: The Scariest Git Command?

1. Why is Rebasing Scary? Is it?

Rebasing is often considered “scary” because it can rewrite the commit history of your branch. This can be dangerous if not used correctly, especially in shared branches, as it can lead to lost commits or complicated conflicts. However, when used judiciously in local branches before they’re shared, rebasing is a valuable tool for creating a clean, linear history.

2. Comparing Merging & Rebasing

• Merging takes the contents of a source branch and integrates them with a target branch. This action typically results in a new “merge commit” that ties together the histories of both branches, preserving the context of parallel development.
• Rebasing takes the commits from one branch and replays them on the tip of another branch. Unlike merging, rebasing creates a linear progression of commits, which can simplify project history but also change commit hashes, which is why it’s not recommended for public or shared branches.

3. Rebase Demo Pt 1: Setup & Merging

Suppose we have two branches: main and feature-x. To demonstrate merging:

1. Make sure main has some commits that feature-x does not.
2. Switch to feature-x: git switch feature-x.
3. Merge main into feature-x: git merge main.
   This merge brings the branches together, preserving their parallel development history.

4. Rebasing Demo Pt 2: Actually Rebasing

Continuing with our example, to rebase feature-x onto main:

1. Ensure feature-x is checked out: git switch feature-x.
2. Run the rebase command: git rebase main.
   This moves all changes made in feature-x so that they appear to be made on top of the head of main, creating a cleaner, linear history.

5. The Golden Rule: When NOT to Rebase

Never rebase commits that have been pushed to a public repository. Rebasing rewrites commit history, and if commits have already been shared, rebasing them can cause confusion and conflicts for other collaborators. Always rebase before pushing your changes.

6. Handling Conflicts & Rebasing

If you encounter conflicts during a rebase:

1. Resolve the conflicts manually in the affected files.
2. After fixing conflicts, stage the changes: git add .
3. Continue the rebase: git rebase --continue.
   Repeat these steps until all conflicts are resolved and the rebase completes.

Exercise with “SampleProject”

To practice, create a new branch experiment from main, make some commits, then go back to main and make other commits. Now, rebase experiment onto the updated main:

1. git switch experiment
2. git rebase main

Through careful execution, this exercise demonstrates the utility of rebasing for achieving a clean, understandable project history. Remember, rebasing is a powerful tool in your Git arsenal when used appropriately, aiding in maintaining a clean commit history and simplifying code integration.