----- Original Message -----
From: hiroki yasui
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.
