6.4 Managing Package Versions Using Git

NetIQ allows you to manage Designer package versions using Git. Git is an open source distributed version control system used for storing and retrieving files. It allows you to manage, track, maintain the history of changes, or retrieve an earlier state or compare different states of files. For more information about Git, see Git documentation.

IMPORTANT:You can use Git to share packages when the packages are developed or staged. NetIQ does not recommend you to use Git for Designer project versioning.

6.4.1 Benefits of Using Git

Implicit backup: Git maintains multiple backup copies within the repository. This is useful in case of an event or disk crash.

Pull and Push operation: Git allows you to copy changes to a remote or local repository.

  • The Pull operation fetches the changes from the Git repository to a local repository. This is useful when you want to synchronize changes between the two repository instances.

  • The Push or Publish operation publishes the changes from the staging area to a local repository and further publish them to the Git repository. You can also publish your changes directly from the staging area to the Git repository.

6.4.2 How Does Git Work?

You must create a source Git repository and add the required files to it. Designer pulls files from the Git repository. The changes are first performed on the Working Tree. Then the changes are staged in the Staging Area before they are pushed to the Git repository.

  • Working Tree: This consists of the files that you are currently working on. You can add, modify, or delete a file from the local code base location. You can modify multiple files at a time. You add the changes to the Working Tree once you have modified the required information.

  • Staging Area: This is an intermediate storage area. This area has the changes that were made to the files in the Working Tree. Git collects all changes which will be part of the next commit action from this area.

  • Git Repository: This is the area that stores all the committed changes. The final version of the changes are available in the Git repository.

Figure 6-4 Commit, Push, and Pull operation

Let us understand how Git works. You first edit the files in the working tree. After editing the file, you move the file from the working tree to the staging area. The Commit option is used to commit the changes from the staging areas to the local repositories. You use the Push option again to commit changes from the local repository to the Git repository.

You can directly commit the changes from the staging area to the local and Git repository by using the Commit and push option.

NOTE:Eclipse supports only EGit and JGit plug-ins.

6.4.3 Adding an Existing Local Git Repository

Perform the following actions to add an existing local Git repository:

  1. Navigate to Windows > Show View > Other > Git > Git Repositories.

  2. Click Add an exiting local Git repository.

    Figure 6-5 Add an existing local Git repository

  3. Select the required repository and click Finish.

6.4.4 Cloning an Existing Local Git Repository

Perform the following actions to clone an existing Git repository:

  1. Navigate to Windows > Show View > Other > Git > Git Repositories.

  2. Click Clone a Git repository.

  3. Specify the Git repository URL you wish to clone in the URI field in order to connect it to the local repository. Once the URL is entered, the remaining fields are auto-populated. Enter the Git credentials for authentication.

    Figure 6-6 Clone Git Repository

  4. Click Next.

  5. (Optional) Select the branch (if any) in the Branch selection window and click Next.

    By default, a local folder is created with the same repository name. This directory is an editable field. Click Finish.

    NOTE:Select the Run in Background option to allow the current operation to execute in parallel with other Designer activities.

    The cloned repository is now listed under Git Repositories.

    Figure 6-7 Cloned repository listed under Git Repositories

  6. In the Outline view, right click on the package and select Build.

  7. Select the Build to cloned Git Repository; and select Release Package if you wish to release the package.

    NOTE:The Build directory option is grayed out when Build to cloned Git repository is selected.

    For more information on releasing package, see Releasing and Publishing Packages.

  8. Click OK.

  9. A success message appears. Click OK.

    The built package is listed under Working Tree.

    NOTE:Each time you edit and build the package, a new version of the package is appended to the working tree.

  10. Right click the cloned repository and click Commit. The Git Staging tab appears.

  11. In the Git Staging tab, the package is listed under Unstaged Changes. Right-click on the package and select Add to Index. The package will be listed under Staged Changes.

    NOTE:You must enter a message while committing your changes to the Git repository.

  12. To check-in the changes only to the local repository, click Commit. Click Commit and Push for the changes to be checked-in to both the local and Git repository.

  13. Click Next.

  14. Click Finish.

The package is listed in the Git repository.

For more information on publishing the package, see Releasing and Publishing Packages.

6.4.5 Creating a Local Git Repository

Perform the following actions to create a new local Git repository:

  1. Navigate to Windows > Show View > Other > Git > Git Repositories.

  2. Click Create a new local Git repository.

  3. Specify the directory for the new repository. By default, a local folder is created. This is an editable field and click Finish.

    Figure 6-8 Create new local Git repository

When you add files to the local GIT repository, the .gitignore file blocks some of .jar files by default. To manually add ignored .jar files to the repository, run the command:

git add --force <file>

For example, git add --force NAME_Of_THE_FILE.jar.