1

A large number of branches makes the commit history a bit difficult to understand.

What is the best procedure to committing so that a look at git commit history tells the most about the dev process?

fullmastbby
  • 19
  • 3
  • 3
    That's kind of like asking whether you can take a complicated 3D image and view it in 2D and see everything. It's never going to work completely. Your subject line and text body seem to disagree as well: the text suggests you know about this problem and are looking for ways to build your 3D object so that it's understandable in 2D, while your subject line is concentrating on making the 2D drawing of some arbitrary uncontrolled 3D object... – torek Jul 15 '16 at 02:05
  • Yeah. I can understand why it must be impossible to do so. I was wondering if I was ignorant about some way to do it perfectly (if it exists). What I expect to learn is a good way to write and manage branches and commits to that I can strive for cleaner and clearer commit history, even though it may not be perfect. – fullmastbby Jul 15 '16 at 02:08
  • You may want to look at http://stackoverflow.com/questions/18188492/what-are-the-pros-and-cons-of-git-flow-vs-github-flow and the git-flow tag. – torek Jul 15 '16 at 02:12
  • If you want a linear commit history, your team could adopt `integration-manager workflow` as described in *Pro Git - Distributed Git*, and use `git rebase` and `git cherry-pick` instead of `git merge`. – ElpieKay Jul 15 '16 at 02:43

2 Answers2

0

Please try git log --first-parent. You can look this page for more details.

gzh
  • 3,507
  • 2
  • 19
  • 23
0

In my opinion, it is good to "rebase" in order to make the history cleaner to understand. Here's is more information about how rebase works.

git rebase basics

Community
  • 1
  • 1