Git workflows

Common Git Workflows

Centralized Workflow

Overview: The Centralized Workflow is similar to the traditional version control system workflow. It revolves around a single central repository where all changes are committed and shared.

Key Features:

• Single Central Repository: All team members work from the same repository.
• Direct Commits: Changes are directly committed to the main branch (often main or master).

Steps:

1. Clone the Central Repository:

   git clone https://example.com/central-repo.git

2. Make Changes:

   # Modify files in your local working directory

3. Add and Commit Changes:

   git add changed-file.txt
   git commit -m "Describe your changes"

4. Push Changes:

   git push origin main

Pros:

• Simple to understand and use.
• Easy to set up and manage.

Cons:

• Limited flexibility for managing features or multiple parallel developments.
• Risk of conflicts due to direct commits to the main branch.

Feature Branch Workflow

Overview: The Feature Branch Workflow is designed to help manage and develop features independently. Each new feature or bug fix is developed in its own branch.

Key Features:

• Separate Branches: Each feature or bug fix is developed in its own branch.
• Merging: Features are merged back into the main branch after they are complete and tested.

Steps:

1. Create a New Branch for a Feature:

   git checkout -b feature/new-feature

2. Make Changes:

   # Modify files for the new feature

3. Add and Commit Changes:

   git add changed-file.txt
   git commit -m "Add new feature"

4. Push the Feature Branch:

   git push origin feature/new-feature

5. Merge Feature Branch into Main:

   git checkout main
   git merge feature/new-feature

Pros:

• Isolates development of features, reducing the risk of conflicts.
• Allows for easier testing and review of individual features.

Cons:

• Requires more branches and merging, which can complicate the repository history.

Gitflow Workflow

Overview: Gitflow Workflow is a set of conventions for managing branches in Git. It provides a structured approach to feature development, releases, and hotfixes.

Key Features:

• Branch Types:
  • main: Production-ready code.
  • develop: Integration branch for features.
  • feature: Branches for developing new features.
  • release: Branches for preparing releases.
  • hotfix: Branches for urgent fixes.

Steps:

1. Create a Feature Branch:

   git checkout -b feature/my-feature develop

2. Complete Feature and Merge:

   git checkout develop
   git merge feature/my-feature

3. Create a Release Branch:

   git checkout -b release/1.0.0 develop

4. Finalize Release:

   git checkout main
   git merge release/1.0.0
   git tag -a 1.0.0 -m "Release version 1.0.0"

5. Create a Hotfix Branch:

   git checkout -b hotfix/fix-issue main

6. Merge Hotfix:

   git checkout main
   git merge hotfix/fix-issue
   git checkout develop
   git merge hotfix/fix-issue

Pros:

• Provides a clear structure for managing different types of branches.
• Facilitates release management and hotfixes.

Cons:

• Can be complex and require discipline to follow.
• May be overkill for simpler projects.

Forking Workflow

Overview: The Forking Workflow is used primarily in open-source projects. It involves creating a personal copy (fork) of a repository, making changes, and then proposing those changes to the original repository via pull requests.

Key Features:

• Forking: Create a personal copy of a repository.
• Pull Requests: Propose changes from your fork to the original repository.

Steps:

1. Fork the Repository:

   • Use the “Fork” button on GitHub or similar platforms.

2. Clone Your Fork:

   git clone https://github.com/your-username/forked-repo.git

3. Create a Feature Branch:

   git checkout -b feature/my-feature

4. Make and Commit Changes:

   git add changed-file.txt
   git commit -m "Add new feature"

5. Push Changes to Your Fork:

   git push origin feature/my-feature

6. Create a Pull Request:

   • Go to the original repository and open a pull request from your feature branch.

Pros:

• Ideal for contributing to open-source projects.
• Allows independent development without affecting the main repository.

Cons:

• More steps are required to propose changes.
• Requires managing multiple repositories.

Best Practices

Writing Good Commit Messages

Purpose: Good commit messages provide clarity on what changes were made and why. They help collaborators understand the history and rationale behind changes.

Best Practices:

1. Use the Imperative Mood:

   • Write messages as if you are giving a command.
   • Example: “Fix bug in authentication” instead of “Fixed bug in authentication.”

2. Be Concise but Descriptive:

   • Provide enough detail to understand the purpose of the commit.
   • Example: “Add validation to user registration form” instead of “Update form.”

3. Include a Summary and Description:

   • Use the first line as a summary (ideally 50 characters or less).
   • Provide additional details in the following lines if needed (wrap at 72 characters).

Example:

Fix typo in README

Corrects a misspelling of 'installation' in the installation instructions section.

Using .gitignore Files

Purpose: .gitignore files specify which files or directories should be ignored by Git. This helps prevent committing unnecessary files, such as build artifacts or sensitive information.

Steps:

1. Create or Edit .gitignore:
   • Add patterns for files and directories to be ignored.

Example .gitignore:

# Ignore build artifacts
/build/
/dist/

# Ignore log files
*.log

# Ignore sensitive files
config/secrets.yml

2. Apply Changes:
   • Git will automatically ignore files matching the patterns specified in .gitignore.

Note: If a file was already committed before adding it to .gitignore, you need to remove it from the repository.

Example:

# Remove a file from the repository but keep it locally
git rm --cached filename

Keeping a Clean History with Rebase and Squash

Purpose: Rebasing and squashing commits help maintain a clean and understandable project history.

Rebasing:

• Rebase: Reapply commits from a branch onto a new base, which can simplify history.
• Usage:

  git rebase main

Squashing Commits:

• Squash: Combine multiple commits into a single commit to reduce clutter.
• Interactive Rebase:

  git rebase -i HEAD~n

  • Replace pick with squash for the commits you want to combine.

Example:

pick 1234567 Commit A
squash 89abcd Commit B

Result:

• Commits A and B are combined into a single commit.

Benefits:

• Rebase: Creates a linear history by avoiding merge commits.
• Squash: Reduces the number of commits, making the history cleaner and easier to follow.

By following these best practices, you can maintain a more manageable and understandable repository, making it easier for you and your team to collaborate effectively.