Common GIT workflows

One of the greatest pros of GIT as a version control system is its optimization for quick and easy committing, branching, and performing other actions with both local and remote repositories.

Due to this, you can conveniently implement GIT in your working circle and work out the workflow that will suit your team best.

However, it may be confusing at first to have to many options.

That is why we provide you with a quick survey of the most common GIT workflows for enterprize teams.

The workflows described here are based on the comparisons provided here and here but correspond to the GIT functionality embedded in Lycia.

Generalized individual workflow

Number of actions performed by a single developer working with GIT is generalized below:

They include:

• cloning the already existing remote repository or sharing your 4gl projects in GIT,
• creating branches and switching between them,
• modifying files (not a GIT action, strictly speaking) and committing changes to your local repository,
• rebasing or merging,
• fetching (or pulling) and pushing to remote, etc.

These actions are performed by all (with few exceptions left out of this documentation) developers on a regular basis.

Enterprise workflows include these individual actions and must be organized in such a way that no actions of one developer spoil or trouble the work of another developer.

Four workflow variants described below can be implemented in your production process as is or mixed and matched depending on your current needs.

Our convention names for these workflows are

• centralized workflow,
• feature branch workflow,
• specified branches workflow, and
• personal repositories workflow.

Centralized workflow

Centralized workflow can be considered as a starting point for the groups who are used to working with CVS or SVN.

Like these version control systems, centralized workflow uses a central repository - master, by convention - that holds all the changes of the project. No other branches or repositories are created.

This single "official" branch gives you extra confidence the all the changes get to there they should be. Plus you do not have to change your existing workflow: You team can go on working exactly as it used too.

However, this workflow is a bit more likely to raise conflicts, so you have to be sure that you have got the changes from other developers before you push your own ones.

The second thing you have to know about the centralized workflow is that it is always better to rebase instead of merge because otherwise, your project history can become uncomprehensible:

Here is a step-by-step explanation how a small developing team can implement the centralized workflow in its workplace:

Step 0. Somebody initializes the remote repository.

Step 2. In their local copies of the project, developers create, modify, and delete files.

Step 6 (optional). The developer resolves all the conflicts.

Step 7. The developer pushes his/her changes to the remote repository.

As the steps 1-7 are repeated all the time, the individual workflow of each developer is this:

The example of how the centralized workflow works in a team of two is in this short video:

Feature branch workflow

Feature branch workflow is similar to the centralized workflow in many points but it give you the chance to start benefiting from the GIT's distributed nature.

With the feature branch workflow, you still have your central repository - master - that holds the project code and keeps the history of all the changes.

The difference is that, instead of committing to the same and the only branch all the time, you start a new branch - feature branch - every time you start working on a new feature:

When working in a feature branch, developers perform the same actions as ever - modify files and commit changes - but without disturbing the master branch. Due to this, the master branch never gets the broken code.

After the feature is fully implemented and tested, the feature branch is merged in the master branch and then deleted:

Specific guidelines of how to implement the feature branch workflow for a development team depend on how many developers work on the same feature in the same feature branch.

Feature branch workflow with a single developer

If there is only one developer, then s/he takes these steps when working on a feature:

Step 1. The developer creates a local feature branch based on the origin/master branch.

When the feature is fully implemented and tested, it is time to publish it to the remote repository.

Step 4. The developer fetches the updated version of the remote repository (cf. Step 4 here).

Step 6 (optional). In the process of rebasing (or merging), conflicts may occur that must be resolved.

Step 7. The developer pushes his/her changes to the remote repository.

In this case, his/her individual workflow is this:

Feature branch workflow with a group of developers

If there are several developers working on the same feature in the same feature branch, then their combined workflow includes these steps:

Step 1. One developer - D1 - creates his/her local feature branch based on his/her local master branch.

Step 2 (optional). In this local feature branch, D1 creates, modifies, and deletes the necessary files and then commits them.

Step 5. All three developers work on the feature according to the centralized workflow (Steps 2-7).

Step 6. After the feature is fully implemented and tested, and all the related commits are pushed to the remote repository, one of the developers - say, D1 - fetches the updated versions of both remote feature and master branches.

Step 8 (optional). In the process of rebasing (or merging), conflicts may occur that must be resolved.

Step 9. After rebasing, D1 pushes his/her local feature branch to the remote master branch.

Step 8. The remote feature branch is deleted.

Step 9. All the developers who worked on this feature, delete their local feature branches.

In this case, the individual workflow of a single developer is this:

• if the developer only committed to the branch:

• if the developer created and deleted the branch (and committed to it):

The example of how the feature branch workflow works in a small team of two developers is in this short video:

 

Specified branches workflow

Specified branches workflow (also called gitflow workflow) was developed and advertised by Vincent Driessen.

It is a strict branching model organized around and focused on the project release and thus is well-suited for projects with established release cycles.

You can read about this workflow here and here.

Personal repositories workflow

Personal repositories workflow (also called forking workflow) differs from the three other workflows described above by the fact that all the developers engaged in it have their personal working space not only on their local machine but in the remote repository as well.

These are specific traits of the personal branches workflow:

• all developers have their own remote (server-side) repositories in addition to the "official" one;
• developers are allowed to push only to their own remote repository but can pull from all the repositories;
• only project maintainer is allowed to push to the "official" repository.

This last trait makes the personal repositories workflow especially useful for large development teams and development teams that include third parties (often untrusted).

With personal repositories workflow, all developers work - commit and push - in their own personal branches. Once they want to publish their changes in the master branch, they must notify the project maintainer who would inspect the code and decide whether it can be integrated to the official code base:

Specific guidelines for working according to the personal repositories workflow are identical for all developers and differ only for a project maintainer.

Personal repositories workflow for an "ordinary" developer

For an "ordinary" developer - not a project maintainer, personal repositories workflow is as simple as the centralized workflow:

Step 1. The developer forks the official repository to create its copy on server.

Step 2. Сlones this new - his/her personal - repository to get its copy on his/her local machine.

Step 4 (optional). While working in his/her personal repository, synchronizes with the official repository once it is updated with the new code.

Step 5. After some piece of work was completed, pushes his/her changes to his/her personal remote repository.

Step 6. And notifies the project maintainer that some code is ready to be published to the official code base.

In this case, the developer's individual workflow is this:

Personal repositories workflow for the project maintainer

The project maintainer not only works on the project his/herself but also is responsible for integrating the updates from other developers to the main code base:

Step 2 (optional). Works in this official repository as described here in Steps 3-5.

Step 3. Learns that some code is ready to be published.

Step 4. S/he fetches the branch - master or feature - that contains the necessary changes to the official repository.

Step 6. Resolves all the conflicts that might occur.

Step 7. Pushes his/her local master branch to the official repository.

Step 8. Notifies all the team members that the official repository has been updated and they must synchronize with it.

The individual workflow of a project maintainer is this: