Git workflow

Today, it becomes more and more important to have clean and easy processes for your software applications developments.

Wether you are working for a big company or for a small startup, you may have to use a code versioning tool.

Git a very powerful tool for such purpose. It enables developers to collaborate seamlessly while building a coding project.

To benefit from the power of Git, you must first understand its inner working and get to know how to use well as a team. In this article, we will talk about the second aspect which is how to properly use Git.

Let’s start from the begining. During a Software development, a workflow or process must be set up. Many teams use what we call Git workflow.

Git Workflow will allow us to organize our software development in order to achieve:

  • Efficiency
  • Better collaboration
  • Reports and insights

Check this interactive tool to play with Git commands .

Now you are ready to read an apply our article on Git Workflow, or use Gitlab with Git.

🌿 How to manage Git Branches

Protected Branches (Production)

🌿 Main: Branch having the production code.
🌿 Release_x_x: Stable versions with associated fixes. You can check our article on using Standard-Version for applications versioning.

Development Branches

🌱 Feat: Branch for developing new features.
🌱 Fix: Branch for quick bug fixes, focused on a specific bug.
🌱 Exp: Experimental used to save work on experimental features.
📢 1 task = 1 feature = 1 branch

Exception: Small refactoring changes that don’t require a task. If you spend more than half a day on the matter, create a task for better tracking. These branches should start with fix- and no task ID.

How to Name Your Development Branch

  • Branch names are in kebab-case.
  • Add the type of branch (feat, fix, exp).
  • Finally, add a precise and informative name.
  • Branch name example:
    Let us say you have a task management tool that provides you the id of the task. Your branch must be named as follow: <-task-id>-<branch-type>-<branch-name> i.e, 427-feat-hello-world

🧑‍💻 Example of How to use Git Workflow?

:dash: New Feature Workflow

  • Start a development:
    • Chek the sprint you are working on.
    • Look for a new task in the planning roadmap.
    • If you have already assigned tasks, check one from them.
    • In most cases, your project maanger mus have alread set the status of the tasks to work on to ready.
    • Pull the latest version of the main branch on the relevant repositories:
    • git checkout main
    • git pull
    • Create a branch for the feature from main branch:
    • Name the branch according to the naming guidelines presented above.
    • git checkout -b <task-id>-<branch-type>-<branch-name>
    • code
    • add unit tests.

Daily Git Workflow

  • Commit changes on a daily basis
    • Use git status to check staged, and untracked files
    • Add not staged or untracked files to staged using git add .
    • Personaly, I prefer to use git add filename to be sure of which file I’m adding.
    • You can gnore parasite files by adding them to .gitignore
    • Commit staged files with a conventional commit message format
    • Test locally and push code changes to the remote repository using git push at least every 3 days.

Weekly Git Workflow

  • Perform a rebase:
    • git fetch --all
    • git rebase origin/main
    • git push -f

Merge Request Git Workflow

  • Rebase to have a clean history and an up-to-date branch. See the last section
  • Rebase code on top of origin/main
  • you can squash commits into a single one
  • you can use git rebase -i origin/main for interactive mode
  • Check all tests locally
  • Push force on the remote repository using git push -f

Creating Merge Request in Gitlab

I have been using Gitlab and I liked it, so I will be talking about it.

  1. Create a merge request to main in Gitlab
  2. I Recommend you to setup a template, so that each developer could elect the appropriate Merge Request template when creating a merge request?
  3. If applicable, complete the “Merge request author checklist” to ensure all necessary tasks are finished
  4. Assign a reviewer to the merge request

ℹ️ The merge request should be reviewed and approved by at least one person. It serves as an opportunity to review the code for compliance with company standards, meeting project requirements, and improving coding skills through technical discussions.

  1. Click “Create merge request” to update the task status automatically

To learn more about performing or requesting a code review, refer to the documentation.

Merging and Finalizing the Task

  1. Once the reviewers approve the merge request on Gitlab and all pipelines are successful, it is the developer’s responsibility to merge the branch into main
  2. Select the option to “Delete source branch” to remove the branch from the remote repository after merging
  3. After completing the merge, the task status is automatically updated to “Validation”

Validation

  1. When preparing for a new release version, merge main into the release branch using Fast Forward merge
  2. Perform functional testing on the project to validate both new and existing feature behaviors
  3. Close tasks and set them to the “Complete” status

Work on your code every day

  1. On a daily basis, commit changes
    1. Check staged, not staged and untracked files:
      git status
    2. Add not staged or untrack files to staged
      git add path_to_file_to_add
      ⚠️ you must commit only related work, parasite files should be added to .gitignore
    3. Commit your staged files with a conventional commit message format
    4. At least every other day, test (unit tests) locally and push your code to save changes in remote repo git push
  2. On a weekly basis,
    1. rebase your code on top of origin/main to resolve all possible conflict incoming.
      git fetch --all
      git rebase origin/main
    2. Verify that your code is working by running unit test and the software, then push force on the remote repo with git push -f

    When your development is finished on your side

  3. Before any merge request or feedback on your code, rebase to have a clean history and up-to-date branch
    1. Rebase your code on top of remote main and squash your commits into a single one (or several relevant ones)
      git rebase -i origin/main will open your notepad to squash your commits (remember to have commits with the conventional format).

      1. Check the software is running and all tests are all green, then push force on the remote repo
        git push -f
  4. Once the reviewers are ok with your request (they have approved it on Gitlab), and all the pipelines are green;
    YOU (the developer) merge the branch into main.
    Check the box Delete source branch, to delete your branch on the distant repo after the merge.
    When done the task status is automatically updated to Validation.

Some Useful Git Resources for Best Practices and Learning

Here are some recommended Git resources for best practices, learning, and improving your Git skills:

Additional Git Resources

Here are some additional resources to further enhance your Git knowledge and skills:

Feel free to explore these resources to improve your Git workflow and enhance your development practices.

Now you are ready to read an apply our article on Conventional Commit with Git, or use Gitlab with Git.

Written by

Albert Oplog

Hi, I'm Albert Oplog. I would humbly like to share my tech journey with people all around the world.