Part 6: Understanding Git Workflows

Introduction

Git workflows provide structured approaches to using Git in a collaborative development environment. They define how teams use branches, integrate changes, and release code. Choosing the right workflow helps maintain code quality, streamline collaboration, and simplify the development process.

1. Gitflow Workflow

Gitflow is a popular workflow for projects that follow a strict release schedule. It was introduced by Vincent Driessen and is ideal for projects with versioned releases.

Branch Structure

• main: The stable branch containing production-ready code.
• develop: The active development branch where features are merged.
• Feature branches: Created from develop and used to work on new features.
• Release branches: Created from develop to prepare for a release.
• Hotfix branches: Created from main to fix urgent issues and merged back into main and develop.

Workflow Steps

1. Create a feature branch:

$ git checkout -b feature/new-feature develop

2. Merge the feature branch into develop when complete:

$ git checkout develop
$ git merge feature/new-feature

3. Create a release branch when ready for release:

$ git checkout -b release/1.0.0 develop

4. Merge the release branch into main and tag it:

$ git checkout main
$ git merge release/1.0.0
$ git tag -a v1.0.0 -m "Release version 1.0.0"

5. Handle hotfixes as needed:

$ git checkout -b hotfix/urgent-fix main

2. GitHub Flow

GitHub Flow is a simpler, more flexible workflow that is well-suited for continuous integration and deployment (CI/CD). It focuses on short-lived feature branches and a fast release cycle.

Key Principles

• main branch is always deployable.
• Feature branches are created for each task or bug fix.
• Pull requests are used for code review and merging.

Workflow Steps

1. Create a feature branch:

$ git checkout -b feature/improve-UI

2. Push the branch to GitHub and open a pull request:

$ git push origin feature/improve-UI

3. Collaborate on the pull request, make changes, and request reviews.
4. Merge the branch into main after approval.

$ git checkout main
$ git merge feature/improve-UI

5. Deploy directly from main as it is always in a deployable state.

3. Forking Workflow

The Forking Workflow is commonly used in open-source projects. Contributors fork the main repository, make changes in their own copy, and submit pull requests.

Workflow Steps

1. Fork the repository on GitHub.
2. Clone the forked repository:

$ git clone https://github.com/yourusername/repository-name.git

3. Create a branch and make changes:

$ git checkout -b feature/community-contribution

4. Push changes to your fork:

$ git push origin feature/community-contribution

5. Submit a pull request to the original repository.

Choosing the Right Workflow

• Gitflow is ideal for projects with defined release cycles and a need for extensive testing.
• GitHub Flow is better suited for teams practicing continuous integration and delivery.
• Forking Workflow is best for open-source projects and scenarios where external contributions are encouraged.

Practical Example: GitHub Flow in Action

1. Create a branch for a new feature:

$ git checkout -b feature/add-dark-mode

2. Work on the feature, commit changes, and push:

$ git add .
$ git commit -m "Add dark mode support"
$ git push origin feature/add-dark-mode

3. Open a pull request on GitHub and collaborate.
4. Merge after approval:

$ git checkout main
$ git merge feature/add-dark-mode

5. Deploy from main.

Recap

• Gitflow supports projects with defined release schedules.
• GitHub Flow is simple and supports CI/CD practices.
• Forking Workflow encourages external contributions.
• Choose the workflow that best suits your team’s needs and development style.

Next Steps

In the next part, we’ll look into Handling Large Repositories and Submodules, where we explore how to manage complex projects efficiently.

Stay tuned for Part 7: "Handling Large Repositories and Submodules."