CODEWITHSUNDEEP
gitgit-branchbranching-and-merginggit-tag
felipe_dmz
felipe_dmz

Reputation: 95

To create a branch from a git tag is a good practice?

I have started working with a new dev team, and they have a practive that I can't find in git-book about branch management:

They use a single branch to centralize changes and close a tag for every release. Overal no news right here, but:

My doubts are:

  1. In my understanding git log or even gitk shows the tag near to the commit, just to associate what commit id that tag gave is the origin of it:

    git log with tags

  2. But, tags by definition are snapshots, so they are detached:

    git tag detached detail

What are the real advantages/risks of doing that? Never see a team working like that and have suspicious that we could be entering in heavy pitfall.

  1. Tried to create branches from tags - that worked ok;
  2. Back merged branches created from tags to another branches - that worked ok also;
  3. Make rebase process and another recursive operations from branches originated from tags - also all right;
  4. Seems that even detached, once we creates branches from tags everything works fine.

They maybe are showed in git tree, but in concept tags do not belongs to "formal git tree", that is bugging my mind, and goes all against what I studied in git-book...

The guys here are used to it, but for is clear that last tag should be equals HEAD of master, so the PR fixes should be created from master.

In “detached HEAD” state, if you make changes and then create a commit, the tag will stay the same, but your new commit won’t belong to any branch and will be unreachable, except by the exact commit hash. Thus, if you need to make changes — say you’re fixing a bug on an older version, for instance — you will generally want to create a branch. If you do this and make a commit, your version2 branch will be slightly different than your v2.0.0 tag since it will move forward with your new changes, so do be careful. reference.

Upvotes: -2

Views: 535

Answers (1)

matt
matt

Reputation: 535586

The behavior you report is normal and best practice.

Consider what we're trying to do here. We have a commit representing the state of a release, sitting off in space with nothing pointing to it (and keeping it alive) but the tag:

A -- B -- C (main)
      \
       X 
       ^ [tag: release1.1.1]

We now discovered a bug in the release and we need to hotfix it. We thus need to perform two tasks:

(1) Fix the bug in the release itself and commit that fix.

(2) Merge the fix back into main.

The problem is the word "commit". Where in the architecture is that commit going to go? You could start by checking out (switching to) the tag, and edit and commit as many times as needed:

A -- B -- C (main)
      \
       X -- Y -- Z
       ^ [tag: release1.1.1]

But the problem is that we now have no convenient way to refer to Z, which contains the ultimate fix here. We could of course now tag Z, and we probably will; but to do that, we have to refer to it by its SHA. And what's more, all that time, as we were working to make Y and Z, we were working in "detached head" mode, which is very clumsy to work with, especially if multiple people are cooperating to work on this fix.

Instead, make life simple: begin by starting a branch at the tag point. That way, while we are working on Y and Z, we are working on a branch, which is always the best way to work with Git:

A -- B -- C (main)
      \
       X -- Y -- Z (hotfix)
       ^ [tag: release1.1.1]

Now we simply tag hotfix with the new release number, and release it; and then switch to main and merge hotfix. We can now delete hotfix; it has done its work.

If any of that confused you, and was not as obvious and intuitive as it should be, perhaps the problem is that you just don't know what a branch is. It isn't a continuum of linked commits; it is just a string, a reference, a label, a temporary name for just one commit. Branches in git are incredibly lightweight, and they should come and go readily and rapidly, like virtual particles that pop into and out of existence.

A branch serves three purposes:

  • It gives a convenient label for a commit.
  • It keeps that commit (and its chain of parents running back in time) alive as you work.
  • When you add and commit while a branch is your HEAD, the branch name is moved automatically to point to that new commit.

So it sounds to me like the lesson for you probably is make more branches! You should be nimble and lithe with your branch creation; make one any time you have work to do or an idea to try out. They cost you (and Git) nothing at all, and they make life much simpler as you move forward.

Upvotes: 1

Related Questions