----- 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 

  Some project team don't care how to use git not only for commit but 

  They commit something as new one every time.

  But git history become complex and it's not understandable when checked git 
  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.


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.

Reply via email to