Chapter 13

Introduction to Workflows

In the previous chapters, you learned the basic concepts of Git. Only the most important commands with the most important parameters were given.

Even with this selection you have perhaps asked the question: When will I use merge or rebase again?

You have surely searched the internet and come across various applications and even more commands and parameters. This flexibility is both a strength of Git and its weakness.

The following workflows describe typical uses of Git in development projects. Here, the focus is on completing tasks rather than on more parameters. Each of the workflows is described using only one solution. It is explained in detail so that the workflow is sufficient for your work and you do not need to always look up the help file.

Even after many years of using Git, there are tasks that need to be done less often, such as splitting a repository. In this case, the workflows can serve as a brief description of commands.

Even more lesser known commands and parameters are used in the workflows if the tasks require it. Therefore, you will also learn more ways of doing things in Git.

When Can I Use These Workflows?

When selecting a workflow selection, we looked at a typical project process.

The Beginning of the Project

If you are starting a new project from scratch and have decided to use Git as the version control, then your first task will be to choose and setup the infrastructure for versioning. The workflow “Project Setup” in Chapter 14 describes the process.

If it is a project that needs to be migrated to an existing Git project, then look at Chapter 15, “Developing on the Same Branch.”

The Development

Once the infrastructure has been defined, the handling of branches should be made clear with the team. It is either all developers work on the same branch, as explained in the workflow “Developing on the Same Branch,” or a separate feature branch is created for every task as explained by the workflow “Developing with Feature Branches” in Chapter 16.

If errors that were not present in earlier versions suddenly appear in development, then the workflow in Chapter 17, “Troubleshooting with Bisection” may help find the root of the problem.

For quality assurance after changes, you should set up automatic builds and tests. For working with Git in a build server, see the workflow “Working with a build server” in Chapter 18.

If Git is not yet used as the version control in your project, but you still want to work with Git, then refer to the workflow “Using other version control systems in parallel" in Chapter 19.

Project Delivery

After the development of the current release is complete, you should make sure a well tested product is delivered to the customer. At the same time, prepare for the next release and resolve problems not yet resolved in the last release. The workflow “Delivering a release” in Chapter 19 discusses it.

Refactoring

Project requirements change with time and with new insights. So it may happen that a decision to divide a project into multiple Git repositories must be reconsidered.

A monolithic project that was initially small may grow and must be modularized. The workflow “Splitting a big project” in Chapter 20 describes how a large repository can be divided into smaller ones.

The opposite can also happen. Dealing with a split in a many-repository project may turn out to be too complex. Re-merging repositories is discussed in the workflow “Merging smaller projects” in Chapter 21.

When a project has been there for a long time and undergone many changes, its associated repository may have grown very large. The histories of all the files include files that were in the local workspace of each of the developers. In particular, when large binary files have been versioned in earlier versions, this can lead to unnecessary resource consumption. The workflow “Outsourcing long histories" (in Chapter 21) describes how a project history can be split and only the more recent versions stored locally by each developer.

Structure of the Workflows

The following is the structure of the descriptions of the workflows in the following chapters. Each section is kept brief.

The entry

Each workflow begins with a brief motivation that explains why and in what context the workflow should be applied. The central tasks of the possible decisions and the special features are described. At the end there is a brief summary of the points that are discussed in this workflow. After this section you will know whether or not the workflow is relevant for your project.

The Overview

This section describes the basic procedures by way of an example. It describes the basic terms, concepts, and Git commands that are needed in this workflow.

After this section you will understand how the workflow works in principle and what Git resources are used.

The Requirements

Each workflow works only under certain conditions. After this section you will learn if the workspace can be used in your project. You will recognize what prerequisites need to be provided or why this workflow cannot be applied.

The Compact Workflow

This brief overview describes the workflow in a few sentences and presents the main concepts and ideas. If you use this book as a reference, this page will serve as a reminder.

Process and Implementation

A workflow may consist of one or more processes. Processes describe individual subtasks that you need to carry out to complete a task. This section describes each process in detail as well as which Git commands must be run with what parameters and in what order. It is deliberately written as a proposed implementation.

After this section you will know how you can implement the relevant function with Git.

Why Not the Alternatives?

Git is a great toolbox, and many tasks can be solved using its various tools. In this section, we discuss alternative solutions and explain why we chose a tool.

There are both alternative strategies that do not make sense from our point of view or that do not work, as well as solutions that would work only in a different context. Here we will also discuss solutions that may be useful when it comes to special cases of the task.

This section explains more thoroughly our reasons for selecting the Git tool and shows you alternative solutions.