GIT Tags versus SVN tags, and HotFix/Patches management

Question

Quick question, about how to handle an hot fix scenario in SVN and GIT, please correct me if i'm wrong.

I come from a solid experience with SVN, i got less experience with GIT and i want, mainly, know if my translation in GIT is okay (not the best ever!) but just if it should work as expected.

SVN:

1. I'm developing on the TRUNK, the customer asks me to work on a special feature and i decide to develop this feature on a BRANCH

2. The feature is okay, I'm about to merge it to the TRUNK that in the meanwhile has been updated with several changes, but the customer asks me a release straight away, and that they have been focusing the testing the BRANCH so they don't want to take the feature merged into the TRUNK, but they want me to release directly the BRANCH.

3. OKAY, far enough, I TAG the BRANCH and i release it to PRODUCTION, then i will be spending the next days merging the feature into the TRUNK for the next release when my TRUNK changes will go live, moreover i decide to delete the BRANCH cause i don't want it anymore, cause the feature has been developed and is gonna be merged into the TRUNK, (and i got the TAG to save the base code)

4. OH MY GOD! there is a bug into the new feature, i got to fix it, but i don't have the BRANCH anymore, no worries "version of control" are made for this, just BRANCH the tag just released, develop your fix and than release it again, then don't forget to merge the fix back into the TRUNK.

GIT:

1. I'm developing on the MAIN_DEV branch, the customer ask me to work on a special feature and i decide to develop this feature on a FEATURE_BRANCH

2. The feature is okay, i'm about to merge it to the MAIN_DEV, that in the meanwhile has been updated with several changes, but the customer is in love with my new feature and asks me to release it straight away and that they have been focusing the testing on the FEATURE_BRANCH so they don't want to take the feature merged into the MAIN_DEV branch, but they want me to release directly the FEATURE_BRANCH

3. OKAY, far enough, I TAG the FEATURE_BRANCH and i release it to production, then i will be spending the next days merging the feature into the MAIN_DEV for the next release where my MAIN_DEV changes will go live, moreover i decide to delete the feature_branch cause i don't want it anymore, cause i developed the feature..

4. OH MY GOD! there is a bug into the new feature, i got to fix it, but i don't have the FEATURE_BRANCH anymore, and i cant fix it into the MAIN_BRANCH cause contains new updates that i don't want to release...no worries "version of control" are made for this, just branch the tag just released, develop your fix and than release it again, then don't forget to merge the fix back into the MAIN_DEV.

Questions:

• It's my the GIT translation of my SVN flow correct?
• If i cut my tag from my feature_branch, than i delete my feature_branch cause the feature has been developed, i can always develop HotFix or Patches on a new branch cut from the tag just released, there is no need to keep stored the feature branch cause i got everything into the TAG (code, history and so on). Am i right?

Answer 1

Your assumptions are pretty close to the mark, and Dietrichs answer is fine, but let me go a bit deeper.

In git, branches and tags are structurally irrelevant. They are just little sticky notes ("refs") pointing to some hex hash numbers representing actual commits. Branches regularly move on to new commits (that is their purpose) while tags only change when you force them to, but are never automatically changed. (There are signing tags which are related to trust in large projects - those are completely different but irrelevant for day to day work).

Every commit in git contains the whole file tree and is self sufficient.

The commits span up what we lovingly call the "directed acyclical graph" which is a fancy way of saying that every commit has arbitrarily many parents (1 for a regular commit, 2 for a regular merge, 3+ for octopus merges that nobody of us is likely to ever see in practice) and children.

So. Branches and tags are irrelevant except for convenience because that graph is immutable. Nothing will ever change what you committed, and all commits are very easily displayed in the graph, along with their branches and tags. That is the gigantic difference to subversion, which lets you really relax about these things, in git. It is very hard to lose anything as long as you keep your mind wrapped around the concepts laid down in the previous paragraphs.

TLDR: you can delete your branch and tag and you will still be fine with a quick look-see in gitk or git log --graph --decorate if need be. All git commands take the commit hash names instead of tag/branch names if you accidentally deleted a ref you still needed.

Answer 2

Mostly correct. However, you cannot merge into a tag in Git. In Git, tags are immutable. You will have to create a new tag every time it changes.

Yes, if you delete a branch where the latest commit is tagged, it is very easy to create the branch again.

---

"I decide to develop this feature on feature_branch."

(main_branch) $ git checkout -b feature_branch
(feature_branch) $ ... development ...

"I tag the feature branch and release it to production."

(feature_branch) $ git tag myfeature_v1.0

"I merge the feature branch..."

(feature_branch) $ git checkout main_branch
(main_branch) $ git merge feature_branch
(main_branch) $ ... fix merge ...

"I delete the feature branch..."

(main_branch) $ git branch -d feature_branch

"Oops! I want to create the feature branch again..."

(main_branch) $ git checkout -b feature_branch myfeature_v1.0
(feature_branch) $ ... fix bugs ...