0

Well as per title, does it matter in any way functionally (say when rewriting history or something), from which branch one derives a new branch?

If at the point of time when creating the new branch all existing (or all relevant) branches have been merged together so they point to the same code?

To explain how this "could" matter:
If I merge branch "feature A" into "dev", and then (accidentally) make a new feature branch "feature B" while in checkout of "feature A" does it make any difference if I would've created it instead from "dev"? And should I undo the branch creation "feature B" and "properly" create it from "dev"? -- There would be no changes to A after the merging.

Improve this question
5
  • 3
    Git branches are just labels that point to some commit. When you create a new branch (add a new label), git doesn't remember the original branch, or if you even started on a branch (tag or detached head). However, it matters from which commit you start and how you later merge the branches. – amon Feb 29 '20 at 7:30
  • @amon while interesting when looking into the details, it still has the similar question: if I merge branch "feature A" into "dev", and then (accidentally) make a new feature branch "feature B" while in checkout of "feature A" does it make any difference if I would've created it instead from "dev"? – paul23 Feb 29 '20 at 7:35
  • 3
    paul23, what @amon told you aren't random details, it's exactly the answer to your question, and it also tells you how to figure out these things on your own. What it means is that it does not make a difference as long as both branches are pointing to the same commit. Git history is just a graph of commits, each of which "links back" to parent commits. A branch is like a pointer, just a simple lightweight object - a label that you can pass to some git commands. – Filip Milovanović Feb 29 '20 at 11:34
  • If you create several branches in a row, they'll all point to the same commit. When you check out any of them, nothing much happens. It's when you make changes and new commits that branches drift apart. You can explore things in a visual way here (freeform - so you can try your scenario yourself) and here (a guided tutorial). – Filip Milovanović Feb 29 '20 at 11:34
  • @FilipMilovanović yes but does a "merge" then actually merge the data in such a way there's a single pointer to that "position". Or does it merely copy all data so that each head of a branch has a separate "label/pointer" that is just equivalent? – paul23 Mar 1 '20 at 20:43
2

Yes. Your understanding is correct. But it depends on the commit ids as well. If the code has been copy-pasted to multiple branches it will be different commit ids. If there are three branches master, dev & feature. If the feature is merged to dev & dev to master then all the commits should be in sync, making it possible to create a branch from any of these branches.

Improve this answer
0

If you branched dev -> A, and for a second task you need what you did in A before it is merged then you branch A -> B, and if you need your work in B before it is merged then you branch B -> C.

Just make sure that a reviewer reviews in the order A, B, C because branch C obviously contains all the changes. When you create the third pull request, it contains all the changes but gets automatically amended when A and B are merged.

Improve this answer
0

I always work better with concrete names, so I will make up a few branches. Let's say you are building a blog web application. What you call "featurea" I will call "blog_posts". What you call "featureb" I will call "comments".

I'm going to assume the git commands that were executed were roughly:

git checkout dev
git merge blog_posts
git checkout blog_posts
git checkout -b comments

As of merging blog_posts into dev you could potentially create a merge commit in dev that does not exist in blog_posts if you have not merged the latest from dev into blog_posts. Upon creating the comments branch it will point to the tip of blog_posts, which would not contain the merge commit. So yes, it does matter which branch you create the new branch from, however...

Don't worry too much about this. If you created the comments branch from blog_posts and meant to create it from dev, merging dev into the comments branch results in a fast forward merge if no commits were added to the comments branch.

If you added commits to the comments branch you can just merge dev into comments and move on with your life. If the comments branch has not been pushed yet, rebasing this branch on dev will rewrite the history of the comments branch to look as though it had been created from dev in the first place.

Even though it does matter which branch you create a new branch from, git allows you make corrections to the history of the branch prior to pushing it. Don't sweat this decision too much given the situation you described. The two branches don't seem like they have diverged that much, so the risk of totally screwing up the code base is minimal.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.