An organized and self constructive team is very valuable to the success of a project. All projects work to a goal to develop the implementation of the idea that is obtained through the vision and direction of the products users, needs, and use cases, and the companies vision of technology and user experience automation. It is very important that the communication structure of a team is not disjointed and is as uniform as possible.

There are multiple ways to achieve this goal, I will speak about the most effective organized team I have yet to experience.

Utilizing Git with Github

It all starts with Git with Github. We use Git to make branches of the code individually, and manage your branches of our main branch as well as for branches for our unstable versions of the product that we make. Another benefit of Git is the use of tags, that can be used for tagging our versions of our product. Tags allow us to justify milestones of our product.

With Github we can use branch protection rules to prevent pushes to the code. If we want to push to our master branch we will need to push a pull request that will merge into a branch code.

Semver

To support our versions we use the semver (semantic versioning) 1.1.5. This is used to note the major, minor, or patch versions of our software. Every time we push a version of our code live, we can update one of these numbers, letting our team know that we have accomplished a major milestone in our development. We use tags in Git to support our versioning.

Main Branch

If you are working on a software or an application you will use the main branch to support the latest and best code in the software. This is where all new features can be supported. This is were you build off your minor and major versions from. Every time you bump your minor or major version, create a new branch with the respective minor/major update. <major>.<minor>.x IE the name of the branches are 1.0.x, 0.16.x, and 5.6.x.

Supporting Multiple Versions

If you support a software component that might be used by multiple clients, then you might have a support policy. A support policy is the following, it of n-x means that you support the main version of your product, plus x additional versions of your product as well. IE. n-2 means you support your latest version 1.16.0, and support 1.15.x, and 1.14.x.

In the case above you would want to have the following branches main, 1.15.x, and 1.14.x. Anytime you update your main version with a feature, you might want to support that feature in your older versions. In this case you merge the commits into your main and all other supporting versions of the software, along side with bug fixes and other patches that are needed for your older versions.

When it comes time to create a new minor version of your software, then you use branch off of main with your new minor version 1.17.x, create your tag 1.17.0 and then no longer support 1.14.x. While still supporting 1.15.x, and 1.16.x.

Make sure to make your code backwards compatible.

Issue Tracking

Github offers a nice way to create issues. Issues are a system of tickets that can be created by users to track the progress of features or epics within the application. If your project is open source it is also a nice way to add in support for your users, so that they can generate issues when they come across bugs, performance issues, or want to add support for some of your third party software that your software utilizes.

Who, What, Where, When, Why, How

Using Issues you can create a nice link to other issues that might relate to any one particular issue. This enables a nice link for your current developers or new developers that start working on the project, to have an idea of the journey of an entire epic or set of features. It tells a nice story to the developer.

Who worked on it, what is it’s purpose, where is the code that pertains to the set of features, when was the code deployed and implemented, why the changes or features were made, how the code changed over the course of the time, what challenges did the team face, where did the idea come from, and much more can be answered by using an effective issue tracking in Github Issues.

Self Documentation

The coolest feature by far about Github Issues is the use of self documentation of the project. This is a living document that is being added to and updated constantly by developers, project managers, and clients in some cases. It provides a nice way for the developers to write out instructions to inform the business or cliental about the project and set of features that are being worked on. The progress, and the other set of work that are requirements for the particular issue in question, if the issue is apart of an epic.

Pull Requests and Code Review

Probably the best feature about using Github is the ability to have code review. This feature allows teams to post code for review for other peers to view. This is a great feature as you can add reviewers to approve the code, which allows your team to set standards on code quality, and expectations.

One core benefit of code review is that it allows for a form of discussion between developers to see changes and updates within the code. Things that allow for further implementation and foresight and vision within the project. It gives the ability of multiple team members to view and read the work of other team members and understand the changes that are being made to the system. Enriching your team’s knowledge about the project as the application evolves over time.

It also serve as a place where others can promote other issues that can be linked with the pull requests to share a web of links to cultivate that self documenting document.

Continuous Integration

Once a pull request is generated, you can attach a set of commands that will enable and disable the continuous integration portion of the code. This can allow for all your tests to run when code is committed and pushed to the upstream branch for the pull request. Enabling as fast as possible a way to review the compatibility of the code, and check for any bugs that might be present in the code.

You can make all Pull Request’s require that they pass testing. Building a proven application that can withstand errors and provide robustness to your CI pipeline.

Continuous Deployment

Once a pull request has been committed into the main branch, you can attach continuous deployment policies with Github Actions to promote and roll out your deployment however you configure our deployments. Canary, Rolling other whichever flavor you prefer deployments.

These are just some of the core benefits of using Github with a team, and which provides the knowledge system and documentation of why a project is being lead in a certain direction. I hope you take these core concepts and apply them if your team is not currently.