GitHub Operations

This section covers common operations and workflows on GitHub, focusing on branching, pull requests, and tagging for releases.

Branching Strategy

A consistent branching strategy is essential for managing development and releases. The GitFlow model is a popular choice, but a simpler model can be effective for many projects.

  • main branch: This branch should always be stable and deployable. Direct commits to main are typically disallowed.
  • Feature branches: All new development, whether for features or bugfixes, should happen in feature branches. These are created from main.
    • Example: feature/add-user-authentication, bugfix/fix-login-button
  • Release branches: When preparing for a release, a release branch can be created from main. This allows for final testing and bugfixes before tagging.
    • Example: release/v1.2.0

Pull Requests (PRs)

Pull Requests are the standard way to merge code from a feature branch into main.

  1. Create a PR: When a feature is complete, open a PR from your feature branch to main.
  2. Code Review: Team members review the code, provide feedback, and suggest changes.
  3. Automated Checks: CI/CD pipelines run automated tests, linting, and other checks.
  4. Merge: Once approved and all checks pass, the PR is merged into main.

Tagging and Releases

Git tags are used to mark specific points in history as important, such as a release. GitHub Releases are a way to package and distribute software based on Git tags.

Creating a Tag

Create an annotated tag for each release.

git tag -a v1.2.0 -m "Release version 1.2.0"

Pushing a Tag

Push the tag to the remote repository.

git push origin v1.2.0

Creating a GitHub Release

  1. Go to the “Releases” page in your GitHub repository.
  2. Click “Draft a new release.”
  3. Choose the tag you just pushed.
  4. Add a title and description for the release (e.g., release notes).
  5. You can also attach binary files (e.g., compiled executables, archives).
  6. Publish the release.

Git Stash

git stash temporarily shelves changes you’ve made to your working copy so you can work on something else, and then come back and reapply them later.

Basic Stash Commands

  • git stash: Stashes your current changes (staged and unstaged).
  • git stash save "message": Stashes your current changes with a descriptive message.
  • git stash list: Shows all stashes.
  • git stash apply: Applies the most recent stash without removing it from the stash list.
  • git stash apply stash@{2}: Applies a specific stash from the list (e.g., the third one).
  • git stash pop: Applies the most recent stash and removes it from the stash list.
  • git stash drop: Deletes the most recent stash from the stash list.
  • git stash drop stash@{1}: Deletes a specific stash from the stash list.
  • git stash clear: Deletes all stashes from the stash list.
  • git stash branch <new_branch_name>: Creates a new branch from the commit where the stash was originally created, applies the stash to it, and then drops the stash.

Use Cases

  • Switching branches quickly: You’re in the middle of a feature, but need to quickly switch to another branch to fix a bug. Stash your changes, switch, fix, switch back, and apply your stash.
  • Cleaning your working directory: Before pulling new changes, you might want to stash your local modifications to avoid conflicts or just to have a clean merge.

For a comprehensive guide on Lazygit shortcuts and usage, refer to the Lazygit Shortcuts article.

graph TD
    A[main] --> B(feature/new-feature);
    B --> C{Pull Request};
    C -->|Review & Merge| A;
    A --> D(release/v1.2.0);
    D -->|Tag v1.2.0| A;
    subgraph "GitHub"
        C;
    end