SAP Learning Journey

Working with GIT Within SAP Business Application Studio

Objectives
After completing this lesson, you will be able to:

After completing this lesson, you will be able to:

  • Use the native Git integration of SAP Business Application Studio

Overview of Git

Why Should You Use a Version Control System?

Think about an Cloud Foundry application. This application, with its different modules (SAP HANA database modules, UI, and control flow modules), consists of a number of files, organized in different folders.

Watch this video to learn about a typical scenario in Version Control.

So, how do you handle this request? At the moment, your current development is not finished or tested, but you need to patch your version 2.1.0. Of course, you want to start from the last release (you do not want to include any part of the future functionality into the patch), but your patch might affect some files that you already modified as part of the development of new features.

This is where a version control system comes into play. It allows you to keep a complete change history by using milestones during the development of your code, at a very fine-grained level if necessary. You can also branch your code, which means, you can develop and test different features in different parallel development threads (branches). If a feature branch is good to go, you can merge this branch with the main branch. If it is not, you can continue your development, or even get rid of this branch if you realize that a development option for a feature was not relevant and you need to think about it again.

Key Benefits of a Version Control System

The following are the key benefits of using a version control system:

  • Source code backup

  • A complete change history

  • Branching and merging capabilities

  • Traceability (for example, connecting a change to project management software)

To learn more about version control systems, view the following page: https://www.atlassian.com/git/tutorials/what-is-version-control.

Git in a Nutshell

Git is a Distributed Version Control System (D-VCS) used to manage source code in software development, or more generally to manage the lifecycle of any set of files.

It allows one or several developers to work locally with their own copy of the Git repository, which contrasts with a traditional client/server architecture.

Note
Git can also be used even out of a collaboration context, to help you control the development of a project on which you work alone, thanks to a number of capabilities.

The architecture of Git is distributed. It is somewhere between purely local and purely central. A local architecture would make it difficult to several developers to collaborate. A centralized one allows collaboration, but in some cases, a developer need to block a piece of code on the central repository while working on it.

Instead of this, Git is designed so that every developer can keep the entire history of a project (or only a part of it, depending of their needs), locally on their computer.

Git is a free software distributed under GNU GPL (General Public License).

The Git Architecture

Watch this video to learn about the Distributed Git Architecture.

Note
In Git, it is even possible for a developer to define the local repository of another developer as a remote repository and to synchronize his development. This requires a network access and the relevant authorizations.

The shared Git repositories can be hosted on the own company’s IT infrastructure, or on Git hosting services such as GitHub (one of the most popular), Helix (Perforce), Bitbucket (Altassian), and many more. A lot of companies offering Git hosting services also provide additional services such as code review or issue tracking.

The Key Benefits of Git

Git has been designed with security, flexibility, and performance in mind. Almost every operation is performed locally. The branching model provides an extreme flexibility.

To lean more about Git, go to: https://git-scm.com/.

The Lifecycle of Files in Git

When you work with files locally in Git (the case of remote Git repositories will be discussed later on), this involves three major "logical" areas.

These areas are:

  • The Working Directory

  • The Staging Area, also known as INDEX

  • The (local) Git Repository

These are not all real areas, in the sense that a given file is not necessarily materialized in each of them. Let’s explain this with a diagram.

The way to manage files in a local Git repository is very straightforward, relying on a small number of actions.

Watch this video to learn about the basic Git Workflow.

But what changes exactly do you want to include in your next commit? This is where the Staging Area comes into play. By staging a file, you mark this new or modified file so that it is included in the next Commit. You can of course stage several files (this is very common), or even stage all the current changes of your working directory.

Let’s put it another way: The staging area is the "virtual" place where you put all the modifications that you want to include in your next commit.

Note
So, when your working directory contains changes that you do not want to include in your next commit, you just need to make sure you do not stage the corresponding files before committing.

The Git History

Git is very good at representing the history of a project in a simple way, as the succession of commits.

Over time, all the commits you execute in your project are added to the history, and each commit (except the initial one) references its parent commit.

Note
Actually, you will see later on that in the case of a Merge operation, a commit can have two parent commits.

With each commit, Git keeps record of the commit date, the identity of the developer who executed it, and useful information about which files where affected (added, modified, or deleted).

The Branch Concept in Git

Branching is one of the core concepts of Git, which provides a huge flexibility at a very low cost. So what is a branch?

From a conceptual standpoint, a branch is a series of commits. Technically, a branch is just a pointer that references a particular commit of the project history.

Each Git repository always has at least one branch. The default branch is generally called Master.

For many different purposes, you can create a new branch and commit your changes to one of the existing branch.

Let’s describe the diagram above. After commit C3, a new branch Feature32 has been created to support the development of a new feature. Two commits, C5 and C6, have been made to this branch. In the meantime, additional changes have been committed in the master branch (commit C4).

GIT usage in Business Application Studio

Now that you are familiar with the Fundamentals of GIT lets have a look at the options available for GIT with SAP Business Application Studio.

SAP Business Application Studio has a local repository for GIT the recommendation is always to have the work saved in remote repositories. Remote repository can be public or private aka Corporate GIT.

For this course we will focus on using the Public GIT in particular github https://github.com/. As mentioned earlier you can use any other if you already have an account or are familiar with the tool.

SAP Business Application studio comes with predefined set of development environments, auto tools, plugins to support Github so no additional tool or installs are required just a few prerequisite that have to be met.

Prerequisites

  1. Account on https://github.com :

    Log on to https:// github.com and follow the account creation process step by step.

  2. Repository on https://github.com :

    Once Account is created navigate to repositories in the menu and create a repository.

Once this prerequisites are met you can start to link the Local Repository to Github repository process in the SAP Business Application Studio in your Dev Space.

  1. Setup your Git user name, email :

    git config --global user.email "git_email@company.com"

    git config --global user.name "user_name"

    Note
    This process is carried out on the root folder Terminal → New Terminal → cd projects

    git config –list is used to retrieve the user credentials saved during configurtaion.

  2. Initialize the local directory as a Git repository :

    git --init

    Here we initialise the Local directory as a Git Repository. This point it is local and not written to linked with the repository
  3. Add the files in your new local repository :

    git add .

    Once we have initialised the repository we then can add the files to this repository ready for the first commit.

  4. Commit the files that you've staged in your local repository:

    git commit -m "First commit(Free Text)"

    This step commits the stages files to the Local Repository.

  5. Create a new :Mainbranch.

    git branch -M main

    This will create a new Branch named Main, this can be any name.

  6. Provide the Remote Repository Link :

    git remote add origin https://<Git-Host-URL>/<full-path-to-repository>

  7. Push to Remote Repository :

    git push origin main

  8. User ID and Password :

    User Name and Password for Git is asked you can enter it here and proceed, to avoid this step for every push we have below options.

    • Using Token :

      SAP Business Application studio support Personnel access tokens instead of passwords

      Personal access tokens (PATs) are an alternative to using passwords for authentication to GitHub when using the GitHub API or the command line i.e Personal access tokens function like ordinary OAuth access tokens. They can be used instead of a password for Git over HTTPS

      Personal access tokens can only be used for HTTPS Git operations. If your repository uses an SSH remote URL, you will need to switch the remote from SSH to HTTPS

      You should create a personal access token to use in place of a password with the Github UI or with the command line

      To create a token, follow the instructions described in the GitHub documentation

      Creating personal access token

      1. In the upper-right corner of Github page,click Settings
      2. Click Developer settings
      3. Click Personal access tokens
      4. Click Generate new token
      5. Provide a name for the Token
      6. Select Scopes, Permissions, to use your token to access repositories from the command line, select repo.

      Using a token on the command line

      git clone https://github.com/username/repo.git

      Username: your_username

      Password: your_token

    • Caching the Password / Token : .

      This avoid the efforts to key in the credentials on every push.

      Git Credential helper :

      Enter below commands once you login successfully when you push first time from Terminal

      git config credential.helper cache –timeout=3600000 (time in milliseconds)

      git config credential.helper store

      To erase credentials use below command i.e to disable this cached username/password for your current local git folder user

      git config credential.helper ""

Note
Other option exists but not covered here. Example usage of .netrc.

Git using UI option :

In addition to the Command Line option SAP Business Application Studio provides a graphical user interface for executing Git commands and managing your source control and versioning.

Working with Files in a Git Project

Modifying your project content (with or without Git) means creating, modifying, and deleting files. With Git, all of these changes are tracked in your working directory as soon as they are made, for example, when you save a file you have just modified and listed in the File Status area.

Then, for each file, you have the following possibilities:

  • Stage the modification so that it will be included in the next commit

  • Leave the modification unstaged (it will not be included in the next commit)

  • Discard the change

Staging or discarding can also be done for the entire set of modifications.

The next step is to commit your changes, which will add a next commit to the history of the branch.

Note
The concept of branches in Git, already introduced, will be discussed in more details later on. For now, let’s just consider that you are working on a single local branch, for example, master.

To materialize this workflow, each file is assigned a Git status. This status is represented by an icon in the SAP Business Application Studio for SAP HANA workspace and/or the File Status area of the Git pane. The list of possible file statuses is as follows:

Note
The Conflict (C) status will be discussed later on.

Committing Changes

When you commit changes, you add these changes to the Git history and provide a commit description. From this moment on, the Git History pane will include this commit, and provide the identity of who committed, the date, the commit description, and details on which files were affected by the commit. Note that committing changes does not modify your working directory. The committed files are still available for further modification, and the new or modified files you haven’t committed yet are still here for an upcoming commit. You can also discard the changes to these uncommitted files.

The commit description provides important information to allow the readability of your changes, in particular when you collaborate with other developers. You can find a number of blogs and tutorials on how to write a good commit message. The following are recommendations for writing a commit message:

  • Start with a relatively short subject (50 characters max), using imperative mood

  • Separate the subject and body with a blank line

  • Provide info about what the change does, and why (for example, what issue it solves)

  • If relevant, provide the URL of a related issue or specification in another system (for example, JIRA)

It is possible to amend a previous commit. This allows you to replace the very last commit by a new one, after you have staged additional files. The original commit description is displayed so that you can modify it before committing again.

Caution
You must not amend commits that have been shared with other developers, because this would modify a (shared) history on which others might have already based their work.

More information on Git capabilities for SAP Business Application Studio can be found at https://help.sap.com/viewer/9d1db9835307451daa8c930fbd9ab264/Cloud/en-US/265962e20eee43f499516de9011ac2e3.html

Git setup in BAS using command Line

DemoWatch Demo

Save progress to your learning plan by logging in or creating an account

Login or Register