No! It is a good practice to have a remote branch namespace for each developer.
A single branch is often not enough, so the developer would either end up rewinding it a lot or it wouldn't be helpful much. You rather want to say that a developer can push whatever they want under their.name/
. They can use it for publishing preview versions for others, giving version for somebody else to test or even for somebody else to integrate.
You can use this also for giving branches to integrator or you can use task-based names. The task-based names are usually easier to track for the integrator, but make developers think more about the naming and people don't like thinking. I don't know which will work better in practice; might even depend on the particular team.
If you absolutely want to keep this naming scheme, you might:
Decide that you don't care about these warnings
That is, if you're happy with the fact that:
git checkout <ref>
will check out refs/heads/<ref>
over refs/tags/<ref>
(see git-checkout)
- other commands will use
refs/tags/<ref>
over refs/heads/<ref>
(see gitrevisions)
For example, in this test repository, the v1.5.2
branch points to commit B, but the v1.5.2
tag points to commit A.
% git log --oneline --decorate
8060f6f (HEAD, v1.5.2, master) commit B
0e69483 (tag: v1.5.2) commit A
git checkout
prefers branch names:
% git checkout v1.5.2
warning: refname 'v1.5.2' is ambiguous.
Switched to branch 'v1.5.2'
% git log --decorate --oneline -1
8060f6f (HEAD, v1.5.2, master) commit B
but git log
will use the tag name:
% git log --decorate --oneline -1 v1.5.2
warning: refname 'v1.5.2' is ambiguous.
0e69483 (tag: v1.5.2) commit A
This could be confusing.
Train people to delete their local branches when they see a new tag
This might be hard/awkward depending on the size of your organisation.
Write a wrapper around "git pull" and "git fetch"
That is, write a wrapper that checks if there are any tags that shadow branch names, and warn about (or delete) those branches. This sounds painful, and it could be undesirable if the shadowed branch is currently checked out.
Unfortunately, it sounds like the easiest way to solve this problem might be to change the way you name your branches. The link you posted uses different naming schemes for tags and branches: if you're already mostly following that method, adopting its naming scheme might be the easiest solution.
Best Answer
The recommended strategy is "don't do it". The cleanest way to do this with git is to have three repos:
And then use
git submodule
(documentation here) to have both Project A and B sync with the common libraries (basically submodule lets you have a repo inside a repo). If you use any build or dependency management tools, like Maven, Gradle or npm, you could skip thegit submodule
part and use them to manage the dependency (which is even cleaner and less error-prone).If you cannot split the repo in three, then you are going to need three separate masters with three develop branches and rebase the common master onto the two projects' masters to apply the changes. Note that it is extremely easy to break something this way (and to end up with merge conflicts), so this is going to require extreme care.