GIT: Team Work and Workflow, Git Flow, Github Flow, GitLab Flow

Team Work

The Pull Request

This is used in order to contribute to projects when you don’t own them and, therefore, lack the necessary permissiones to push your commits and contribute to the project. Or in other words,  it's a request from the owner of a repository fork to the owner of said repository to incoporate all commits included in said fork into the repository. 

Real life case

I discover a bug in a repository I don’t own. I want to modify it but, as I don’t own it, I will need to follow a series of steps in order to suggest that change:

    1. Fork the repository in order to have it in my remote (this will clone the repository into my remote)

    2. Clone repository to my local

    3. Make relevant changes 

    4. Commit

    5. Push (this will push changes from my local repository to my remote repository for which I have the necessary permissions)

    6. Pull request will tell the owner of the repository that I am suggesting him certain changes. I can also mark it as a draft in order to warn them that I am still working on it. Another useful option would be enabling the owners of said repository to edit this Pull Request.

Team Workflow

Labels

Don’t confuse them with tags (which are semantic keywords associated with commits).

Labels are keywords associated with issues or pull requests. This labels can be modified inside of Issues Tab, on the top part of the section next to Milestones.

For example:

    • To do (Assignee)

    • In progress (Assignee)

    • To review (Reviewer)

    • Accepted (Reviewer)

    • Changes Requested (Reviewer)

The problem with this system is we are using labels for something they were not intended for, and we risk mixing abstraction levels. For example, we could have labels for completion levels (in progress, to review, etc) and labels referred to semantic descriptions like default ones (bug, enhancement, refactor).

Github Projects

This progress can also be defined within Github projects. Each new feature is a new project inside of which we can define the above mentioned status (To do, In progress, etc). Another advantage is being able to automate the kanban (system of columns) in our project. For example, everytime I close an issue I can automate the process so that it transfers to "For Review" column. The downside of this system though, is when using other Project Management Tools like Jira, it might make no sense to maintain this information twice.

PR Status

Another solution is creating a Pull Request as a Draft, that will not notify the reviewers of my pull request, but it will allow them see that I am working on something before I am close to completing my task.

Git Flow

The problem

Branches are free! They cost nothing, so basically you start with two:

  • master > ready for production
  • develop > where we place code for the next version of the project
Ooops! We have made a mistake and need to fix, but we want to keep track of this mistakes in our code and how we fixed it, so we create another one:
  • hotfixes > bug fixing
We want a pre-production branch for pre-production testing purposes, so, again, bring that branch on! It's free!

  • pre-production
Now, we have a version in production and we are realeasing a new version, and we also want to keep track of that:
  • version 2.0 
I am pretty sure I am not the only one who sees a problem here, right? We really need a set of rules to organize work, specially when working with big teams. 

So what would be a basic branch strategy for git flow?

  • Master > Ideally only code ready for production
  • Develop > Every now and then merged into Master
  • Feature > It originates from develop and is merged into Develop. This branch is used to develop new features or functionalities within our app.
  • Release > It originates from develop and is merged into Develop and Master. This branch is used for the next code in production. This is for bug fixes and minor adjustments  before production.
  • Hotfix  > It originates from master and is merged into Develop and Master. It is used to correct production code. 
In order to implement Git Flow, everytime we want to implement something in our code we will:
  1. Create a new branch
  2. Create and implement code
  3. Merge into relevant branch (Develop and/or Master).
  4. Close Branch

GitHub Flow

This is more simple and it has way less branches:

  • Main/Master > Ideally only code ready for production. All of other branches are born from this. 
  • Feature/Hotfix
The most interesting part of this is, instead of deploying master, which should be the only source of truth, we deploy feature or hotfix branches. That way, in case a bug appears, we roll it back and deploy our fully functional source of truth from master while fixing the bug.
In case no bug appears, we merge that branch into master and deploy it. 

The main advantage of this is, everytime you deploy a feature branch, you are able to check how that sole feature integrates with the rest of the code, instead of deploying twenty features at the same time, as would be the case with Git Flow. 

GitLab Flow

  • Main/Master 
  • Feature/Hotfix > Changes merged into Pre-production or Production are made through cherry-picks in the case of bugfixes
  • Pre-production > Updated from Master through Merge Requests (the equivalent to Pull Request in GitHub). 
  • Production
Though production environment is highly trustable, this workflow is more complex than GitHub Flow. Nevertheless, as Main/Master merge requests into Pre-Production or Production are likely to contain several features (otherwise we would uselessly reviewing the same merge request as the one made from feature branch into main/master), making a mistake is more likely to happen. 

As you can see, there's plenty of options when orginizing team and work flows, the choice depends on particular situations but I hope it is as instructive for you as it was for me to have an overview of what they look like and their main advantages and disadvantages.

Happy coding everyone!

Comments

Post a Comment

Popular posts from this blog

SOLID: The Single-Responsibility Principle (SRP)

 This Object Oriented Programming principle states that each module or class should be responsible for only one part of the functionality.  By saying this, we are stating that each subsystem, module, class or function should have just one reason to change.  How do we accomplish this? By developing small service classes with enclosed objectives.  What is it that we want to accomplish through this strategy?   More cohesion and less resistance to change. Allow the composition of classes (or class injection) which deserves a extended post in this blog. Avoid duplicity and copy-pasting portions of code. Now, that seems fairly simple but, as with any theoretical principle, the problem is usually visualizing with an example what the theory is suggesting and, even more than that, in which cases should we apply this theory. Of course, it's not the same developing a small online shop for a cousin who produces and sells hand made costume jewelry, than developing  an a...
Read more

Symfony HTTP client

 I am currently developing a very simple app which offers you the possibility to create question-answer flipping cards, creating thus some kind of funny Trivia to practice on any topic you want to apply it to. As a user, you create first the question-aswear entities which also include  category field, and then you can practice them in the playground area, which shows you the question on a hoverable flipping card. It also offers you a textearea which disables 60 seconds after you start typing on it, so that you can write down your answer before actually flipping the card and getting to see the correct one.  In this app, though simple, I wanted to keep a client-web service architecture from the very beginning. The web client contains the views and communicates with the API, which contains the data through Ajax calls. This was working consistently so far. An example of the creation and saving of new question-answer items is: When I press on "Create new question" button, I am...
Read more

Inheritance: Abstract classes and interfaces

What is inheritance? It's a programming principle used in the PHP object model which allows a class (child) to inherit another class' (parent) protected or public methods, properties and constants, retaining the parent's original functionality, unless these are overriden by the child class. What is an abstract class? A class that contains at least one abstract method, which means only the signature of the method is defined. For example: abstract Class Parent { abstract protected function defineMyFunction (). } Class Child extends Parent {      protected function defineMyFunction () {           return "I am an abstract function in my Parent class" ;      } } As childish as this example might seem , it quite easily represents the aforementioned definition. When a  class (or child class) extends from an abstract class (or parent class), it must define all methods declared as abstract. In fact, if you are using an IDE...
Read more