Git

Git stores each version of the code and lets many people work on a project in parallel. Its business value goes well beyond being able to undo a file. A well-kept history shows why a change was made, who reviewed it and which version went to production.

Git itself does not decide how people work together. The team needs rules for branches, commits, code review, releases and emergencies. A process that is too heavy slows down small fixes, while having no rules at all makes it hard to judge risk.

We can help tidy up your existing workflow, move repositories or connect Git to CI/CD. We start by looking at how a change currently travels from task to production, and where the team waits, resolves conflicts or does things by hand.

A clear process starts with a small change linked to a task. A developer creates a branch, makes logical commits, opens a pull or merge request and hands the code over for review. Once it is approved, automated tests confirm the basic assumptions and the system builds an artefact ready for deployment.

Not every project needs the same number of steps. A small team can work with short-lived branches and quick reviews. A regulated product may need extra sign-off and an audit trail. The rules should match the risk rather than copy a model from another organisation.

A definition of done helps decide when a change is ready: the tests have passed, any migration has a rollback plan, the documentation is updated and monitoring will reveal a problem after release.

A commit should represent one logical change. That way the reviewer can see its purpose, and if something breaks, the team can revert that specific piece without removing unrelated work.

A commit message is best written as a note about the result and the reason for it. “Fixes” says nothing about what was fixed. “Don’t send a second notification when a webhook is retried” gives context that will still be useful months later.

We don’t expect a perfect history on every working branch. Before merging, we tidy it up to the extent the team has agreed. What matters most is that the main history is understandable and linked to a business decision or a bug.

Trunk-based development relies on short-lived branches and merging changes often. Git Flow introduces separate branches for development, releases and hotfixes. The first model makes continuous delivery simpler, while the second can help when several versions are maintained in parallel.

Long-lived branches increase the risk of conflicts and delay feedback. If a feature can’t be shown to users straight away, you can separate deploying the code from switching it on by using a feature flag.

We choose the strategy based on release frequency, the number of teams and how testing is done. The name of the workflow matters less than whether people understand the rules and can follow them without working around the process by hand.

Code review helps catch bugs before deployment, but sharing knowledge about the system is just as important. The author explains the decision, and a second person checks the impact on security, data, performance and maintenance.

Small pull requests get faster and more thorough feedback. A large bundle covering dozens of topics encourages a quick, superficial approval. It is therefore worth splitting a project into changes that each have their own purpose and can be tested independently.

An automated linter or test does not replace a conversation about architecture, and a person shouldn’t be checking formatting by hand. We agree which rules the pipeline enforces and where you need the judgement of someone who knows the context.

A repository can trigger tests, static analysis, image builds and deployment once agreed conditions are met. Every artefact is then linked to a specific commit. You can check what is running in each environment and which code it was built from.

Deployment permissions, protected branches and required reviews reduce the chance of an accidental release. In an emergency the process should still allow a quick fix, while keeping a record of the decision for later.

We design pipelines to give fast feedback. The quickest tests run first, heavier ones later or in parallel. A process that is too slow encourages people to bypass it, so its running time also needs watching.

Access to the code is granted by role and reviewed regularly. The main branch should be protected, and particularly sensitive operations can require approval from the owner of that area. When someone leaves the team, their permissions must be removed along with their access to other systems.

Passwords, tokens and keys should never end up in Git. Removing them from the latest commit does not remove them from the earlier history. If a secret has been committed, it must be revoked and replaced with a new one, and only then should the repository be cleaned up.

You can also sign commits and tags, require multi-factor authentication and keep dependencies under control. We match the safeguards to the value of the code, the client’s requirements and the risks linked to the pipeline.

Moving a repository should preserve the full history, branches and tags. Platform-specific items are migrated separately: pull requests, issues, wikis, protection rules, pipelines, artefacts and permissions. Not all of them have a direct equivalent.

Before the switch we list all integrations and prepare a cut-over plan. We agree when the old repository will be frozen, test cloning and deployment from the new platform, and then update the addresses in the team’s tools.

GitHub, GitLab, Bitbucket, Azure DevOps and self-hosted solutions differ in their ecosystem, management model and CI/CD. The choice should take into account existing accounts, security requirements, hosting and administration costs, not just the price per user.