Understanding Git's "Staging Area" concept and how it's implemented in Tower will help you create better commits.
The "Staging Area"
In Git, just because a file was modified doesn't mean it will be automatically included in the next commit. Instead, you have to tell Git explicitly which of your modifications shall be part of the next commit. This is done by adding a change to the Staging Area or, put simply, by "staging" it.
A change can be as granular as a single changed line in a file, leading to very precise commits. If, after staging a change, you decide you don't want that change to go into the next commit, you can also "unstage" it, again.
Staging Changes in Tower
You can quickly determine if a file is staged or not by looking at the Status column: A checked box means that all changes in the file are staged. A square in the box means that some changes in the file are staged while some are unstaged. An unchecked box means that the file is completely unstaged and will not go into the next commit.
The Status column indicates both the staging status and the type of change. An icon on the left half of the column indicates staged changes while an icon on the right stands for unstaged changes. The icons symbolize: modified (M), added (A), untracked (?), deleted (D), renamed (R), and copied (C).
Staging All Modifications in a File
In most cases, you'll want to add all changes in a file to the Staging Area. This can be done by clicking the checkbox in the Status column of the file list.
If you quickly want to stage all files at once you can do so by clicking the button.
Staging Parts of a File
In case you only want to stage some of the modifications in a file, you can do so in the Diff view on the right.
Click thebutton to add this complete block of changes to the Staging Area.
Alternatively, you can even select individual lines (by clicking on their line numbers). The "Stage Chunk" button then turns into thebutton and allows you to stage just the selected lines.