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's 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 other's 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 isn't finished, not tested, but you need to patch your version 2.1.0. Of course, you want to start from the last release (you don't 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 isn't, you can continue your development, or even get rid of this branch if you realize that a development option for a feature wasn't 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's 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
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's even possible for a developer to define the local repository of another developer as a remote repository and to synchronize their 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 aren't all real areas, in the sense that a given file isn't 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 SAP Business Application Studio in your Dev Space.
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
In the upper-right corner of Github page,click Settings
Click Developer settings
Click Personal access tokens
Click Generate new token
Provide a name for the Token
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 SAP Business Application Studio 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.
