How to use Git and GitHub while working with teams

ยท

5 min read

How to use Git and GitHub while working with teams

Introduction

Git is a fundamental tool in modern software development, and understanding how to effectively use it in a team is crucial.

Many teams face challenges related to branch management, handling conflicts, and coordinating work among team members. Addressing these challenges can improve productivity and collaboration.

Branching structure

While working with multiple team members on one project, having a consistent branching structure is essential for smooth collaboration among team members.

Let's take an example of a typical branching structure commonly used in team projects:

  • Master/Main Branch:- The master branch is the initial branch from which the project is started. It contains the stable and production-ready codebase that is deployed to the live environment. The code is merged to this branch only after it's tested and ready for deployment.

  • Staging Branch:- The staging branch is created from the master branch. It should always be a copy of the master branch at any given time. Prior to merging changes into the master branch, they are first merged into the staging branch to ensure compatibility and functionality across different environments.

  • Development Branch (Dev):- The dev branch is also created from the master branch. During the development phase, feature branches and bug fix branches are merged into the dev branch for testing and validation. And once changes are approved on dev, they are deployed to the higher environments.

Working on a Feature/Bugfix

Before working on a new feature or fixing a bug it's essential to establish a structured workflow for creating and managing feature and bugfix branches.

Here are some examples of branch names for new Features or Bugfixes.

  • feature-id-short-description

  • issue-id-short-description

  • hotfix-id-short-description

The id could be the GitHub issue number or task ID if you are using any project management system.

Here's a step-by-step guide to get started:

  1. Branch Creation:

    • Begin by switching to the master/main branch to ensure you're working with the latest codebase:

        // Checkout to master/main branch
        git checkout master
      
    • Pull the latest changes from the remote repository to sync your local branch with the upstream:

        // Pull the latest code
        git pull
      
    • Create a new branch for your feature or bugfix, following a standardized naming convention:

        // Create a new feature/bugfix branch
        git checkout -b feature-1-social-auth-google
      
  2. Development Workflow:

    • Proceed with implementing your feature or bugfix, making changes as necessary:

        // After completing work, commit your changes
        git add .
        git commit -m "commit message"
      
    • Use clear and descriptive commit messages to provide context about the changes made.

  3. Branch Pushing:

    • Once your changes are ready, push your feature or bugfix branch to the remote repository:

        // Push your feature branch
        git push origin feature-1-social-auth-google
      
  4. Pull Request Creation:

    • Navigate to the GitHub repository and create a pull request (PR) from your feature branch to the target branch where you intend to merge your changes.

Fixing code conflicts

Code conflicts usually occur when two developers make changes to the same lines in a file. In these cases, GitHub cannot automatically merge the code and we have to fix these conflicts manually.

Never merge the target branch directly to your main task branch while fixing the code conflicts!
Suppose you faced a code conflict while merging your branch to dev. So, If you face conflicts while merging with dev branch then don't merge dev branch directly to your main task branch while fixing the conflicts. What will happen in this case is that the dev branch contains the work of other developers as well which is in the development phase and not ready for production yet. So, if you merge dev branch directly to your task branch then you will get those un-tested changes as well and then you won't be able to further merge your branch to the higher environments.

Here's a step-by-step guide to resolving code conflicts while maintaining the integrity of your task branch:

  1. Create a Conflict Resolver Branch:

    • Switch to the target environment branch (e.g., "dev") to fetch the latest code:

        // Checkout to the target environment branch
        git checkout dev
        // Pull the latest code
        git pull origin dev
      
    • Return to your task branch and create a new conflict resolver branch from it:

        // Checkout to your task branch
        git checkout feature-1-social-auth-google
        // Create a conflict resolver branch
        git checkout -b feature-1-social-auth-google-dev-conflict-resolver
      
  2. Resolve the Conflicts:

    • Merge the target environment branch (e.g., "dev") into your conflict resolver branch to trigger conflict resolution:

        // Merge dev branch into your conflict resolver branch
        git merge dev
      
    • Manually resolve the conflicts that arise, ensuring that the resulting code reflects the desired changes and maintains functionality:

        // Fix conflicts manually
        // Commit your changes after resolving conflicts
      
  3. Push the Conflict Resolver Branch:

    • Once conflicts are resolved, push the conflict resolver branch to the remote repository:

        // Push your conflict resolver branch
        git push origin feature-1-social-auth-google-dev-conflict-resolver
      
  4. Create a Pull Request:

    • Create a new pull request (PR) with the target environment branch (e.g., "dev") using your conflict resolver branch.

    • Test your code on the target environment to ensure that the conflicts are resolved and that the changes are working as expected.

Integration with Higher-Level Branches

Once your code changes have been thoroughly tested on the development (dev) environment and verified to meet requirements, the next step is to move them to staging and master branches. Here's how to proceed:

  1. Pull Requests for Staging and Master:

    • Create pull requests (PRs) for staging and master branches using your base task branch once testing on the dev environment is complete.
  2. Resolving Conflicts with Master or Staging:

    • In case of conflicts with the master or staging branches, follow the same conflict resolution approach used earlier.

    • Create a new conflict resolver branch from your task branch and merge the master or staging branch into it to resolve conflicts manually.

Conclusion:

Learning how to use Git and GitHub well is really important for working together on software projects. By using clear rules for creating and managing branches, and by fixing conflicts when they happen, teams can keep their code organized and working smoothly. Testing changes thoroughly before merging them into important branches like staging and master ensures that the final product works well.

If you have any questions, feel free to ask in the comments or reach out to me. I'm here to help!

Till then happy coding and have a great time ahead ๐Ÿ˜‡๏ธ.

ย