Thanks Philip for your kind explanation.
I got it completely.
I do it depending on projects situation flexibly.
2016年4月25日月曜日 21時14分59秒 UTC+9 Philip Oakley:
>
> ----- Original Message -----
>
> *From:* hiroki yasui <javascript:>
> Hello guys,
>
> I've experienced some projects to develop application which use git.
> Each of projects has more or less different way how to operate git.
> However I'm confusing how often commit to branch and what is best unit of
> commit?
>
> Some project team don't care how to use git not only for commit but
> everything.
>
> They commit something as new one every time.
>
> But git history become complex and it's not understandable when checked
> git log.
> I think trivial commits message is not necessary.
>
> In one of open-source projects as my past experience, there was rule that
> basically one feature is one commit.
> If something modification is required after source code review by team
> reader, I don't do added commit. I redo as same commit to use reset.
> ```
> git reset --soft HEAD~
> git commit -am "same message"
> git push xxxx xxxxxx
> ```
>
> I know, it's troublesome, that's why I'm using alias as below.
> ```
> $ git config --global alias.recm '!f(){ cmt=$(git log -n 1
> --pretty=format:%s);git reset --soft HEAD~;git commit -am "${cmt}";};f'
> $ git recm
> ```
>
> Sorry, I digressed.
>
> My question is what is best practice of commit.
>
> Hi Hiroki,
> While it is normal to commit small changes often within Git, one
> un-mentioned area is how the Git server system is set up and administered.
>
> If we first remember that Git is a DVCS so, at one level, the [total]
> control has been distributed to you (yeah). This means that you should be
> able to (locally) make as much mess as you like with personal commits. As
> long as the mess is private no one should care...
>
> At the other side of fence is how the 'blessed' usptream respository is
> managed, and what layers are between you and it. How these are controlled
> can have a significant impact on what workflow is used.
>
> You mention the potential for a confused or complex history, however Git
> already has multiple histories because of the distributed nature. In a good
> environment the history quality would steadily improve as you move further
> usptream and toward production status.
>
> Have a look at the difference between the workflows and also the server
> support (levels of repos and control) to work out what is best for you.
> This will also depend on the size of the team and scale of the product.
>
> --
> Philip
>
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
