How does the git's "local-repository" concept differ from "developer branches"?

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.

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.

A DVCS like Git or Mercurial introduces a publication workflow (push/pull) which is orthogonal to branching.

That means that:

• even though all developers are working on the same branch, they can do so "privately" on their own repo: as long as they don't publish they work (i.e push to an upstream repo), that common branch is actually their own. They can pull (fetch + merge) regularly in order to not diverge too much from the work of others on the same topic, but they will push when ready.

• a developer might even never push his/her work, but an integrator can fetch, from an upstream "integration" repository, as many branch (with the same name) from as many developer's repos that integrator needs to: each branch will be store in the integration repo in its own namespace (dev1/branch, dev2/branch, dev3/branch, ...)
  From there, the integrator can look at the commits each developer's branch is introducing, and decide to merge or not those changes in the integration repo.
  Note: this is slightly different in Mercurial, since named branch have names in a global namespace (See Jakub Narębski's answer on "Git and Mercurial - Compare and Contrast", looking at the "Personal opinion: I personally think that "named branches" ..." part)

So a git "local repo" transform any branch in a developer's branch (which doesn't prevent a developer to make his/her own private branch on top of those coming from a common repo).
Those branches are available for active publication (push by the developer) or passive publication (pull or fetch from an upstream repo, without direct intervention from said developer)

What David W's answer (upvoted) makes clearer is the difference between:

• working from a branch in a new branch (which could be linked to a developer, even though I prefer branches linked to a task or set of tasks, in order to isolate a development effort: see "When should you branch")
• working from a branch cloned from a repo in your own repo: you can work on the same branch, except it is a cloned (copy) of said branch from an upstream repo.
  If the developer repo isn't accessible by an integrator, then yes, as David says, "In Git, the developer's changes are unavailable until the developer delivers their changes.".
  If the developer's repo is accessible (even through a simple "local protocol" like a network share), then the developer's changes can be pulled from the downstream repo to an integration upstream repo)

See also "Describe your workflow of using version control (VCS or DVCS)" for another way to contrast the Centralized VCS way of using branches vs. the Decentralized VCS way of using repositories.

If it worked for you, great. I think you would find it would work even better with a DVCS, because they can support everything you're doing now and more.

One advantage of a local repository over a developer branch is that you can have as many branches as you want locally. You can spin up a quick branch to test something you're curious about. You can spin up a branch to test migration to the latest version of that library you love. All without needing to "pollute" the centralized server with stuff that perhaps shouldn't ever see the light of day.