This is our GIT extensions tutorial for beginners. Here’s what you are going to learn:
GIT Extensions is a distributed version control system enabling a user to robustly manage a collection of source files and the changes made in them. The changes made are shown in the History of changes. Users can make changes by accessing a Central repository called remote repository and committing the changes to it. It implements classic GIT by using GUI (Graphical user interface), basically driven by a set of dedicated commands, hence maintaining the version control system intuitively. So, let us go through a glimpse of functionalities provided by GIT Extensions so that our version control system can be maintained.
There are many options to manage the repository through GIT Extensions. It includes viewing the committed logs and changes made in comparison to the previous commit, cloning a repository, traversing through the file directory and filtering the committed logs by using custom search input, etc.
GIT Extensions can be downloaded from https://github.com/gitextensions/gitextensions/releases/tag/v2.48.05
SSH Keys should be loaded as a one-time activity. SSH keys can be generated while setting up the GIT Extensions.
In order to use a safe development environment with SSH, you need to get PuTTY installed as a preferred SSH client. PuTTY can be downloaded from http://www.putty.org/
The first thing is to check that Git Extensions is properly configured to use PuTTY, as well as all paths, are given correctly.
In the Remotes Tab just choose Generate or import key to start the key generator.
It will ask you to move around the mouse in order to generate more random keys. When the key gets generated, save the public and private key in a text file by clicking the Save Public key button.
Since now you are having a key pair, provide the public key to the Github account by copying the Key from the file which you just saved above at your desired location.
Then open your Github account and click on the profile image, followed by Account settings and going to the SSH Keys tab. Finally, paste the public key over there.
You can create a Github account at https://github.com/join?source=header
Now GitHub will get to know which public key it has to use to decrypt. Now you also need to provide the private key to GitExtensions to encrypt. You will find a Load SSH key button in the clone dialog where you can load the private key in PuTTY authentication.
Note: This is a one-time activity and you don’t need to repeat these steps again.
Cloning a repository will create a local copy of the repository being cloned by this action.
It’s possible that the repository you want to clone is located on a network share or is accessible via an internet or intranet connection. You may need to load an SSH key into PuTTY depending on the protocol (http or ssh). You must also indicate the location of the cloned repository and the branch that will be checked out first. If the cloned repository has submodules, they can be initialized with their default values if necessary.
When making a clone, you can create two different sorts of repositories. A personal repository stores all of the histories as well as a functioning copy of the source tree. A central (bare) repository serves as a public repository to which developers push updates that they want to share with others. A central repository holds the entire history but does not have a working directory, unlike personal repositories.
Note: A Red Cross mark with respective errors will be displayed too during the occurrence of errors in the process if any.
You’ll likely get some issues when cloning a repository. If you’re having trouble cloning a repository, make sure:
From the Common Actions section at the left click the ‘Open Repository’ link and give the directory address for opening a repository. Then click the ‘Open’ button as highlighted in the figure.
It opens the repository and all committed logs will be shown with an abstract message associated with them, committed user, and the time elapsed when the commit was done (Refer figure). Also, the details like Author, date are shown at the bottom in the commit section.
Initially click the ‘File Tree’ tab. It will show the whole repository in the form of a file tree and intended files and directories can be viewed easily. This is the step-wise procedure to traverse a repository by a user.
Let’s have a peek at the source code.
#include <git2.h>
This header file must be included in any program that uses libgit2.
The first step is to use git libgit2 init to get libgit2 and its resources up
int main(int argc, char * argv[]) { git_libgit2_init(); const char * REPO_PATH = "/path/to/your/repo/"; git_repository * repo = nullptr; git_repository_open(&repo, REPO_PATH);
You open a repository with git repository open, which creates an object that you may use in your code to interact with a repository.
git_revwalk * walker = nullptr; git_revwalk_new(&walker, repo);
The next step is to develop a revision walker, which is an object that iterates over a git repository. The git revwalk new function handles this.
git_revwalk_sorting(walker, GIT_SORT_NONE);
Once we’ve created a revision walker, we’ll need to provide a few parameters to manage the traverse. One example is the sorting mode when iterating over the repository. This is accomplished by invoking git_revwalk_sorting with one of the following values as the second parameter:
GIT SORT NONE – the default reverse chronological order (beginning with the most recent) of commits as in git
GIT SORT NONE – the default reverse chronological order (beginning with the most recent) of commits as in git
GIT SORT TIME – order of commit timestamps
GIT SORT REVERSE – performs commits in reverse order.
An OR can also be used to combine topological and temporal ordering.
It’s worth noting that you don’t need to use this function to set GIT_SORT_NONE because that’s the default setting.
git_revwalk_push_head(walker);
We are now ready to begin the traversal after the setup stage. This is accomplished by the method git revwalk next, which obtains the ID of the next commit to visit.
Calling git_revwalk_push_head changes the root to the HEAD of the repository.
git_oid oid; while(!git_revwalk_next(&oid, walker)) {
Once we have used the commit, it’s time to release the object calling git_commit_free.
git_revwalk_free(walker); git_repository_free(repo);
We are now ready to begin the traversal after the setup stage. This is accomplished by the method git_revwalk_next, which obtains the ID of the next commit to visit.
git_commit * commit = nullptr; git_commit_lookup(&commit, repo, &oid);
Once we have an ID, we can use git commit lookup to retrieve a git commit object. This object will be used to retrieve information about the commit.
std::cout << git_oid_tostr_s(&oid) << " " << git_commit_summary(commit) << std::endl;
This is where we collect the necessary information from the ID and the commit.
After we’ve utilized the commit, we’ll call git_commit_free to release the object.
git_revwalk_free(walker); git_repository_free(repo);
We can extract the hash of the commit from the ID using git_oid_tostr_s and the short summary of the commit using
git_commit_summary. git_commit_free(commit); }
Then we may call git_revwalk_free to free the revision walker and git_repository_free to free the repository.
git_revwalk_free(walker); git_repository_free(repo); git_libgit2_shutdown(); return 0; }
Finally, we shut down libgit2 with git_libgit2_shutdown.
By clicking the ‘Diff’ tab comparison can be made with respect to the previous commit as shown in the figure.
Press Ctrl+click commits to see all changes between them in the Git Extensions GUI. Because the first pick is handled as the base, choose an older commit first to show the change direction in diff view (additions/deletions) appropriately.
AFAIK, Git Extensions does not offer a GUI option to send a directory diff to an external tool (just file by file); therefore, you must do it from Git shell to obtain all changes at once to Beyond Compare (assuming you have configured it as a diff tool for Git).
git difftool -d <commit1> <commit2>
If you want to compare your current checked-out version to <commit1>, omit <commit2>. For instance, if you are on your local master and use fetch rather than pull
git difftool -d origin/master
will display the modifications that will be made when your local branch is merged with the origin branch.
Note: Newly added lines are marked as ’+’sign and shown with green color and the deleted ones as ’-’ sign and presented with red color.
This action of committing and then pushing the given code to a remote repository is divided into two operations:
This process of committing involves various steps:
Icon | Meaning |
This represents all existing files that were edited after the last commit | |
This represents files that are removed after the last commit | |
This represents new files that are added after the last commit |
Note: Clicking ‘Commit’ lets the files be committed into the local repository and not into the remote repository.
‘Push’ action is used to move the files of the local repository into a remote repository. It needs to be ensured by the user that the code which was taken lastly from the remote repository is not modified before you perform push action. There is every possibility that a repository could have been modified when it has been pulled or cloned by another person. This generally happens in a multi-user environment where a lot of branching and merging happens. Hence, it is necessary for a user to perform a Pull before opting for a Pushing action for the committed code.
As of now, the local repository and the remote repository are in sync, so the user now has to click the ‘Push’ button as shown in the figure so that all the locally committed changes can be pushed to the remote repository.
We hope that this tutorial helps you in getting familiarized with the use of Git using the tool Git Extensions.