sap web integrated development environment …...executing “git init” creates a .git...

SAP Web Integrated Development Environment How-To Guide

Provided by Customer Experience Group

Introduction to Git Applicable Releases: Release independent Version 1.0 - October 2014

Introduction to Git

2

Document History Document Version Authored By Description

1.0 Customer Experience Group

First release of this guide

Introduction to Git

3

TABLE OF CONTENTS

1. Business Scenario ............................................................................................................................... 4

2. Background Information .................................................................................................................... 5

3. Prerequisites ...................................................................................................................................... 7

4. Step-‐by-‐Step Procedure ..................................................................................................................... 8 4.1 Project initialization ............................................................................................................................. 8 4.2 Case 1: A very simple merge (fast-‐forward merge) ............................................................................ 10 4.3 Case 2: The 3-‐way merge ................................................................................................................... 14 4.4 Case 3: Merging through rebase ........................................................................................................ 18 4.5 Case 4: Two users on the same branch .............................................................................................. 22

Introduction to Git

4

1. BUSINESS SCENARIO

What is Git? Git is Version Control Software/System (VCS), which means a system that records all the changes to a file or to a set of files over time, so that you can recall a specific version later. Any kind of file can be put under version control, not just source code files. If you are a software engineer or a graphical designer and you have a project, which you want to keep every single version of, VCS is the software that suits perfectly to your case. You can create multiple versions of the project and revert back to a specific version at any time. Git was developed by Linus Torvalds, the creator of Linux, and his team, in order to replace and improve BitKeeper software, which went out the free licensing policy. There are different kinds of VCSs: local, centralized and distributed. A local VCS is a system that allows you to store all the changes to a project in a simple database holding all the changes to files under revision control: it basically works by keeping all the patch sets (differences between files) from one version to another in a special format on disk; then it can recreate what any file looked like at any point in time by adding up all the patches.

Centralized VCSs were developed to allow users working on different systems to collaborate. These systems, like CVS, Subversion and Perforce, have a single server that contains all the versioned files and a number of clients check out files from that central place. This has been the standard for many years. Here it is a simple diagram of its operation:

Introduction to Git

5

This setup offers a lot of benefits, especially if compared with local VCSs. Everyone knows to a certain degree what everyone else is doing on the project. However it has some downsides: for example, if a centralized server goes down for an hour, then during that hour, nobody can collaborate at all or save versioned changes to anything they are working one. If the hard disk on which the central database is, becomes corrupted and there are no backups in place for it, you lose the complete history of the project, except whatever single snapshot people might have on their local machine. Distributed Version Control Systems (DCVSs) overcome this problem. In ad DVCS (such as Git, Mercurial and so on) clients don’t just check out the latest snapshot of the files: they fully mirror the repository. Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied to a server to restore it. Every checkout is really a full backup of all the data.

Since its birth in 2005, Git has evolved and matured to be easy to use. It’s incredibly fast, it’s very efficient with large projects, and it has an incredible branching system for non-linear development 2. BACKGROUND INFORMATION

In this guide we will give a look to some basic functionalities of Git. In particular we will examine a bunch of commands, so that you can get skilled to Git and you will be able to understand how to deal with this VCS. This is the list of the Git commands that will be examined:

• init The “git init” command creates a new Git repository. It can be used to convert an existing, unversioned project to a Git repository or initialize a new empty repository. Most of the other Git commands are not available outside of an initialized repository, so this is usually the first command you’ll run in a new project. Executing “git init” creates a .git subdirectory in the project root, which contains all of the necessary metadata for the repo. Aside from the .git directory, an existing project remains unaltered (unlike SVN, Git doesn't require a .git folder in every subdirectory).

• clone The “git clone” command copies an existing Git repository. This is sort of like “svn checkout”, except the “working copy” is a full-fledged Git repository, it has its own history, manages its own files and is a completely isolated environment from the original repository. As a convenience, cloning automatically creates a remote connection called origin pointing back to the original repository. This makes it very easy to interact with a central repository.

Introduction to Git

6

• add The “git add” command adds a change in the working directory to the staging area. It tells Git that you want to include updates to a particular file in the next commit. However, “git add” doesn't really affect the repository in any significant way, changes are not actually recorded until you run “git commit”.

• remote The “git remote” command lets you create, view, and delete connections to other repositories. Remote connections are more like bookmarks rather than direct links into other repositories. Instead of providing real-time access to another repository, they serve as convenient names that can be used to reference a not-so-convenient URL.

• commit The “git commit” command commits the staged snapshot to the project history. Committed snapshots can be thought of as “safe” versions of a project; Git will never change them unless you explicitly ask it to. Along with “git add”, this is one of the most important Git commands. While they share the same name, this command is nothing like “svn commit”. Snapshots are committed to the local repository, and this requires absolutely no interaction with other Git repositories.

• push Pushing is how you transfer commits from your local repository to a remote repo. It's the counterpart to “git fetch”, but whereas fetching imports commits to local branches, pushing exports commits to remote branches. This has the potential to overwrite changes, so you need to be careful how you use it.

• branch A branch represents an independent line of development. Branches serve as an abstraction for the edit/stage/commit. You can think of them as a way to request a brand new working directory, staging area, and project history. New commits are recorded in the history for the current branch, which results in a fork in the history of the project. The “git branch” command lets you create, list, rename, and delete branches. It doesn’t let you switch between branches or put a forked history back together again. For this reason, “git branch” is tightly integrated with the “git checkout” and “git merge” commands.

• checkout The “git checkout” command lets you navigate between the branches created by “git branch”. Checking out a branch updates the files in the working directory to match the version stored in that branch, and it tells Git to record all new commits on that branch. Think of it as a way to select which line of development you’re working on.

• fetch The “git fetch” command imports commits from a remote repository into your local repo. The resulting commits are stored as remote branches instead of the normal local branches that we’ve been working with. This gives you a chance to review changes before integrating them into your copy of the project.

• pull Merging upstream changes into your local repository is a common task in Git-based collaboration workflows. We already know how to do this with “git fetch” followed by “git merge”, but “git pull” rolls this into a single command.

• merge Merging is Git's way of putting a forked history back together again. The “git merge” command lets you take the independent lines of development created by “git branch” and integrate them into a single branch.

• rebase Rebasing is the process of moving a branch to a new base commit. From a content perspective, rebasing really is just moving a branch from one commit to another. But internally, Git accomplishes this by creating new commits and applying them to the specified base, it’s literally rewriting your project history. It’s very important to understand that, even though the branch looks the same, it’s composed of entirely new commits.

• Our tour will be based on a GitLab, which is an Open Source Software Management system. It’s very similar to GitHub, one of the most popular VCS servers. We will be using a local installation of GitLab on Ubuntu. However, all the commands seen here can be easily applied to any server with Git standards.

Introduction to Git

7

3. PREREQUISITES

In order to follow the steps in this guide you need to have a couple of accounts on any Git server and a project with the related repository already created for this. As I said, we’ll be using GitLab. Some users have been created inside GitLab: riveradmin, which is the administrator of the server (you don’t need it if your project with the repository is already in place) and a couple of simple developers, as river01 and river02: these are the users that will perform all the operations in this document. Our project is named firstproject and so the related repository. The user riveradmin is the owner and the administrator of this project: it creates the project, the repository and initializes it. The two developers will work on the project separately. Both users are already in place on the server and an SSH key as been already assigned to them. The SSH key has been already added to the GitLab server, so that the trusting between the user and the server works properly. We are going to use Git from terminal in order to issue the commands. This because it will be easier to see how it works from a very low point of view and to get all the messages coming back from the server. Of course there are a lot of applications that drive the users through all the Git operations, but we prefer, for the scope of this document, to stay as basic as possible.

Introduction to Git

8

4. STEP-BY-STEP PROCEDURE

In this section I will introduce you to several Git commands. As our scenario we’ll consider the case of a user who wants to perform some changes to a set of files, then he wants to merge these changes together. The “merge” scenario is one of the most recurring situation when dealing with Git: users work separately and then their work needs to be unified, needs to be merged in one single package. In this document we won’t split the job among different users: just one user will do the entire work, but it’s easy to extend the following steps in the case that multiple users are working on the same project: all the steps here will be quite the same.

4.1 Project initialization The user riveradmin connects to the system: he creates the project from the web administration console and assigns the users river01 and river02 to it as developers.

Then he opens the terminal and initializes the project with the following sequence of commands

1. Open terminal

2. Go to the user’s home folder: cd /home/riveradmin

3. Create a temporary folder: mkdir temp

4. Go in the temporary folder: cd temp

5. Create a new folder named firstproject: mkdir firstproject

6. Go inside this folder: cd firstproject

7. Initialize the folder with Git: git init

8. Create a new file inside this folder: touch README

9. Stage this file in the next commit: git add README

10. Commit the changes to the local repository: git commit -‐m “User riveradmin initialized the project”

11. Check the remote repositories configured for this project. The list should be empty: remote show

12. Add a new remote repository to the project and assign to it the name origin:

git remote add origin git@ubuntu:riveradmin/firstproject.git

Introduction to Git

9

13. Push the changes to the remote repository into a branch named master:

git push -‐u origin master (the -‐u option indicates that you want to push the current branch to its upstream branch)

14. If you check the network diagram, you see that the repository has been initialized and that there is just one

operation pushed in it

Introduction to Git

10

4.2 Case 1: A very simple merge (fast-forward merge) In this chapter we’ll see a very simple case where a user river01 has already done some commits and pushes on the master branch (this is the default branch) and at a certain time he decides to open a new branch, named feature01, in

order to start developing a new feature on the project. Once switched on this new branch he starts doing other commit and push operations on this new branch. No one touched so far the original branch, so at that point of time there is just a fork of the master branch on a new one. Now he wants to merge this new feature with the master branch and delete feature01, as it’s no longer needed. The situation is something similar to the one represented in the following picture:

In order to start with the solution of this problem the user river01 opens a terminal window. Since this is the first time that he logs to the system it’s required to clone the project that riveradmin has created to start working on it. The sequence of commands performed by river01 is the following:

1. Open terminal

2. Go to the user’s home folder: cd /home/river01



5. Clone the repository that riveradmin prepared: git clone git@ubuntu:riveradmin/firstproject.git

6. Go into the firstproject folder: cd firstproject

7. Now river01 creates a new file and starts working on it: touch file01.txt

8. Edit the file file01.txt: gedit file01.txt

9. Add the line “Commit M1”, save and exit.

10. Stage this file in the next commit: git add file01.txt

11. Commit the changes to the local repository: git commit -‐m “Commit M1”

Introduction to Git

11

12. Push the changes to the remote repository: git push -‐u origin master

13. Now let’s do another commit and another push:

14. Do: gedit file01.txt 15. Add the line “Commit M2”, save and exit.

16. Do: git commit -‐am “Commit M2” (notice that we are not issuing the “add” as a separate command, but inside the commit itself by specifying the “-‐a” option)

17. Do: git push -‐u origin master

18. Checking the network diagram, this is the situation we find:

19. Now let’s open a new branch for the new feature and let’s name it feature01. Then add a new “Feature line

1” to the file01.txt:

20. Open a new branch named feature01: git checkout -‐b feature01

21. Do: gedit file01.txt 22. Add the line “Commit feature line 1”, save and exit.

23. Do: git add file01.txt 24. Do: git commit -‐m “Commit feature line 1”

25. Do: git push -‐u origin feature01

Introduction to Git

12

26. Add a new line to the file01.txt. Do: gedit file01.txt 27. Add the line “Commit feature line 2”, save and exit.

28. Do: git commit -‐am “Commit feature line 2”


30. This is the network diagram at the end of this operation. As you can see here the feature01 is on the same

line of the master branch. This means that merging the two things is quite simple. We need just to move the master cursor up to the “Commit F2” commit. This is just a “fast-‐forward” merge operation.

31. If you do git branch now, you see that you are still on the feature01 branch) 32. Go on the master branch: git checkout master

33. Check that you are now on the master branch: git branch

34. You can now merge the feature01 branch with master: git merge feature01

35. Don’t forget now to push the result of last merge operation: git push -‐u origin master

36. You can delete the local feature01 branch: git branch -‐d feature01

Introduction to Git

13

37. You can delete as well the branch feature01 from the origin: git push origin -‐-‐delete feature01

38. By giving a look to the network diagram, this is what we see now:

Introduction to Git

14

4.3 Case 2: The 3-way merge ...

Another case of merge is called the 3-‐way merge. This case occurs when, while you have created a new branch for a new feature, the development on the master branch moved forward.

In the picture you can see how this is structured before merging. At a certain point someone started developing some new feature, but someone else continued working on the master branch. Our goal is to merge all together.

For this merge operation you will need 3 commits: one for master, one for the new feature and another to join the two branches in the master again. For this reason, it’s called “3-‐way merge”.

After merging, the master head will point to the latest version of the code, with the changes made in the new feature branch applied into master.

We will assume that our new feature is called feature02.

Staying connected with the user river01, let’s continue the work we started in the previous chapter. We have now the following situation:

There are two files in our project: README created by the administrator and file01.txt created by river01. Now let’s open a new branch for a new feature called feature02 and let’s start working on it.

1. Open terminal

2. Do: cd /home/river01

3. Do: cd temp

4. Do: cd firstproject

5. Do: git checkout -‐b feature02

6. Do: touch feature02.txt

7. Do: gedit feature02.txt

8. Add the line “Feature F2 line 1”, save and exit.

9. Do: git add feature02.txt

10. Do: git commit -‐m “Feature F2 line 1”

Introduction to Git

15


12. Now let’s do another commit and another push: gedit feature02.txt

13. Add the line “Feature F2 line 2”, save and exit. 14. Do: git commit -‐am “Feature F2 line 2” (notice that we are not issuing the “add” as a separate command, but

inside the commit itself by specifying the “-‐a” option)


16. Now switch on master and continue working on it by adding a new file named file02.txt. At the end of this

process we’ll have a file named feature02.txt present in the feature02 branch and a file file02.txt in the master branch. We will have to merge them together in master. So now switch on master: git checkout master

17. Do: touch file02.txt 18. Do: gedit file02.txt 19. Add the line “Commit Q1”, save and exit.

20. Do: git add file02.txt 21. Do: git commit -‐m “Commit Q1”

Introduction to Git

16


23. Add a new commit and push: gedit file02.txt

24. Add the line “Commit Q2”, save and exit.

25. Do: git commit -‐am “Commit Q2”


27. At the end of this process, this is the resulting network diagram:

Introduction to Git

17

28. The two branches now are NOT on the same line, they are diverging, but we want to merge both back into master. We’ve already done two commits, one for feature02 and another for master. We need to do the final commit to put all together on the master branch. Notice that the file feature02.txt belongs to feature02 and file02.txt belongs to master:

29. Let’s do the merge: git merge feature02 -‐m “Merging feature02 with master”

30. Push the merged branch: git push -‐u origin master

31. We have now both files together in master:

32. This is the network diagram for the new situation:

33. We can now delete the feature02 branch, if no longer needed, from both the local and remote repositories:

git branch -‐d feature02 34. Then: git push origin -‐-‐delete feature02

Introduction to Git

18

4.4 Case 3: Merging through rebase ...

There is another way to merge two divergent branches. This method is achieved by using a new Git command named “rebase”. Doing a rebase means moving a branch to a new base commit. In the picture you can see indeed that the

entire feature branch is moved at the end of the master branch. Then you just need to perform a fast-‐forward merge as explained in the chapter 4.2, in order to have all merged into master. We will consider here a simple case where we have a new feature feature03 that we want to merge into the master branch, which, in the meantime, has moved forward with other commits. The steps are quite the same we did in the previous chapter. The only different thing is the final part.

Staying connected with the user river01, let’s continue with the work we started in the previous chapter. We have now the following situation:

Let’s open a new branch for a new feature called feature03 and let’s start working on it.

1. Open terminal

2. Do: cd /home/river01

3. Do: cd temp

4. Do: cd firstproject

5. Do: git checkout -‐b feature03

6. Do: touch feature03.txt

7. Do: gedit feature03.txt

8. Add the line “Feature F3 line 1”, save and exit.

9. Do: git add feature03.txt

10. Do: git commit -‐m “Feature F3 line 1”

Introduction to Git

19


12. Now let’s do another commit and another push: gedit feature03.txt

13. Add the line “Feature F3 line 2”, save and exit. 14. Do: git commit -‐am “Feature F3 line 2”


16. Now switch on master and continue working on it by adding a new file named file03.txt. At the end of this

process we’ll have a file named feature03.txt located in the feature03 branch and a file file03.txt in the master branch. We will have to merge them together in master. So now switch on master: git checkout master

17. Do: touch file03.txt 18. Do: gedit file03.txt 19. Add the line “Commit Z1”, save and exit.

20. Do: git add file03.txt 21. Do: git commit -‐m “Commit Z1”


Introduction to Git

20

23. Add a new commit and push: gedit file03.txt

24. Add the line “Commit Z2”, save and exit.

25. Do: git commit -‐am “Commit Z2”


27. At the end of this process, this is the resulting network diagram:

28. The two branches now are NOT on the same line, they are diverging, but we want to merge both back into

master. This time we’ll use another technique, which consists in rebasing the feature03 on top of the last commit in the master branch and then doing a fast forward merge always on the master branch.

29. Switch to feature03: git checkout feature03 30. Rebase feaure03 to master: git rebase master

31. Go back on master: git checkout master

32. Do a fast-‐forward merge: git merge feature03

Introduction to Git

21


34. This is the final network diagram:

35. We can now delete the feature02 branch, if no longer needed, from both the local and remote repositories:

git branch -‐d feature03 36. Then: git push origin -‐-‐delete feature03

Introduction to Git

22

4.5 Case 4: Two users on the same branch ...

What happens if two users are working on the same branch? We are going to see it in this chapter. We will consider the case when a new developer (river02) jumps in and makes a modification to the master branch.

Let’s start with the first case. Connect to the server with the user river02.

1. Open terminal

2. Go to the user’s home folder: cd /home/river02



5. Clone the repository that riveradmin prepared: git clone git@ubuntu:riveradmin/firstproject.git

6. Go into the firstproject folder: cd firstproject

7. Now river02 edits an existing file and adds a new line to it: gedit file01.txt

8. Add the line “This line was added by river02”, save and exit

9. Do: git add file01.txt

10. Do: git commit -‐m “river02 added a new line”


12. Now switch on river01 and try to change the same file: gedit file01.txt

13. Add the line “river01 added a new line”, save and exit 14. Do: git add file01.txt

Introduction to Git

23

15. Do: git commit -‐m “river01 added a new line”

16. If you try to push now, look what happens: git push -‐u origin master

17. You get an error: the push operation cannot be performed because another one changed this file and these

changes are not in the river01’s local repository. In order to bring these changes in your local repository you can run the command git fetch origin

18. The origin is fetched and brought into your local repository. Now you need to merge the local repository with your last changes: git merge origin/master

19. Again an error message informs you that there are changes from both sides on the same files so you need to

fix the merge conflicts by editing the file01.txt file: gedit file01.txt

20. The lines in this file appear formatted in a special way. You can see the changes made by the two users together. You have just to decide how to fix them.

Introduction to Git

24

21. We fixed them in some way:

22. Now you can post the final version: git add file01.txt 23. Do: git commit -‐am “river01 fixed conflicts on file01.txt”


25. All worked fine: the two versions are now perfectly integrated. The problem is now that from the point of

view of river02, his file01.txt is not in sync with the remote repository since river01 merged it with his file. There is the need from river02 to update his file accordingly. This operation can be done easily simply by performing a pull operation. The pull command does two things: a fetch and a merge. As river02 didn’t touch file01.txt since river01 did the last post, this operation will be fine because the merge that will be performed can be done automatically.

26. So the command git pull origin, will quickly synchronize river02’s local repository.

© 2014 SAP SE. All rights reserved.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAPBusinessObjects Explorer, StreamWork, SAP HANA, and other SAPproducts and services mentioned herein as well as their respectivelogos are trademarks or registered trademarks of SAP SE in Germanyand other countries.

Business Objects and the Business Objects logo, BusinessObjects,Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, andother Business Objects products and services mentioned herein aswell as their respective logos are trademarks or registered trademarksof Business Objects Software Ltd. Business Objects is an SAPcompany.

Sybase and Adaptive Server, iAnywhere, Sybase 365, SQLAnywhere, and other Sybase products and services mentioned hereinas well as their respective logos are trademarks or registeredtrademarks of Sybase Inc. Sybase is an SAP company.

Crossgate, m@gic EDDY, B2B 360°, and B2B 360° Services areregistered trademarks of Crossgate AG in Germany and othercountries. Crossgate is an SAP company.

All other product and service names mentioned are the trademarks oftheir respective companies. Data contained in this document servesinformational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materialsare provided by SAP SE and its affiliated companies ("SAP Group")for informational purposes only, without representation or warranty ofany kind, and SAP Group shall not be liable for errors or omissionswith respect to the materials. The only warranties for SAP Groupproducts and services are those that are set forth in the expresswarranty statements accompanying such products and services, ifany. Nothing herein should be construed as constituting an additionalwarranty.

www.sap.com

sap web integrated development environment …...executing “git init” creates a .git...

Documents