KetchCyork/SAPgit.md

## SAPgit.md

      
    Raw
  

              SAPgit.md
            
          
    SAP Cloud Version Control with Git

Week 0 Notes


Git was created by Lunus Torvalds when the version control for Linux open source development community was no longer going to offer free version control
Gerrit is web based code review while managing your code repositories
The SAP Web IDE that most developers have been using will be sunsetted soon and replaced by the SAP web IDE full stack.  This new IDE will ultimately allow cloud development for apps running node.js and access to open source libraries

Week 1 Notes


History of Version Control

Paper comments - multiple versions help you understand the evolution
Electronic file based - using multiple computer based files with new names
Local Access Version Control - in 1972 Bell Labs created SCCS - Source Code Control System that gave the illusion of a single file with multiple versions
Centralized Version Control - CVS and ABAP on Netweaver - only one developer can work on an object at any given time
Distributed Version Control - Git - every developer gets their own separate central version control system.  A developer could create branches and repo's locally without communicating with the master rerpository until they are ready.  When you need to sync your local repository with the master version there are other commands to use.


For git you must always understand if the command is intended for your local repo or the master repo
Starting out with cloud platform development you can use the free Git service for your central repository
Cloning - when you clone a repo the branches get their name changed automatically adding "origin"
Cloning will always result in N + 1 branches locally after cloning
Cloning - the parent is not aware of the child or "cloned" repo.  The child repo is however aware of the parent from which it was cloned
SAP Web IDE allows you to start development and then assign the content to a repo after the fact so that your team can begin colloboration with cwrsion control

First create your files for your stand alone UI5 project
Make the files a Git repo
Create an empty GitHub repo
Assign the files to the Github repo
Push code to the repo


Files in a repo can be modified, saved, staged and commited
Files that you want Git to ignore can be done by creating a file with the extension of ".gitignore"
The examples show how you can change the sequence of commits to the branch by staging them in the sequence you desire
Git gives you the ability to amend a commit - the example is a simple edit to the index.htyml file and you don't want a new commit, you can stage the changes with the amend feature which will simply update the previous commit and not create a new commit
Stashing was designed to save your code progress without impacting your local repo
Branches are pointers to a commit
Several branches can be sequential or can point to the same commit
Two branches in sequence means all commits are ina . straight line and there are no divergence in history
The term "Head" is just short hand for the currently checked-out version
Detached head state happenes when the currently checked out version is not pointed to by any named branch
Tags are names attached to a commit to note something
Most teams use tags for release management as a best practice
Reverting allows you to undo any commit, not just the most recent
You can also revert the previous reversion to rstore the commit you may have mistakenly removed
When you revert in web ide is will remove the changes and automatically commit the changes

Week 2 Notes


The term merging into and maerging onto mean the same thing
for a fast forward merge (where the current feature development is more advanced than master, you start by checking out the branch you are starting from, so we use the example of merging from master onto the feature branch.  In this case we check out master and fast forward merge onto feature - branch pointers end up pointing to the same commit
Automatic 3 Way Merge

THe situation here is when there has been a number of changes made to the master branch (production bug fixes) and several made to the feature branch.  When you merge there are 3 commits that happen automatically
Commit 1 is pointed to the branch you are merging from
Commit 2 is pointed to the branch you are merging to
Commit 3 is pointed to the last common ancestor of both branches
The branch pointers end up pointing to different commits
This merge creates a new commit called a merge commit, however the fast forward merge does not create a new commit
After this merge you can still check out master and make commits and they WILL NOT include commits from the feature branch - if that is the desired outcome you will need to create a fast forward merge directly after the 3-way merge and then make changes to master branch.


3 way merge with conflicts - where the same lines of code are modified in 2 seoarate branches
When attempting to merge two branches with conflicts SAP Web IDE will show each line that has conflicts and highlights each section of code that is different in shades of color to allow easy conflict resolution
Web IDE has a reset function to reverse a previous merge commit and reset your repo to the state it was before the attempted merge
Rebasing can be used in place of a 3 way merge.  When you rebase you pick up all of the coomit from one branch and put them on the tip of another branch
Rebasing does not createa a merge commit
Rebasing can be used in place of a 3 way merge.  When you rebase you pick up all of the coomit from one branch and put them on the tip of another branch
After rebasing there are some housekeeping steps

Check out the branch you were rebasing onto
Fast forward merge onto the branch you originally rebased from
delete the branch you originally rebased from


In the example we are going to rebase from style_mods branch onto Master

Check out style_mods
Click rebase and choose master branch in the pop-up
the result is a linear history for changes
What happen if you choose to rebase instead of 2 way merge


Rebasing actually takes each commit and computes the change from the target branch and make a new commit
If any commit finds any comflict web IDE will automatically go into interactive rebase conflict resolution mode
During conflict resolution you have 4 main options

skip patch - combines seeral commits before resolving conflicts
abort - same as reset in a 3 way merge
Continue - after resolving the conflict, saving the file, staging the fils and then clicking "continue"
Reset - just moves the branch pointer - VERY RARE you would do this


Hard resets moves the branch pointer to the same commit however you lose all of the commits from the branch you move from
Hard reset clears out your working area as well
A mixed reset retins all changes between the two branch commit and turns them into unstaged changes
Often times people are trying to solve a challenge with Git but cannot accurately describe what they are trying to solve.

determine the current state of the repo
describe the target state of the repo
often times a mixed reset is a part of the problem


If we have a bunch of commits on a separate branch and we want to reduce commit that show up on the master you can "rebase" and the skip-patch for each conflict and then resolve the conflicts at the end.  If you only get a few conflicts you still have a bunch of commits that show up on master
If you check out the experiement branch and then do a mised reset on the Master branch and the all commits would be place din the working are and then you make one commit after manually evaluating changes ( unfortunately all changes made during the same time on the master branch will be placed as un-staged commits and you also have to manually figure those out as well)

Week 3 Notes


Remote Branch - SAP Web IDE uses Remote Branches to keep local branch differences to the origin repo and calculate what has changed.  You cannot check out the remote branch.  The remote branch is the last state of the master branch before you cloned it.
You can think of the remote repo as a "bookmark" of the state of the origin branch
Push is the commend you use to get the contents of your local repository to the remote repository
The push command updates the entire branch and not just a commit - it is essentially a fast forward nerge from your local repo branch to the branch on the origin repo
After the push all branch pointers are pointing to the same commit locally and remote repo's
In SAP Cloud Web IDE you can push the master branch back to origin on Github by selecting push and logging into Github when prompted
If you completed a push and realized you forgot one small change in your local repo and decide to use the amend command in Web IDE, so now your local branch and remote branch are not aligned
Fetch command allows you to bring the content of the remote repo into your local repo
When you use the Push command it is a single branch, however when you use Fetch it Fetches all branches.
"Pull" is a shortcut command that combines Fetch and Merge
Pull has some disadvantages

Sometimes you want to rebase instead of merge
It doesn't give you the opportunity to evaluate your next steps
It creates the illusion of centralized version control creating problems later
Unnecesary as it is a combination of other commands
Some developers think that "Pull" is like checking out the code and "Commit + Push" is checking in thier code which is a wrong understanding
Avoid using the "pull" command


Rebasing - if you rebase an experimental branch (local development) onto the Master (local copy) you then corrupt the historical context of the Master branch and will damage what your colleagues are attempting to do locally.
If you then push your work to the remote origin and it succeeds you will prevent your colleagues from being able to merge their work
Diff allows you to quickly compare any two commits
Blame allows you to see exactly when and by whom a change to code was made
Git workflows define how teams work togther using Git version control
Centralized Workflow

All development done on the master branch
Strict centrailized workflow means the origin repo should only have the master branch and no other branches


Feature Workflow

A feature branch is created in the origin repo
Each developer clones the repo to their machine and check's out a local branch called Feature 1 (a replica of origin/feature1)
After coding and commiting the developer will Fetch the changes from the remote repo and see if there are any changes and if not push their changes back up to the remote repo
When they are done one of them does a 3 way merge from Master onto Feature1 branch to merge all changes
Normally in a feature workflow the team would use rebasing within the feature branch and then a 3 way merge from the feature branch onto the master branch
Gitflow builds on the concept of the feature workflow

Only production releases are allowed on the Master Branches
every single commit on master is tagged for a release, therefore very limited commits are allowed on master
In this approach a separate branch for new devlopment is required
Also a release branch is created to merge completed tested features onto the release branch
There is also a hotfix branch for production fixes
Only hotfixes and release commits can come into master
Only 1 thing that is completely done gets commited to the branch
You should be obsessive about fetching continuously to mitagate conflicts
In the Gitflow the develop branch serves the same purpose as the master branch in the Feature workflow
In a large team the Featue branch would have sevaeral active branches at the same time


Distributed workflow primarily deals with how repo's interact with each other versus branches
This is NOT supported by Web IDE
multiple remote repositories are typically in place
Git was created in 2005 and github just started the 2008 and added some additional features
Forking on GitHub is a server side clone - to take it in a different direction than the originally planned