Common Mistakes and Pitfalls When Using Git

Let's dive into some common mistakes and pitfalls when using Git and how to address them.

Incorrect Branching Strategies

One of the most common mistakes in Git is choosing the wrong branching strategy, which can lead to conflicts and confusion. The two most common branching strategies are the "Feature Branch Workflow" and the "Gitflow Workflow."

Feature Branch Workflow

This strategy involves creating a new branch for each new feature or bug fix. Developers work on their changes within the feature branch, and once the feature is complete, it gets merged back into the main branch.

Let's demonstrate this workflow with an example:

Create a new feature branch

git checkout -b feature/new-feature

Make some changes and commit them

echo "This is a new feature." >> feature.txt
git add feature.txt
git commit -m "Add new feature"

Merge the feature branch back into the main branch

git checkout main
git merge feature/new-feature

Delete the feature branch (optional)

git branch -d feature/new-feature

Gitflow Workflow

Gitflow is a more complex branching strategy, which introduces additional branches for features, releases, and hotfixes. It aims to provide a more structured development process.

Here's a basic overview of Gitflow:

• main: Represents the stable production code.

• develop: Serves as an integration branch for ongoing development.

• feature/: Branches for new features.

• release/: Branches for preparing releases.

• hotfix/: Branches for critical bug fixes in production.

Gitflow example:

Create a new feature branch

git checkout -b feature/new-feature develop

Work on the feature branch, commit changes

Merge the feature branch into the develop branch

git checkout develop
git merge feature/new-feature

Create a release branch

git checkout -b release/1.0.0 develop

Test and finalise the release branch

git checkout main
git merge release/1.0.0
git tag 1.0.0

Merge the changes back into develop

git checkout develop
git merge release/1.0.0

Delete the release branch

git branch -d release/1.0.0

Choosing the right branching strategy depends on your project's needs. Both strategies have pros and cons, so it's essential to consider your team's workflows and preferences.

---

Force Pushing

Force pushing (using git push --force or git push -f) is a dangerous action that rewrites the Git history by overwriting remote branches.

It should be used with caution and only in specific cases, as it can lead to data loss and conflicts for other collaborators.

A common scenario where force pushing is tempting is when you need to amend a commit or fix a mistake after pushing to a remote branch.

• How to avoid it: Instead of force pushing, use git push --force-with-lease or git push -f --no-verify. These commands will only force push if the remote branch has not changed since you last pulled.

Before force pushing, check the remote status

git fetch origin

Force push with lease

git push --force-with-lease

---

Improper Merging

Incorrect merging can introduce conflicts and produce unexpected results in your Git history. It's essential to follow best practices for merging branches.

• Merge Conflicts: Merge conflicts occur when Git cannot automatically merge changes from different branches. These conflicts require manual resolution.

To resolve merge conflicts, follow these steps:

Fetch the latest changes from the remote repository

git fetch origin

Switch to the branch you want to merge into

git checkout main

Merge the branch you want to merge from

git merge feature/my-feature

Resolve the merge conflicts using a text editor

Add the resolved files

git add .

Commit the changes

git commit -m "Merge branch feature/my-feature"

Push the changes to the remote repository

git push origin main

• Rebase vs. Merge: Another common mistake is not understanding when to use git merge or git rebase. The choice between the two depends on your desired Git history and collaboration workflow.

  • git merge: Incorporates changes from a source branch into a target branch as a new commit. It preserves the original branch's commit history.

  • git rebase: Transfers the commits from a source branch to the tip of a target branch, creating a linear commit history. It can make the commit history cleaner but should be used cautiously, especially when working with shared branches.

Ensure to choose the appropriate strategy based on your project's needs and collaboration requirements.