Milan
Milan

Reputation: 1740

Managing Git branches and subbranches?

I am trying to figure out how to manage Git branches so I have a correct and readable flow for my development process.

Basically, we have a master branch, a project branch, then we can start to develop features under this project branch. I would like to be able to make subbranches too.

Say I would have master - > project -> feature 1 -> feature 1 sub 1 ...

What I would get in Hg would look like this:

https://i.sstatic.net/lAz5c.png

What I actually get under git is this:

https://i.sstatic.net/y6mmx.png

Basically, the whole development flow is lost, and in 1 year there will be no way to know that "Interface refactoring" was related and a sub part of "Duplication of speed model".

Moreover, I am avoiding fast forward merges because it just lost track of all history, but still, in a few months even I won't be able to tell that "Update necessary setExecutionMode" was done under "InterfaceRefactoring" and not "Duplication of ..."

I am seriously considering going back to Hg and using a plugin to make a bridge between Hg and Git, because Git is so incredibly NOT user friendly, but I also badly want to use the company tool as it is still a modern and efficient SCM (not like SVN or CVS).

I still think that I could get what I want, I just don't understand how.
What am I doing wrong?

Upvotes: 3

Views: 242

Answers (3)

max630
max630

Reputation: 9238

Also, since you anyway use the non-fastforward merges, it is possible to request which commits have contributed to the merge with command

git log *mergehash*~1..*mergehash*

this range query also can be various UIs, for example gitk (in view definition) and GitExtentions (in branch selector)

Upvotes: 0

max630
max630

Reputation: 9238

Mercurial branches are strings attached to commits. Git commits do not have such dedicated strings, but you could put a keyword to the subject:

  • EDF merge speed duplication
  • DSPEED stuff
  • REFACTOR_INTERFACE stuff

Some put there a number from bugtracker

Upvotes: 1

Kevin
Kevin

Reputation: 30151

Git doesn't have what Mercurial calls "named branches." Instead, what Git calls "branches" are very similar to what Mercurial calls bookmarks. There are a few differences:

  • In Git, every head must have a branch pointer or it is considered semi-nonexistent (a "detached HEAD") and may be garbage collected after a while. Such heads will not appear in the repository history, but can be retrieved from the reflog. This contrasts with Mercurial, where bookmarks are entirely optional.
  • Git maintains "remote branches" all the time, while Mercurial only does this when the local and remote bookmarks diverge (you get a "divergent bookmarks" warning and a bookmark with a name like foo@default is added to the repository). This means that Git's local branches must be manually fast-forwarded after a pull, while Mercurial fast-forwards local bookmarks automatically on pull.
  • In Mercurial, @ is a special bookmark which may or may not exist. If it does, cloning checks it out by default. It can be used as a pointer to the trunk (default branch), though that is not its only use. In Git, @ is shorthand for the current commit, and the "main" branch is instead called master.

If you need Mercurial-like branches, you should use Mercurial instead of Git.

Upvotes: 1

Related Questions