Developer Working methodology¶

1. Cloning the forked repository
2. Working locally and pushing to the forked repository
3: Importing an external team repository

Note

This section targets mainly project developers

1. Cloning the forked repository ¶

This section presents the process of cloning a forked repository locally which will allow development work to start.

The process is illustrated using the EGit Eclipse plugin.

Tip

There are many GIT GUI clients, the most popular being GIT Kraken which has support for Mac, Windows and Linux.

GIT Kraken client was presented in the previous document, and is highly recommended since it adds a GitLab integration to manage different elements.

When using Eclipse the Egit is not always displayed and can be accessed by right-click > “Show in” > “Git Repositories” as shown below:

Figure 60 EGit display menu

The EGit menu can be usually found at the bottom left of the Eclipse window:

Figure 61 EGit Interface

First copy the repository URI from personal GitLab page by clicking on the project icon:

Figure 62 Main GitLab interface

In Eclipse select “Clone a Git repository”. The following menu will appear asking for an URI as copied above.

Figure 63 EGit Clone menu

EGit will complete the Host, Repository path, User and Passwords fields. The result should be as shown in Figure 63 above.

The communication protocol should be set to SSH.

A message indicating that the host authenticity can’t be established will appear, select “Yes” to indicate it is a trusted connection:

Figure 64 Host authenticity warning

If a passphrase was added when the SSH key was created, a new popup will appear asking for this value. Note: this is not the git login password but the passphrase for SSH (see SSH Key creation)

Figure 65 SSH Key passphrase popup

The next window will ask you to indicate which branches will need to be cloned. Since we are working on a forked repository, we will only clone the AP242 (in this case) branch. This is where all the commits and modifications should be posted to work internally (in the forked repository):

Figure 66 Branch selection

Finally,, you will have to select a local directory to where the fork will be cloned. The initial branch that must be selected is the AP242 branch. By default, the repository in the server will be named “origin”. This is a GIT convention and is applied by default by every GIT client:

Figure 67 Local folder cloning and branch

Once the project has been cloned, the EGit interface should be similar to this:

Figure 68 Repository structure

As you can see, different kind of branches are created when cloning a repository: the local branch is the physically present branch and the remote tracking branch is the branch in the server repository. In this case, only the AP242 branch exists.

2. Working locally and pushing to the forked repository ¶

With EGit we will be able to stage changes and commit them locally and to the server. To track all the files, right-click on the Working-tree icon and select Add to Index:

Figure 69 Add to index menu

This way EGit will be able to see which changes have been done in the local repository. To commit the changes, right-click on the repository and select Commit...

Figure 70 Repository menu

A commit menu will appear in the bottom right of your eclipse client:

Figure 71 Commit menu

All the files in the Staged Changes section will be pushed commited whenever the Commit button is pressed. A commit message must be written before pressing the “Commit” button.

The changes will be commited locally and the local branch will be updated with the latest commit message:

Figure 72 Updated branch status

To push those changes to the repository so every user can benefit from them, right click on the branch and select Push Branch...

Figure 73 Branch menu

The selected remote should be the origin (the forked repository) and the project branch (in this case the AP242 branch):

Figure 74 Pushing menu

A success message should appear and the changes will be pushed to the server and available to all the users.

3: Importing an external team repository ¶

Note

Before being able to add an external repository, you should ask the team leader for the correct access rights so you can clone their repository.

A. Cloning an external repository¶

If during the development process you need to work with another team and synchronize your development process with theirs, you will have to import a new remote. To do so, right click on the Remotes icon and select Create Remote...

Figure 75 Remotes menu

The window that will appear will ask you to give a name to the new remote. In this case, we will name the repository “mossec”. Be sure to configure the fetch option since we will not push directly to that repository:

Figure 76 Remote name definition

The “Configure Fetch” window will appear asking for a repository URI. Simply click on Change… and write down the external repostory URL that can be found in GitLab:

Figure 77 External repository import menu

If the import process has gone smoothly, the mossec branches should appear in the EGit interface:

Figure 78 EGit interface with mossec branches

B. Pulling from the remote repository¶

To integrate the Mossec branch current files into the AP242 branch. Simply right-click the repository icon and select Pull...

Figure 79 caption

In the “Pull” window, please select the “mossec” repository and the branch from where you want to merge the changes. In this case, the MoSSECworking branch.

Figure 80 Pull menu

If there is a conflict for the pull, the conflict window will appear in eclipse. In this case the README.md file has been modified by both teams. Therefore we need to manually select the correct version and select Commit and Push...

Figure 81 Conflict resolution environment

Whenever the development process is complete and mature, we will push the changes back to the forked repository.

To do so, right click on the AP242 branch and select Push Branch...

Figure 82 Branch menu

The Push menu appears. Select the “origin” repository and the good branch:

Figure 83 Push menu