GitHub Flow | Workflow Strategies

When comes to software development, Managing change can be challenging. It’s an elaborate process, where lots of people are using many complex tools, in parallel, to produce a one thing. Workflow is about controlling the sequence of events which transform a piece of work to ensure every person can use the best tool at the right time. There is no any universal solution for every team’s needs, but a good workflow will streamline all of the tools, processes, and people, for optimum productivity.

Rather than presenting a prescriptive set of features or family of products with a predetermined flow, GitHub gives you the flexibility to define the best workflow for you. It puts your code at the center of your development process and provides sensible tools for managing changes to your software.

Let’s take a look at some of the ways GitHub lets you define your workflow. Branching is a core part when comes to managing parallel software developments. So the Git, the version control system lets you create, destroy, and combine branches with minimal effort. So, branches can exist for as long, or as short, as you need. One of the most straightforward branching workflows is the GitHub Flow.

In this workflow, your project has a single master branch. you can create temporary feature branches when new development comes.

When changes are ready for review, you can open a pull request to review and discuss them.

Pull requests let you show others the changes you’ve made on one branch, so they can review and discuss them before merging changes into an another branch.You can also have additional information about build results, Test runs and etc. Team members can use this information to discuss the code and submit reviews to approve it, or request changes which need to be addressed before merging.

When changes are approved, you can deploy your code from your feature branch to production or any other environment if you need.

After that you can merge the feature branch into the master branch, and remove the feature branches.

Complex Workflows

Github’s flexibility supports workflows with more complex branching needs as well. One example of a more robust branching strategy is the Git Flow. Git Flow relies on long-lived branches for simultaneously developing new features while supporting current releases. In the Git Flow, you have two primary branches Master and Development. The master branch will always reflect the most recent production source code, while the development branch reflects the latest development for the next release.

Let’s see how the typical workflow with the Git Flow works.

Developers create feature branches from the development branch

Merge them back into development when features are ready.

When it is time to create a new production release, you’ll make a decision about which new features will be included in it. At that point in the development branch, you start a release branch. This allows work to continue on development branch without disrupting the preparations for releasing the new features to production. You may find that there are a few bugs to fix before releasing. It’s okay to add that work to the release branch as well, but it’s best to avoid adding new big features to an existing release branch. Therefore, save them for a future release.

When the release is ready, you merge the release branch into the master and tag it with a version number. GitHub recognizes tags in your project and lets you easily create releases from them.

Now, all of the work merge into the development branch, prior to the release branch which is available in the production as part of the newest release.

However suppose a critical bug arises in production. You can create a hotfix branch from the master branch to address the bug immediately, while planned work continues on development branch. When the bug is fixed, you can merge the hotfix branch into the master branch and tag the work, and create a new release.

You’ll also want to merge the hotfix branch back into development branch, or to a next release branch, if one currently exists.

More articles : techprogramme.com