Although the issue is mentioned in #415, I see there are some long developing (log page relative) commits are merged. And still, the git commit history is too complex to read in that situation:
This is not the worst git commit history I have seen, but I think we can do better on this. I can share some of my experience here.
Use SourceTree
I use SourceTree to manage my git repos, it is really nice and handy to use. I really love it. ❤️ I never like hard-to-memorize command line tools and those ugly ASCII log graph. Here is the website
It's free, and even better, it supports both Windows and Mac.
Some daily routines
Always create a new branch on new feature or bugfix
I always create a new branch on new features or bugfixes. Some naming practice could also be used, but so far, this project is not that complex, it won't be necessary.
Next, start working. To submit a commit, just click the commit button and type your commit message
(Tips: you can drag files to add them into the staged list just like git add did)
Then, push to our fork repo
So far so good, we have a nice and clean history with a feature branch
For now, we want to merge it, but we want to keep the branch history, so remember to disable fast forward merge option.
It's time to merge, first, right click one the master branch and click Checkout. You should be at master branch now. Then, right click new-feature branch and click Merge.
Remember to check Commit merged changes immediately to make a new commit directly.
Whoa, here we are, a beautiful linear history still with branch information. The most merging might be done in GitHub, when you click merge pull request it do almost the same.
okay, this is too long, I am going to post the remaining parts in following posts