Git and license # and changelog

I’m new to git. It looks great and I think I get the general process of making commits and adding tags for version numbers.

My questions are:

  1. Do you make a commit every time you want to ‘save’ your work but only add a tag when you want to change the version number?
  2. Can you insert a version number automatically based on a tag? E.g. get git to find and replace {VERSION} with 1.6.14
  3. I can see the gitlog command can be used to generate a changelog. On github people tend to have a CHANGELOG.md or README.md file that is converted to HTML on their github page. Is the MD file something you create or github creates? Should your local README/CHANGELOG be .md format or something else?

Thanks.

  1. I tend to make multiple commits for each little part of things I save – you can do loads of neat things combining small commits but parsing out large ones is a *****.
  2. Yes but that is a job for a build server. A better approach is to let the build server “own” the tag and insert it in the right places. I’ll note I very, very rarely use tags these days – and when I do it is for one-off communication. Continuious deployment FTW.
  3. Typically you want the changelog to be a bit more human understandable than a raw commit log – oftentimes you’ll have a number of commits changing things back and forth in order to figure something out or fix a bug.

@DrQuincy;

The general approach is to make your commits ‘atomic’. That is very subjective (differs for each person) but - particularly if you are working as part of a group - you should remain conscious of how the git history will read (the results of a git log command). Depending upon the project, I often make commits at the end of a ‘working session’. If those changes represent a little work on several features (or issues) I will use the -i flag to selectively break up my changes in to several commits.

The tag in git is really just a different way to reference a commit. It is nothing more than a label.

The accepted SOP on Github is to provide a README file for your project. The Markdown language is extremely popular - and Github even has their own ‘flavor’ - and that is how the README.md file can display in a formatted (HTML) manner.
The same format is used in Github Gists.

If you are new to git and have a Github account don’t miss out the great “add-on” capabilities you get with your Github account:

  • An unlimited number of Gists that can be Public or Private (realizing “Private” just means they will not show up in SERPs, but you can share the URL with anyone)
  • Github Pages to “host” a website about each project
  • Wiki for each Repository
  • Issues tracking for each Repository
  • Enormous amount of Help Resources related to git and to Github

One other thing – you might want to check out bitbucket. It has a little less cache than github but a few more features (mercurial) and a better model with unlimited free private repos.