Home/ Questions/Q 4555748
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-21T17:16:10+00:00

In a previous job, I found easier to manage and keep a stable pre-release

  • 0

In a previous job, I found easier to manage and keep a stable pre-release branch (or main, depending on setup) by having each developer work on his/her own branch. We only had a single production instance, so no need to support multiple versions of the same apps.

This “pre-release” branch is named that way because there was another branch (main) where we’d make our staging and production releases from. The branches were setup such that only code from the pre-release branch could be merged into the release branch. These merges were our code review checkpoints. The CI builds were made from this pre-release branch as well and it was up to each developer to merge from “pre-release” to their own branch to migitage complex merging issues when the development for that body of work was completed.

If there was a need for developers to pair up and work together one a given feature, nothing but their own branches permissions prevented them from working with others. This worked well for managing distributed teams where individuals within each team were working on separate/multiple features.

With the help of frequent (1-2 times a week) 30-minute status update meetings, we as a team, would decide what would go into QA and what wouldn’t for that particular QA release.

This system worked, but I find a lot of resentment for developer branches when searching on this topic. There seems to be a lot of enthusiasm about git’s local repository feature. Yet, it seems that they are just different ways of addressing the same problems. Not considering the cross-network issues that local repositories address, such as check in latency and such.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    There are three main differences:

    1. Local repository means just that: It is local to your system, and if you ever found yourself stranded on a desert island with no Internet connection, you’ll still be able to commit your changes. One of the best things about Git is that you don’t have to be connected to your repository to be able to take advantage of the version control system. Developers sometimes work remotely without being able to access the main repository and that can usually be messy when you have a system like Subversion, Perforce, or another type of centralized repository version control system. With Git and BitKeeper, you can easily work offline.

    2. In a developer branch situation, you normally are branching from the integration branch to your developer branch and merging back to the integration branch. In Git, you don’t merge, but send patches and you can send your changes not just to the master repository, but to other developers without first sending your patch to the master repository. This allows developers to work together without touching the master repository.

    3. In a developer/integration branch setup, the developer branch is in the repository which means others can see it. In Git, the developer’s changes are unavailable until the developer delivers their changes.

    • 0