GIT Staging view

Git Staging view contains a toolbar, 5 fields, and 2 buttons:

Unstaged Changes ↓	holds changes which have not been added to the GIT index yet
Staged Changes ↓	holds changes which have already been added to the GIT index
Commit message ↓	holds the committer's messages regarding the committed changes
Author ↓	displays the name and the email of the project author
Committer ↓	displays the name and the email of the committer
Commit and Push	commits the changes to the local repository and pushes them to the remote one (launches two separate actions sequentially - Commit and Push)
Commit	commits the changes to the local repository (without pushing them to the remote one)

GIT Staging toolbar

GIT Staging toolbar includes buttons used for managing the GIT Staging view:

Filter files allows filtering the content of the GIT Staging view by the specified parameter:

Refresh triggers an immediate refresh of the view.

Link with Editor and Selection – when enabled, creates a link between the Project Explorer, the GIT Repositories view, and the active editor.

Compare Mode – if enabled, allows opening a compare editor for the selected file:

If disabled, the selected file will open in the code editor:

View menu opens the drop-down menu ↓ :

Minimize minimizes the GIT Staging view.

Maximize maximizes the GIT Staging view.

The drop-down menu of the GIT Staging view allows performing the following actions:

Presentation allows selecting how the changes (both staged and unstaged) are grouped:

with List, all files are given in one list in an alphabetical order (and each item of this list is called by not the file name alone but its relative path):
with Tree, all files are grouped by projects and folders (folders, projects, and files are given by their names):
with Compact Tree, all files are grouped by projects (files are given by their names, projects are given by their relative paths):

Open New Commits – if enabled, opens the new commit (the latest you have made) to the code editor:

Column Layout changes the mutual layout of Unstaged changes and Staged changes from the default (row ↑ ) to the column one:

Show File Names First – when changes are presented as a list ↑ , displays the file names separate from their paths:

Compare Mode – if enabled, allows opening a compare editor for the selected file.

Unstaged changes

Unstaged changes field holds the changes which have not been added to the GIT index yet:

From the Unstaged changes toolbar, you can perform such actions:

Sort by State

allows sorting the unstaged changes by the state (e.g. tracked, untracked, ignored, etc. → )

Expand All

allows expanding all the projects and folders added to the Unstaged changes

(is available when changes are presented as a tree ↑ or a compact tree ↑

is not available when changes are presented as a list ↑)

Collapse All

allows collapsing all the projects and folders added to the Unstaged changes

(is available when changes are presented as a tree ↑ or a compact tree ↑

is not available when changes are presented as a list ↑)

From the Unstaged changes context menu, you can perform such actions for selected files and folders (the number of available actions can vary):

Open Working Tree Version opens the current version of the selected file in the editor associated with this types of files (e.g., .4gl files are opened in the code editor, and .qxtheme files are opened in Lycia Theme Designer):

You can open the working tree version of the file by double-clicking it.

Compare with Index opens the selected file in the compare editor so that you can compare its versions - the one you want to commit and the one already existing in your GIT repository:

Add to Index adds the selected files to the GIT index (only those files are committed which were added to the Index):

You can add file to the GIT index by dragging them from the Unstaged Changes and dropping to the Staged changes..

Ignore adds the folder or file to the list of resources which are ignored (not tracked) by the GIT team provider:

We recommend adding the project output to the Ignore list so that it won't be committed.

Delete deletes the file from the file system.

Show In allows opening the selected file in the file system or viewing its properties:

Staged changes

Staged changes field holds the changes which have been already added to the GIT index:

From the Staged changes toolbar, you can perform such actions:

Expand All

allows expanding all the projects and folders added to the Unstaged changes

(is available when changes are presented as a tree ↑ or a compact tree ↑

is not available when changes are presented as a list ↑)

Collapse All

allows collapsing all the projects and folders added to the Unstaged changes

(is available when changes are presented as a tree ↑ or a compact tree ↑

is not available when changes are presented as a list ↑)

From the Staged changes context menu, you can perform such actions for selected files and folders (the number of available actions can vary):

Open Working Tree Version opens the current version of the selected file in the editor associated with this types of files (e.g., .4gl files are opened in the code editor, and .qxtheme files are opened in Lycia Theme Designer) - the same as in Unstaged changes↑.

Compare with Working Tree opens the selected file in the compare editor so that you can compare its versions - the one you want to commit and the one already existing in your GIT repository:

Remove from Index removes the selected file or folder from the GIT index and sends it back the Unstaged changes:

You can remove file from the GIT index by dragging them from the Staged Changes and dropping to the Unstaged changes.

Show In allows viewing the properties of the selected file or folder:

Partial staging

Sometimes it is useful to commit only some changes to the files.

To perform partial staging, you

move the necessary file to the Staged changes,
open it in the compare editor,
change the index (staged) version of the necessary file,
save these changes and commit them.

Commit message

Commit message field holds the committer's messages regarding the committed changes:

Preferably, commits have to consist of two parts: a short "title" part in the first line which briefly summarizes the commit and the message body which provides all the necessary details. These two parts must be separated with a blank line.

From the Commit message toolbar, you can perform such actions:

Amend

amends the previous commit.

To amend a commit means to change (correct it). Amending are useful when you want to correct an insignificant mistake in both your project and the commit message and at the same time do not want your repository to be crowded with such tiny correction. After amending, your previous commit will be overwritten (replaced) with a new one.

However, you have to be careful when amending if your are a part of the developing team and have already published your changes to a remote repository: Your commit may be cloned and come into your colleagues' hands before you amend it, and this can cause trouble. If this case it is better to publish a new commit but amend the previous one (or inform other team members about yours amends).

Add signed-off by

adds the Signed-off-by template to the commit message:

Add change-Id

add the id of the current change:

From the Commit message context menu, you can perform all basic actions associated with text editing:

Author and Committer

Author and Committer fields display names and emails of the GIT repository author and the committer to it:

These names are necessary to trace any commits to their authors:

Thus, they must be specified for every working station before setting down to work with GIT repositories. Refer here to learn how to set user names on a working station.

Author's and committer's name and email can be typed in the corresponding field: