git branch off of another branch [closed]

Question

Closed. This question needs details or clarity. It is not currently accepting answers.

---

Want to improve this question? Add details and clarify the problem by editing this post.

Closed 9 years ago.

Improve this question

Hi I have two branches in parallel 'dev' and 'prod' I would like to add another local branch to the local dev branch called 'issue22' (GitPro refers to this as a topic branch - others call it a feature branch). So at the terminal I created my feature/topic branch with

git checkout -b issue22 dev

Which I thought would do 'make a branch called issue22' and start with the same source code that is in the dev branch. I am expecting to see

prod
dev
dev/issue22

However when I send the command git branch -a

Instead, I see

prod
dev
issue22
remotes/origin/head -> origin/master
remotes/origin/dev
remotes/origin/prod

What command should I use to create a new branch so that 'issue22' appears to look like a topic/feature branch that runs in parallel to the 'dev' branch and also appears to stem from the dev branch?

many thanks

Answer 1

The parental relationship between commits is what gives a repository its "structure". And a visualization like the one displayed on the Git Flow website is definitely possible with Git. It was designed around Git!

Here is an example that should get you started:

1. First, create a new repository and add a single empty commit:

   $ mkdir test-repo && cd test-repo
   $ git init
   $ git commit --allow-empty -m "Initial empty commit"
   

   At this point you've got one branch and one commit. Your network will look something like

   [master]  A
   

   Here, A represents the blue dot at the extreme top-right corner of the Git-Flow site.

2. This commit is missing its tag from the diagram. Let's add it:

   $ git tag -a 0.1
   

   Now we've got

   [master] [0.1]  A
   

3. Now we'll create our develop branch:

   $ git checkout -b develop
   

   At this point, we haven't added any commits to develop that aren't in master, so the branches are pointing to the exact same commit:

   [master] [develop] [0.1]  A
   

4. It's getting a bit crowded here. Let's add a few more commits to develop:

   $ # Hack, hack, hack...
   $ git add somefile.txt otherfile.dat
   $ git commit
   $ # Hack, hack, hack...
   $ git add foo.bar
   $ git commit
   

   Now our network is a little bit more interesting. When we created each of these two new commits, our develop branch was updated to point to each of them in turn. Now we've got

   [master] [0.1]  A
                    \
   [develop]         B---C
   

   develop actually points to commit C at this point, and we can trace C's ancestry back to commit A.

5. We can do the same thing with a new branch issue22, though it won't be named develop/issue22 unless we explicitly call it that:

   $ git checkout -b issue22
   $ # Hack, hack, hack...
   $ git add foo.bar
   $ git commit
   

   and now we've got

   [master] [0.1]  A
                    \
   [develop]         B---C
                          \
   [issue22]               D
   

   issue22 branches off of develop by virtue of D's parent being C. We can do some more work on both develop and issue22

   [master] [0.1]  A
                    \
   [develop]         B---C---F---G
                          \
   [issue22]               D---E---H
   

   without changing that relationship. Then we can merge issue22 back into develop (or directly into master, though that's not the "Git-FLow way") and get something like

   [master] [0.1]  A
                    \
   [develop]         B---C---F---G---I
                          \         /
   [issue22]               D---E---H
   

This model extends to as many branches as you'd like, and with a little care you could exactly reproduce the Git-Flow diagram. Branches don't "diverge" until they contain different commits.

It might be helpful for you to understand a little bit about Git's internal workings. The website Think like (a) Git is a very good introduction.