Tell us what you think

We want to create the best possible experience for our learners. Your feedback helps us to improve the experience for everyone.

SAP Learning Journey

Using Git to Manage Source Code

Objectives

After completing this lesson, you will be able to:

Manage source files using Git

Overview of Git

Why Should You Use a Version Control System?

It is very likely that there will be multiple developers working on the same modeling project. The developers need to work together and this means not overwriting each others work, making sure they use the latest version of any file, and also being able to return to a previous version of any file if errors are found. To handle these requirements a source code version control system is needed.

The source code version control system needs to be able to handle parallel developments. Let's take a look at a common scenario:

So, how do you handle this request? At the moment, your current development is not finished, not 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 kind of milestones during the development of your code, at a very fine-grained level if needed. And 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

Source code backup
A complete change history
Branching and merging capabilities
Traceability (for example, connecting a change to project management software)

Git in a Nutshell

Git is a Distributed Version Control System (D-VCS) used to manage source code in software development.

It allows one or several developers to work locally with their own copy of the Git repository.

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 for 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).

Note

Note that the initial purpose of Git is NOT code review or automated deployment of applications. For this, other tools exist –often with advanced connectivity to Git– such as Gerrit for code review, or Jenkins for automated integration and deployment.

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 internally on a company’s IT infrastructure, or on public Git hosting services such as GitHub.

Lifecycle of Files in Git

When you work with files locally in Git, this involves three major "logical" areas.

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.

The staging area is the "virtual" place where you put all the modifications that you want to include in your next commit.

Note

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.

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 an existing branch.

Let’s describe the figure, The Branch Concept. 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

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

Account on https://github.com :
Log on to https:// github.com and follow the account creation process step by step.
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.

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.
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
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.
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.
Create a new :Mainbranch.
git branch -M main
This will create a new Branch named Main, this can be any name.
Provide the Remote Repository Link :
git remote add origin https://<Git-Host-URL>/<full-path-to-repository>
Push to Remote Repository :
git push origin main
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