Skip to content
vincere_

Work with Git

Using git is not only helping us to collaborate among developers. For us, it’s more than that, it’s an asynchronous collaborative culture and a sharing knowledge process indirectly in a team and we take that seriously. This is how we work with git in Vincere Digital.

Branching Model

We have chosen trunk-based development as our preferred Git branching model for several reasons. Foremost, it aligns perfectly with our culture of rapid development and continuous delivery and we can ensure that new features and bug fixes reach our users faster.

Trunk-based development offers numerous advantages for our team and our projects.

  • smoother and quicker development cycles.
  • reducing the risk of large and complex merge conflicts.
  • smaller changes mean more frequent releases and faster delivery.
  • ensuring that only essential and well-tested code is added.

While trunk-based development offers significant benefits, it’s not without its challenges.

  • require the developer to have CI/CD to support the rapid flow of changes.
  • require the developer’s commitment to write a test.
  • require the developer to not break the build (CI/CD)

How to TBD

  • Make sure you are creating a branch from the main branch.
  • Always git pull origin main before creating a new branch.
  • Small commit preferred, try to limit the total file changes in a pull request. Eg: Max to 10 files in a PR
  • Prevent long-lived feature branches = Preventing merge conflict hell
  • Add unit tests or at least a simple render test or simple end-to-end test.
  • Implement CI/CD or at least the CI to run the tests when a commit is merged to the main branch.
  • Do not break the CI/CD.
  • If the feature is not ready hide it with feature flags (FF).
  • Use rebase on your own branch, and squash when merging to the main branch.
  • Pull Request Review Culture
  • We know the importance of collaboration and learning from each other. One of the practices is the art of reviewing each other’s pull requests.

For The Author

  • Format every file before committing changes. Use Prettier for .js file, PHP Intelephense if it’s an .php file. PHPCS for WordPress.
  • Your code should be DRY and prevent WET code. Write a reusable function for a specific task, don’t copy-paste.
  • Readable and maintainable. Make everyone easily understand your code at first sight.
  • Small changes’ PR is preferable. Big PR often comes with many bugs.
  • Put a screenshot or video. Make your reviewer confident with your code.
  • Add the ticket link or ticket number on the PR or vice-versa.
  • One PR one task. If you have another change that doesn’t relate to the task, create another PR.

For The Reviewer

  • Review PRs in the morning before starting to work on your task, or before having lunch is better to help people work on it during office hours.
  • Be positive. Avoid criticism. Provide a constructive feedback. Keep your ego out of code review. Don’t merge if the CI is broken.