Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Git Commit Review - Project: Radium-218

  • You cannot reply to this topic
2 replies to this topic

#1 BinaryPhysics   Members   -  Reputation: 294

Like
0Likes
Like

Posted 29 September 2013 - 03:57 PM

I was wondering if anyone would be able to give me a hand with my general commit messages in Git.

 

Specifically, my project's history is here: https://github.com/MiniAl/Radium-218/commits/development/.

 

My question is basically: What kind of quality would you rate these messages?

 

General goals and thoughts when I write commits:

  • Explain what changed (as a brief overview), explain why it changed, and finally explain how this might affect the project in the near future;
  • Attempt to make commits minimal and focused ('git add -u -p'); and
  • Write messages in Markdown (http://daringfireball.net/projects/markdown/) to provide a structured way of providing links and emphasis without bloat.

I was hoping someone could take a brief outside look at let me know if I'm actually achieving these goals or if there's something huge that I should be doing and are not.

 

Brutal, constructive criticism is welcome. smile.png.



Sponsor:

#2 jotak   Members   -  Reputation: 156

Like
0Likes
Like

Posted 03 October 2013 - 11:41 AM

Hello,

 

The "why it changed" is fine considering this commit is not responding to an opened, reported issue. But I would say ideally the issues should be reported first (github provides an issue system), and then a link to the issue in the commit message would simply answer to the "why" part.

 

Also, you could also write more in-code comments. Commit messages are only read when the commit is submitted, and then forgotten (except searching in the git history, which can be a pain after hundreds of commits), whereas code comments will still be read on further developments.



#3 AllEightUp   Moderators   -  Reputation: 4240

Like
0Likes
Like

Posted 06 October 2013 - 02:41 AM

I apologize for coming into this late but wanted to expand on this subject considerably. In general, the messages you use are perfectly fine from what I could see, your use of git in it's intended form is crippled by worrying about this though. I don't mean to be offensive, I just mean to point out an alternative which makes worrying about the individual messages less important except at the points it actually matters. What I'm talking about is specifically codified with the GitFlow scripts, which is actually very close to what I have used with other items such as Perforce and SVN for many years.

Look at the purpose of revision control in general. It actually has 3 primary goals:

1. The individual user wants basically an undo system along with the history. As you work as an individual, things compile but don't actually work yet, you might check that in just as a "compiled at this time" mark. The message doesn't matter to anyone else, only that you decided you needed a point of reference for what you were doing next. You keep working and find that you went down the wrong path, a quick revert to the check point and you can start over. This is the user personal level. Obviously if this is done in the main/dev branches folks will flay you alive. Hence, GitFlow 'Feature' branches. (Or personal branches in other revision control systems.)

2. The always almost always working, though potentially buggy, development branch. This is where #1 integrates with the "team" nature and how GitFlow and branching in other RCS systems have done things successfully. The individuals do everything in a personal branch, GitFlow calls them "feature" branches, and you only write the fancy messages describing what you have done in detail during the merge of the personal branch into the development branch. These are the messages which need to make sense, the merges. Obviously your history in the personal branch is important (and yes it is tracked even if you kill the branch and start a new one) for tracking why some bug may have shown up.

3. The "release" branch. (GitFlow I believe says this is the master branch to follow Git conventions.) The intention is obvious I hope, but the utility is underrated. Say you release 2.8.7 of your software (i.e. check into the release branch, build and deploy) and your devs (you perhaps) are all busy on 2.9 when a bug is reported on 2.8.7 which simply has to be fixed immediately. With the branches, you simply check out the release version, fix the bug and check it in as release 2.8.7.1 as a hot fix. If you need to apply the fix back down to current work, that is simple using the cherry picking system in Git though a bit more complicated in other revision control systems.

This is basically an overview of GitFlow which is pretty much a formalization of how many AAA game shops work in one way or another. It applies to all RCS usages in reality, just some are more painful than others to setup.





PARTNERS