Git Series. Episode 1

Distributed VCS. Good Commits

Mikhail Melnik, 2015

Distributed VCSIn a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don’t just check out the latest snapshot of the files: they fully mirror the repository.If any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it.Every checkout is really a full backup of all the data.

In distributed VCS almost every operation is local!

Why Git?● Speed● Simple design● Fully distributed● Strong support for non-linear development

(thousands of parallel branches)● Able to handle large projects like the Linux

kernel efficiently (speed and data size)

Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. It’s incredibly fast, it’s very efficient with large projects, and it has an incredible branching system for non-linear development.

Important Statements● When you clone repository you get it’s full copy.

● Git repository represents a directed graph of commits.

● Every commit has link to its parent.

● Branch/Tag are only a link to the certain commit.

● Any certain commit lives until exists at least one branch or tag that points to it.

● Git has a garbage collector that cleans up repository from unreferenced data.

Git Keeps the Snapshots

Snapshot, Tree and Blob

Commits Chain

The Three States

Commit

Commit in Git is generally made locallyusing the following commands:

git add readme.txtgit commit

Firstly you add some files to the Staging Areaand after that make a commit from all staged files.

Commit

To change commit that was already made,use console command:git commit --amend

Using it you can add new files to previously created commitor change it’s message.

Note, that it is really bad ideato change commits that were already published.

CommitHere are a commit message recommendations from the ProGit book:

Capitalized, short (50 chars or less) summary

More detailed explanatory text, if necessary. Wrap it to about 72characters or so. In some contexts, the first line is treated as thesubject of an email and the rest of the text as the body. The blankline separating the summary from the body is critical (unless you omitthe body entirely); tools like rebase can get confused if you run thetwo together.

Write your commit message in the imperative: "Fix bug" and not "Fixed bug"or "Fixes bug." This convention matches up with commit messages generatedby commands like git merge and git revert.

Further paragraphs come after blank lines.

- Bullet points are okay, too

- Typically a hyphen or asterisk is used for the bullet, followed by a single space, with blank lines in between, but conventions vary here

- Use a hanging indent

Short commit name. Think of it as of email subject. Must be strictly followed by empty line.

And here is where the email body with detailed description is started.

Separate paragraphs with blank lines.

Use bullet lists if you need them.

Commit Summary● Commits should be atomic.● Commits should include only working code.● Commit messages should be descriptive.● Use multiline commit messages. First line of such message is a short task description.● Commit message also may include number from issue tracker if you use it.● Use the imperative present tense in your commit messages.

(“Add tests for” instead of “I added tests for” or “Adding tests for”, etc).● Do not commit anything that can be recreated from sources.● Do not commit configuration files that depend on environment.● Do not commit large binary files.● Do adding new or deleting/moving/renaming old files in separate commit.

Commit Summary

STORY-2015 Create Users page. Refactor UserService.

- simplify hardToUnderstandFoo() - rename badNameFoo() -> goodNameFoo() - extract someName class field - remove duplicated stateField clean code from foo1() private method. It was triggered twice from foo1() and its parent method. - remove oldMethod() because of 0 usages.

STORY-2015 Create Users page. Add getUsers() in UserService.

- add GET_ALL_USERS query to User entity

- add getUsers() method in UserDao

- add getUsers() method in UserService

1. Short commit name. You can mention issue number here and small description.

2. Put the empty line immediately after commit name.

3. Itemize your changes in a bullet list manner. Use imperative tense.

4. Additionally you may describe your motivation here, why this or that code change were made and also the previous behavior.

I strongly recommend to use commit messages like these:

Commits that were good receive presents from Santa!

LinksCore Git sources:

1. Pro Git book2. Git reference3. Git magic

Step-by-step tutorials:1. Nice online Git tutorial2. Become a Git guru

Additional links:1. Git concepts simplified

Feel free to mail me at mikhailimelnik@gmail.com.

Specific topics:1. Git best practices2. Atomic commit convention3. Blob and tree experiment posts4. Note about commit messages