Git Workflow for Working in Teams

So, you're a self-taught web developer who has mostly worked alone.

Up until now, you've used Git primarily to push code to a server through deployment services, and that's about it. Looking back, you realize most of your commit messages have been vague and unhelpful.

But things are changing. Whether you're landing more freelance projects or joining a company, you'll likely be working in a team—and that means adapting your workflow to collaborate effectively.

At this point, you're feeling lost about where to start. You already know the basic concepts of Git, understand why people use it, and see how it could be beneficial. Yet, it feels like you're missing the foundation to truly build upon.

You've tried learning Git through courses and tutorials, but they only cover what you already know. It feels like you "know everything and nothing" at the same time.

To help bridge that gap, I've written this article to guide you through using Git effectively in a team setting. It's laid out in a sequential manner, covering the steps you'll need most of the time.

Having this guide handy will give you a solid foundation and set you apart from others who are just starting out.

So lets get started!

Step 1: Cloning the Source Code

When you join a team, the source code for the project typically already exists. Even if you're the one setting up the repository, you'll still need to clone it to your local machine to start working on it.

The first step is to use the git clone command. This will create a local copy of the repository on your machine, allowing you to make and manage changes locally. Cloning a repository downloads a full copy of all the repository data from the remote server, including every version of every file and folder in the project.

• On GitHub, navigate to the main page of the repository.

• Above the list of files, click Code.

  

• Copy the URL of the repository.

  

• Open your terminal or command prompt, type git clone, and paste the URL you copied.

  git clone https://github.com/github/docs.git
  

• Press Enter to create your local clone.

  $ git clone https://github.com/github/docs.git
  > Cloning into `Spoon-Knife`...
  > remote: Counting objects: 10, done.
  > remote: Compressing objects: 100% (8/8), done.
  > remote: Total 10 (delta 1), reused 10 (delta 1)
  > Unpacking objects: 100% (10/10), done.
  

This will download the repository and all its history to your local machine.

If you already have the source code on your machine, you can skip this step and move directly to Step 2.

Step 2: Staying Updated with Team Changes

When working in a team, your teammates are constantly pushing their code to the remote repository.

Before you start working on a feature or bug fix, it’s crucial to get the latest changes from the remote. This ensures you're working with the most up-to-date code and reduces the risk of working on outdated code. It also helps minimize merge conflicts when you later integrate your changes back into the main codebase.

Since you're just starting to work, a simple git pull is often sufficient. This command brings the latest changes from the remote repository into your local branch. Think of it as syncing your local code with the most recent version of the project.

• First, ensure you're on the branch you plan to branch off from (usually main or master):

  git checkout main
  

• Pull the latest changes from the remote repository:

  git pull
  

Once you've pulled the latest updates, you're ready to create a new branch for your feature or bug fix, which we'll cover in Step 3.

Step 3: Creating a Branch for Your Work

Most companies won’t allow you to push code directly to the main branch. Even if you have permission, it’s not recommended.

The goal is for the main branch to always be fully tested and stable. Working on your own branch ensures your changes don’t disrupt the main branch while you're still working on them.

This also allows for code review before merging into the main branch, ensuring nothing breaks in production.

There are two common ways to create and switch to a new branch in Git.

1. Create a Branch First, Then Switch to It

You can create a branch and then switch to it in two separate steps:

git branch <branch-name>
git checkout <branch-name>

git branch <branch-name> creates a new branch with the specified name. git checkout <branch-name> switches to that branch.

This method is helpful if you want to create a branch first and decide later when you want to start working on it.

2. Create and Switch to a Branch in One Step

Alternatively, you can combine both actions into one command using the -b flag:

git checkout -b <branch-name>

This creates and immediately switches to the new branch, saving you from having to run two separate commands.

This approach is commonly used when you're ready to start working on a new branch right away.

Step 4: Making Changes and Reviewing Them

After working on your feature or bug, you’ll have some files that have been edited. To review the changes, you can use the git status command.

The git status command provides a summary of the changes in your working directory. It shows:

• Staged changes: Files that have been added to the staging area (ready to be committed).

• Unstaged changes: Files that have been modified but not yet added to the staging area.

• Untracked files: New files in your working directory that Git isn’t tracking yet.

It’s a good habit to run git status regularly while working to stay aware of the state of your changes.

Step 5: Committing Your Work

Once you’ve made changes, the next step is to commit them. A commit is a snapshot of your changes, and it starts with adding the modified files to the "staging area." The staging area is where Git prepares your changes before saving them in a commit.

You can add specific files or all the changed files to the staging area using the following commands:

• Add a specific file:

  git add <file-name>
  

• Add all changed files:

  git add .
  

After staging your files, you need to commit them with a meaningful message describing the changes.

git commit -m "Fix: Resolved login bug causing crash on invalid input"

Tips for Writing Clear Commit Messages

Clear, descriptive commit messages help you and your team understand the purpose of each change. Follow a simple format like this:

• Feature: For adding a new feature. Example: Feature: Add user profile page with edit functionality

• Fix: For fixing bugs or issues. Example: Fix: Resolve crash on login page for invalid input

• Docs: For documentation updates. Example: Docs: Update README with API usage instructions

Using meaningful commit messages makes it easier to track changes and understand the project history.

Step 6: Syncing Your Work with the Team

Once you’ve committed your changes locally, the next step is to share them with your team by pushing them to the remote repository. This ensures that your work is visible to others and can be reviewed or integrated into the main codebase.

git push origin <branch-name>

Replace <branch-name> with the name of your current branch. This command uploads your changes to the corresponding branch in the remote repository.

Step 7: Creating a Pull Request

After completing your work, the next step is to merge your changes back into the main branch. This is typically done by creating a Pull Request (PR), which acts as a formal request to merge your branch into another branch (usually the main or master branch).

You might wonder: Why create a Pull Request? Why not directly merge into the main branch?
A Pull Request is important because:

• It allows your team to review your code for potential bugs, style issues, or improvements before merging.

• It provides a space for teammates to discuss changes, leave comments, and suggest improvements.

• It ensures that changes are introduced systematically and that the main branch remains stable.

The exact steps to create a PR vary depending on the Git hosting platform you're using (e.g., GitHub, GitLab, Bitbucket). Most platforms offer an intuitive web interface for creating PRs:

• Navigate to your repository on the hosting platform.

• Switch to the branch containing your changes.

• Click on the "New Pull Request" or "Compare and Pull Request" button.

• Add a clear title and description explaining what changes were made and why.

• Submit the PR for review.

Once submitted, your teammates can review the code. After approval, the changes can be merged into the target branch, ensuring a smooth workflow.

Step 8: Addressing Feedback

Once you raise a Pull Request (PR), your teammates might request changes or suggest improvements. To address their feedback, you'll need to make the necessary updates to your code. The process is similar to the steps you followed when you first started working:

• Make the required changes based on the feedback.
• Add the updated files to the staging area:

  git add <file-name>
  

• Commit the changes with a clear message:

  git commit -m "Fix: Addressed feedback on PR #123"
  

• Push the changes to the remote repository:

  git push origin <branch-name>
  

Any changes you push will automatically update the existing PR. This allows your teammates to review the updated code and proceed with approval if everything looks good.

Step 9: Syncing with the Main Branch

Once your Pull Request (PR) is approved, the final step is to merge your branch into the main branch. However, sometimes merge conflicts can occur during this process.

A merge conflict happens when Git cannot automatically combine your changes with the updates in the main branch. This usually occurs if the same lines in a file were modified in both your branch and the main branch.

For example:

• Your teammate modified index.js in the main branch.

• You also made changes to index.js in your branch.

Git needs you to decide which changes to keep or combine.

Steps to Resolve Merge Conflicts

• Pull the Latest Changes from the Main Branch

  git pull origin main
  

• Git will notify you about the files with conflicts. Open these files, and you’ll see markers like:

  <<<<<<< HEAD
  Your changes
  =======
  Changes from the main branch
  >>>>>>> main
  

• Decide what to keep or combine from both sets of changes. Edit the file to remove the conflict markers (<<<<<<<, =======, >>>>>>>).

• Once the conflicts are resolved, stage the files:

  git add <file-name>
  

• Commit the resolution:

  git commit -m "Fix: Resolved merge conflicts with main branch"
  

• Push the resolved branch back to the remote repository:

  git push origin <branch-name>
  

Step 10: Merging the Branch

Once your Pull Request (PR) is approved and there are no merge conflicts, you're ready to merge your branch into the main branch.

• Switch to the main branch:

  git checkout main
  

• Pull the latest changes from the remote main branch to ensure it's up-to-date:

  git pull origin main
  

• Merge your branch into the main branch:

  git merge <branch-name>
  

• Push the updated main branch to the remote repository:

  git push origin main
  

Step 11: Cleaning Up Branches

After the merge, you can delete your branch locally and remotely to keep your workspace clean.

git branch -d <branch-name>            # Delete the local branch
git push origin --delete <branch-name> # Delete the remote branch

By cleaning up, you avoid clutter in the repository and keep the branch structure organized. ```

This workflow will cover 90% of the situations you encounter while using Git in a team setting. For anything beyond this, you can always look it up online or consult your teammates for guidance.

Hope you find this helpful!