®
IBM Software Group
Introduction to Git for TSO/ISPF Developers
DevOps Jon Sayles, IBM z Products - [email protected]
@Copyright May, 2019 IBM Trademarks and Copyrights © Copyright IBM Corporation 2008 through 2020.
All rights reserved – including the right to use these materials for instruction.
The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates.
This information is based on current IBM product plans and strategy, which are subject to change by IBM without notice. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way.
IBM, the IBM logo, the on-demand business logo, Rational, the Rational logo, and other IBM Rational products and services are trademarks or registered trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.
2 Mods for Rev2
▪ 90 minutes for branch/merge ▪ Add git pull ▪ A final section on Git in the Real World New branch Git pull Git Fork? For merge - where does the code go?? Show what happens
How do I know what files are in a commit? $ git show --pretty="" --name-only bd61ad98
git show --pretty="format:" --name-only START_COMMIT..END_COMMIT
git config --global alias.changed 'show --pretty="format:" --name-only'
git config --global alias.graph 'log --all --decorate --oneline --graph'
Q&A ▪ 1. Get a class together for the "Git in the Real World" questions -- maybe a Q&A session? ▪
▪ 2. Let people who come to the classes know exactly what's in - and what's not in a class. I didn't do that - this first go round ▪
▪ 3. I'll probably also apportion 90 minutes to Branch & Merge ... the actual baseline usage is way deeper than I'd imagined
3 The IBM Z Open Development and IDz DevOps Curriculum ▪ Module 1 – Introduction to Git for Veteran ISPF Developers ▪ Module 2 – IDz/ZOD Terms, Concepts and Navigation ▪ Module 3 – Graphical Git Tools – The IDz/ZOD Git Views ▪ Module 3 – Editing Your COBOL Programs ▪ Module 4 – Analyzing COBOL Programs ▪ Module 5 – Remote Systems – Connect, Navigate and Search ▪ Module 6 – Using eGit and DBB ▪ Module 7 – Remote Systems – Dataset Access and Organization ▪ Module 8 – Remote Systems – ISPF 3.x, Batch Jobs and Job Management ▪ Module 9 - The Data Tools – SQL Code/Test and DB2 Table Access ▪ Module 10 - Debugging z/OS COBOL Applications and Code Coverage
Optional Modules ▪ Z Open Unit Test ▪ Code Coverage – Deep Dive ▪ Software Analyzer/Code Review – Application source quality standards ▪ Menu Manager – Integrate ISPF REXX Execs and CLISTs ▪ Reusable Code ▪ Application Discovery (AD)
4 Course Assumptions – 1 of 2 1. You have 6+ months of production z/OS work experience, using COBOL, PL/I or Assembler 2. You have some experience with a source management or version control tool: ▪ CA-Endevor ▪ Changeman ▪ SCLM ▪ ISPW ▪ RTC ▪ Subversion ▪ “Home-Grown” source management tool 3. You have Windows/GUI skills: ▪ Navigation ▪ Create new files ▪ copy/paste files & text within files 4. Some experience with Eclipse tooling is helpful 5 Course Assumptions – 2 of 2 5. If you wish to do the hands-on labs, you must have access to a Git Repository with a command-line interface. This can be: ▪ Your own company’s Git Server/Hub ▪ A local Git product: I.E. “GitHub Desktop” ▪ GitHub/GitLab/BitBucket ▪ Some other Git server; – Katacoda’s free Git learning system: www.Katacoda.com – Instruqt’s free Git learning system: https://instruqt.com/public
Notes: ▪ Most of the free Git environments/products require you to register in the vendor’s site ▪ Whatever product or environment you choose, you will use its Command Line Interface to do the workshops in this course 6 Local Git Command Line Interface with IDz & ZOD 6. If you’re using IDz or ZOD you can open a CLI to your Repository: From Remote Systems: Expand Local - then Right-Click Local Shells and select Launch Shell From the Local shell Command line use MS-DOS commands to access the directory you want to use as a Git Repository: cd to your repository-folder Issue Git commands
7 Additional Learning Resources Much of the Git/Tech-Ed approach used in this course was developed by David Mahler – whose work is widely recognized as best-in-class, for Git and modern DevOps tooling enablement: https://github.com/dmahler https://www.linkedin.com/in/davidmahler/ ▪ David Mahler’s video-based learning on YouTube: A simple-to-follow, yet in-depth introduction to Git ▪ Core concepts: https://www.youtube.com/watch?v=uR6G2v_WsRA ▪ Branching/Merging files: https://www.youtube.com/watch?v=FyAAIHHClqI&list=PLf6wuaD-31jdZRVA-YuHWAgiVykP_Si56 ▪ Working with remote Repositories: https://www.youtube.com/watch?v=FyAAIHHClqI&list=PLf6wuaD-31jdZRVA-YuHWAgiVykP_Si56 ▪ Blogs and White Papers on Git from other authors: https://www.atlassian.com/git/tutorials/why-git https://product.hubspot.com/blog/git-and-github-tutorial-for-beginners https://medium.com/@lett/git-basics-f82852313c65 Vim Editor tutorial: https://www.youtube.com/watch?v=szTtE60fIt8 Migrating code to Git: https://www.ibm.com/support/knowledgecenter/en/SS6T76_1.0.4/migration.html Command Line Interface/Git: https://www.git-tower.com/learn/git/ebook/en/command-line/introduction ▪ An aggregation of Git learning sites: https://hackernoon.com/top-5-free-courses-to-learn-git-and-github-best-of-lot-2f394c6533b0
8 UNIT Intro to Git - for z/OS Developers
Topics:
▪ Overview of Git – Initial Git terms, vocabulary, syntax ▪ Comparing, working with and committing files ▪ Remote Git Repositories ▪ Branches, Positioning and HEAD
9 Topics in this section After completing this section you will be able to: ▪ Define Git, and specify reasons for learning to use it ▪ Explain the difference(s) between Git and GitHub ▪ Define what a Git Repository is ▪ Describe the three conceptual areas of a Git Repository ▪ List the steps in a basic Git Workflow ▪ Use the vim editor to create/modify text files ▪ Issue the following Git commands in a live git environment git init git configure user-name/email git add git commit git log ▪ Create a .gitignore file – and describe its purpose
10 What is Git? Git is an open-source, distributed version control system – a tool to manage files and changes to files Git went G.A. in 2005. It is maintained by the Linux foundation and is currently the leader in the version control space – owning nearly 60% market share
https://www.datanyze.com/market-share/source-code-management/git-market-share
11 What do you do with Git? • Store your & organize source files • Take snapshots of files – capturing changes to your source code as versions over time • Restore earlier versions of files from snapshots • Work on multiple versions of a file in parallel • Work on different parts of a file in parallel Note that Git can be used for all filetypes: XML, PowerPoint, MS-Word Spreadsheets, graphics files, etc. But it is particularly well-suited for managing source files: PL/I, COBOL, Assembler JCL BMS/MFS IMS Gen & SQL/DDL REXX/CLIST Copybooks, Includes & Macro files
12 Why Learn Git? ▪ Better systems Improved parallel development Faster SCM tooling performance Simplified merge and faster release cycle Seamless integration into an open CI/CD pipeline Strong support for “non-linear development” ▪ Working on different parts of the application concurrently Cloud integration Supported by all modern tools/IDEs One Version Control System for both enterprise & distributed applications
▪ Career future-proofing (quotes from the Inter-webs) Companies love it when you have Git on your CV “My number one piece of advice for new developers: Learn Git and push code to GitHub every day”; Brandon Morelli I woke up one morning & realized I had to learn Linux. 13 Local Git Version Control vs. GitHub/GitLab Git is the version control tool (SCM) that tracks changes to your files Git Installs locally and manages version control and file sharing: ▪ Via a desktop interface (GUI and/or Command-line) ▪ Using a Repository to manage the history of file changes ▪ GitHub, GitLab and Bitbucket are web-based Git hosting products – which provide: A remote Git Version Control System ▪ Free space for open-source projects, “for-pay” space for private projects Features for collaborative production-quality project work: ▪ Work-item management and organizational tools ▪ Problem-tracking, Branch protection, etc.
▪ GitHub: a web-based hosting service for version control using Git. GitHub is owned by Microsoft: https://github.com/ ▪ GitLab is a cloud-based, DevOps lifecycle tool providing CI/CD pipeline features. GitLab is owned by GitLab, Inc. https://about.gitlab.com/ ▪ Bitbucket is a web-based source-control-management Repository owned by Atlassian. Bitbucket offers commercial & free Git Repository time? https://bitbucket.org 14 Local Git Repository vs. Remote GitHub/GitLab
Git GUI Interface
Git GUI Interface
Local Git repo
Git GUI Interface Git GUI Interface
Local Git repo Remote Repositories Git Remote
Local Git repo
Local Git repo 15 What is a Git Repository ? ▪ A Git Repository (“repo”) is a hidden folder named .git under the project drive:/directory that tracks changes to files This .git subdirectory contains the metadata Git uses to track file changes - building a “history of changes” over time If you delete the .git folder, then you delete your Repository
Drive/Directory File
File
File
.git subdirectory Your files Δ Your file changes… Δ Your file changes… Git repo Your files Δ Your file changes… Your files
16 How do you create a Local Git Repository ? ▪ You turn a directory into a Git Repository using the command: git init After initializing a Repository, Git creates that .git subdirectory
Drive/Directory File Drive/Directory File File File git init ➔ File File .git subdirectory Repository created/initialized to track changes to files in the Drive/Directory (also called the Working Directory)
Notes: • You can create a local Repository anywhere – including your local workstation • However, an Enterprise Git implementation is usually done from a Server • You can name your Repository using: git init
17 What is the “Working Directory”? The initialized directory is referred to as a Working Directory – some people refer to it as the “Working Tree” 1. When working on project tasks you make changes to files in the Working Directory 2. All files in the Working Directory are "untracked" by Git until you add them to the Git Repository using git add To obtain a status of the files in your Working Directory versus files committed to the Repository use the command: > git status git status On branch master
Initial commit
Untracked files: (use “git add
File1 An untracked file in the Working-Directory ➔
▪ The output of git status can be referred to as the “Working Tree status“
18 Conceptual Areas of a Git Repository
Modified Index History (Working Directory) (Staging Area) (Commit Points) “Working Tree” .git directory Your files and folders exist in one three states: 1. Modified – Files that are being edited reside in the Working Directory. This is where you add/delete/copy/edit. Files in the Working Directory are not known to Git 2. Index – Files that are ready to be committed or saved are “Staged” and added to the Git Index 3. History – Files that have been saved/committed create Commit Points in the Repository History
19 Git Source Control "Workflow"
Work Stage Commit (Working Directory) (Staging Area) (Commit Points) “Working Tree” .git directory 1. Work: You create & update files in the Working Directory using a text editor, such as: Notepad, vi/vim, IDz/ZOD Editing tools 2. Stage: You organize & prepare files to be committed using the git add command 3. Commit: You save the Staged files to the Local Repository using a git commit command
20 Command Line Git – Command Syntax ▪ Git Repositories can be accessed through a GUI/Eclipse product such as: Z Open Development or IDz – you can access Git by executing a set of commands through a Command Line Interface (CLI) The examples in this course use the Command Line Interface
▪ Git - CLI commands: Begin with the keyword: git Are case-sensitive Allow wildcards (*) - to make it easy for operations to work with sets of files Have a large number of subcommands Can use double or single quotes to enclose ‘literals’ Do not end with a punctuation/scope-terminator ▪ Basic syntax: git command
**Note: Typically in Enterprise projects you will check code out of a Git Repository and work on the code in a “branch” created for your project team 22 1. Initialize a Repository The Working Directory contains three files git init Creates an empty git repository in the Working Directory
Modified Index History Working Directory Staging Area Committed Changes
File1 File2 File3
Note that Git knows nothing about the files in the Working Directory – at this point
23 2. Configure your Name/Email for Git Commit Messages
Modify the Repository configuration git config --local user.name "Your Name" git config –-local user.email "Your eMail" Configures the repo for Commit processing messages
Modified Index History Working Directory Staging Area Committed Changes
File1 File2 File3
.git directory Repository configuration updated 24 3. Create/Modify Files in the Working Directory Most of the Git products ship with an instance of the editor known as vim (vi improved). To create or edit files with vim: At the Command Line prompt type: vim Filename $ vim Filename vim runs in two modes:
Insert mode – where you Some banner enter text in the file Line1 Normal mode – where you Line2 Type lower case i to enter Insert mode, Line3 enter vim commands (:wq, :q!) ~ then type your text into the file ~ ype or copy/paste code: ~ To t ~ Type a lower-case i to enter ~ ~ The tildes ~ denote Insert mode, then type your code ~ ~ empty records in a file The Enter key: ~ ▪ Ends the current line (CRLF) ~ ▪ Opens a new record on the next line ~ ~ Insert When you’re finished editing, Filename – other metadata … or … Mode 1. Press the Esc key – which returns vim to Normal mode 2. Type :wq An interactive vim tutorial 3. Press Enter https://www.openvim.com/tutorial.html 25 4. Stage files to the Git Repository’s Index Stage files/Prepare to save/commit git add . Adds all files in the Working Directory to the Index (Staging Area) To stage a specific file, use: git add filename
Modified Index History Working Directory Staging Area Committed Changes
File1 File1 File2 git add . File2 File3 File3 … … .git directory
26 5. Commit Files to the Git Repository’s History Commit/Save files & file changes git commit -m "Message" Commit records changes to the Repository & creates a Commit Point The Unique Hash# allows you to recover file changes to a specific Commit Point
Modified Index History Working Directory Staging Area Committed Changes
git add . git commit… File1 File1 Commit1 File2 File2 (Unique Hash#) … …
.git directory
27 6. Tell Git to Ignore Specific Files
Create a text file named: .gitignore and edit the .gitignore file. Add names of files and/or directories to omit from version control git add .gitignore to stage, then: git commit the file
You can use wildcards in the .gitignore file to include categories of files: *.zip
Modified Index History Working Directory Staging Area Committed Changes
File1 File1 Commit#2 Unique Hash# File2 File2 Commit#1 Unique Hash# … … .gitignore .gitignore Repo metadata: Config, .gitignore
.git directory 28 Git Commands used in this Section Use Case Git Diff Command Create (initialize) a local Repository git init in a directory Add your name and eMail address git config --local user.email "your.eMail" to the Repository for the purposes git config –-local user.name "your name" of annotating commit points Edit a file using the vim editor vim Filename Enter text “insert” mode ➔ i Enter vim Normal mode ➔ Esc (Escape key) Leave and save work ➔ :wq Stage a Working Directory file git add Filename Stage files in the Working Directory git add . Stage a specific file git add Filename Commit all Staged files to History git commit –m "Commit Message" (create a new Commit Point) …or… This creates a unique Hash# git commit Filename –m "CommitMessage" Create a file that tells Git to ignore vim .gitignore files in the Working Directory -- add filespec*(s) git add .gitignore git commit –m "Adding .gitignore file" 29 Labs/Workshops – Overview To do these labs you will use a Command Line Interface (CLI) to a Git Repository and development environment – ostensibly one of those mentioned at the beginning of the course Follow the steps on the next slides to: ▪ Initialize a new Git Repository in your Working Directory ▪ Create files in the Working Directory - as described in the steps Note that the default editor for the course is the vim editor ▪ vim is packaged with most Git products ▪ If you don’t know vim there are slides that will help you in these labs – There are also YouTube videos and learning resources available through Google – You will likely not use vim for your production work – so we will not spend a lot of time on it in the class ▪ If you can utilize another editor to create/modify files: Notepad, IDz/LPEX, etc. feel free to do so ▪ If you are using katacoda.com or instruqt.com – after you’ve finished the Workshops, reinforce your Git learning by utilizing the training resources associated with those sites.
30 Workshop – Open a Command Line Interface *** If you’re using GitHub for Windows or some other PC/Local Git product, you will need to create a Working Directory on your local machine: Using Windows, create a folder named: git-repo Right-Click on the folder & select: Git Bash Here This creates the CLI where you enter commands
Select Get Bash Here ➔
Right-click on the folder you want to use as a repo
*** If you’re planning to use your company’s Git server or Katacoda or Instruqt or some other environment that comes with a pre-configured Git Repository you will not create the CLI –– Please see next slide… 31 If you're using Katacoda, Instruqt or your company's Git server… If you’re using your company’s Git server, or Katacoda or Instruqt or some other environment that comes with a pre-configured Git Repository you can use the CLI in the product:
▪ If you’re using Katacoda – start here: https://www.katacoda.com/courses/git/playground
▪ If you’re using Instruqt, use: https://instruqt.com/public/tracks/create-and-clone-a-git- repository/challenges/run-git/assignment
▪ If you’re planning to use your shop’s own GitHub – you’ll need to speak with your Git Administrator(s) about getting your own “education branch” for the throw-away/workshop code you’ll create, put under version control with Git during the labs. You’ll need a clean/environment (no production files) for the workshop And you’ll be starting each section’s workshops in a clean environment with: git init Best Practice for this course: Consider signing up for Katacoda or Instruqt to do the workshops instead of using your shops Git Server
32 vim Editor Tutorial To create or edit a file: $ vim Filename At the Command Line prompt enter: vim Filename
Some banner vim operates in modes: Line1 Line2 Insert mode – where you Line3 Type lower-case i to enter enter text in the file ~ ~ Insert mode. Normal mode – where you ~ Create records in the file by enter vim commands (:wq, :q!) ~ ~ typing or copy/pasting text ~ ~ To enter records in the file: ~ ~ Type a lower-case i to enter ~ Insert mode. Type your code ~ ~ While in Insert mode you can Insert paste copied code by pressing Filename – other metadata … or … Mode the Shift+Ins keys
When you’re finished editing: The Normal mode commands you'll need Press the Esc key – to return to Quit without saving your work Normal mode :q! vim editing commands issued in Save your work, then Quit :wq Normal mode are case-sensitive Save work without Quitting 33 :w Workshop – Basic Project Steps/Workflow – 1 of 2 Do the following using the Command Line Interface to your Git environment. After each step issue a git status and note the message(s). Refer to the slides in this section for help with the Git CLI commands
1. Initialize a Git Repository – Create a Repository in the Working Directory ▪ Only do this if you don’t have an existing Repository (Do this if you're not using Katacoda or Instruqt) 2. Configure user-name/email – Allow Git to include your name, email as part of a Commit point annotation 3. Create files – Use vim to create two files in the Working Directory ▪ File1.txt and File2.txt Line1 Line4 Line2 Line5 – Add lines to each file. Similar to but not necessarily exactly like ➔ Line3 Line6 ▪ A brief vim tutorial appears in an upcoming slide File1.txt File2.txt – Recall that you can use another file editor if one is available
4. Stage files – Prepare to Commit by staging all files in the Working Directory 5. Commit the Staged files – Take a snapshot (create a Commit Point) in your Repository for your work 6. Issue a git log command Be sure that you are able to visualize the effect of each command on 34 the “conceptual areas of a Repository” Workshop – Basic Project Steps/Workflow – 2 of 2
7. Copy File1.txt twice - to create 2 new files in the Working Directory cp File1.txt File3.txt cp is a Linux copy file command cp File2.txt File4.doc
8. Issue the command: ls ls Note: File1.txtls means “File2.txtlist the files File3.txtin the current File4.doc directory”
9. What files is Git tracking? git status
10.Create a file name: .gitignore *.doc Tell Git to cease tracking: *.doc File3.* *.zip 9.Stage and commit the .gitignore file .gitignore 10.Issue the command git status What happened, and why are File3.txt & File4.doc no longer being tracked?
11.From the CLI type: ls Refer to the slides in this section Do you still see File3 & File4 files in the directory? for hints on the Git commands for each of the above Steps 35 Optional Workshop#1 – Working With COBOL Code From http://www.jsayles.com/tech/ ➔ download (Right/Click then Save As) equip.cpy to your Working Directory Repeat the above for diag.cpy – which is shown on the slide after equip.cpy If you are using Katacoda.com or Instruqt.com; 1. Save the files to your PC. 2. Open the files & Copy (Ctrl/A ➔ Ctrl/C) the content. 3. Create (vim) new files in the Git environment and Paste (Shift/Ins) the copied lines
▪ Do a git status ▪ Stage and commit both files ▪ Using vim modify equip.cpy Add a new 88-level definition ▪ Save the file and do a git status ▪ Then do a git diff What new information does diff give you?
Again, be sure that you are able to visualize the effect of each command on the “conceptual areas of a Repository”
Working Directory ➔ Index (Staged36 Files) ➔ History (Commit Points) File content – equip.cpy
01 WS-EQUIPMENT-REC. 05 EQUIP-TABLE-REC OCCURS 100 TIMES INDEXED BY ROW-IDX. 10 EQUIPMENT-ID PIC X(08). 10 EQUIP-CATEGORY PIC X(04). 88 HEATING-PAD VALUE "HEAT". 88 AUTOCLAVE VALUE "AUTO". 88 SCOPE VALUE "SCOP". 88 DRIP VALUE "DRIP". 88 MONITOR VALUE "MON ". 88 SHUNT VALUE "SHNT". 88 MISCELLANEOUS VALUE "MISC". 88 VALID-CATEGORY VALUES ARE "HEAT", "AUTO", "SCOP", "DRIP", "MON ", "SHNT", "MISC". 10 EQUIP-SHORT-DESC PIC X(25). 10 EQUIP-COST PIC 9(5)V99. 10 PRESCRIBING-PHYS PIC X(08). 10 DIAG-CDE PIC X(05). 10 EQUIP-LONG-DESCRIPTION PIC X(39).
Get from: http://www.jsayles.com/tech/
37 File content – diag.cpy
▪ ****************************************************************** ▪ * DCLGEN TABLE(DDS0001.DIAG_CODES) * ▪ * LIBRARY(DDS0001.TEST.COPYLIB(DIAGCODE)) * ▪ * ACTION(REPLACE) * ▪ * LANGUAGE(COBOL) * ▪ * QUOTE * ▪ * DBCSDELIM(NO) * ▪ * ... IS THE DCLGEN COMMAND THAT MADE THE FOLLOWING STATEMENTS * ▪ ****************************************************************** ▪ EXEC SQL DECLARE DDS0001.DIAG_CODES TABLE ▪ ( DIAG_CODE CHAR(5) NOT NULL, ▪ INS_TYPE CHAR(3) NOT NULL, ▪ COPAY SMALLINT NOT NULL, ▪ DEDUCTIBLE SMALLINT NOT NULL ▪ ) END-EXEC. ▪ ****************************************************************** ▪ * COBOL DECLARATION FOR TABLE DDS0001.DIAG_CODES * ▪ ****************************************************************** ▪ 01 DCLDIAG-CODES. ▪ 10 DIAG-CODE PIC X(5). ▪ 10 INS-TYPE PIC X(3). ▪ 10 COPAY PIC S9(4) USAGE COMP. ▪ 10 DEDUCTIBLE PIC S9(4) USAGE COMP. ▪ ****************************************************************** ▪ * THE NUMBER OF COLUMNS DESCRIBED BY THIS DECLARATION IS 4 * ▪ ****************************************************************** Get from: http://www.jsayles.com/tech/ 38 Optional Workshop#2 – Why Git Staging? ▪ git add . takes new and changed files from the Working Directory and stages them in the Repository Index - to be “pushed” using git commit ▪ Think of this “Staging Area” as a preliminary view of the your source files, at the next Commit Point in the Git Repository. (See graphic below). ▪ What this graphic does not show is that Staging can be iterative. One effective use of Staging is to fine-tune your code before Committing it ▪ This is because – typically – Commits are not reversed or deleted. Commit Points are added to the Repository’s History. So you keep staging Working Directory files until you’re ready to Commit.
Workshop: ▪ Using vim, edit File1 and make a few changes ▪ Save and do a git status ▪ Stage the changes to File1 ▪ Make a change to File2 ▪ Do a git status ▪ Stage the change to File2 ▪ Commit the staged files ▪ Do a git log
39 Review After having completed this section you should be able to: ▪ Define Git, and specify reasons for learning to use it ▪ Explain the difference(s) between Git and GitHub ▪ Define what a Git Repository is ▪ Describe the three conceptual areas of a Git Repository ▪ List the steps in a basic Git Workflow ▪ Using a Git environment/system Issue the following Git commands ▪ git init ▪ git configure user-name/email ▪ git add ▪ git commit ▪ git log ▪ Create, stage and commit a Gitignore file
40 Git – Command Reference A web-site dedicated to git syntax: https://git-scm.com/doc
41 UNIT Intro to Git - for z/OS Developers
Topics: ▪ Overview of Git – Initial Git terms, vocabulary, syntax ▪ Modifying, Staging, Comparing, Committing files ▪ Branches, Positioning and HEAD ▪ Remote Git Repositories
42 Specific topics in this section After completing this section you will be able to: ▪ Describe and the process of comparing files and file versions Between the Working Directory and Repository Between the Working Directory and Staged files ▪ Interpret the symbols and characters in a Git diff command ▪ Overwrite files in the Working Directory: From the latest Commit point From a specific Commit point Overwrite all files in the Working Directory from the latest Commit point ▪ Use the vim Editor to: Create and modify files Copy files ▪ Understand the git concept of HEAD ▪ Employ the following Git commands: diff status log show 43 Modifying Code ▪ Once you’ve added and committed code to a Git repository you’re (only) at the starting line for your project work ▪ Projects require you to: Modify code and add/commit the modified source files to the Repository Compare Git-managed files: ▪ Between the Working Directory and the Repository ▪ Between the Working Directory and Index (Staged files) Continue to commit/save files to the Repository Overlay files in the Working Directory ▪ From the current Commit point ▪ From a specific Commit point You’ll also want to examine the state of the Repository from time to time ▪ The status of files ▪ Commit point meta-data 44 Starting Point – New project, New Directory, New Repository
1. Create a new file using vim. Then put the directory under Git version control using: git init 2. Determine the Repository status: git status
Modified Index History Working Directory Staging Area Committed Changes File1 Line1 Line2 Line3
File1 created in the Working Directory Note that in order to simplify your understanding of “cause & effect” we have
45 reinitialized the existing Local Repository Stage and Commit the new file
3. Stage the file: git add . 4. Again check the Repo status: git status 5. Commit the file to the repo: git commit –-m "File1V1"
Modified Index History Working Directory Staging Area Committed Changes File1 File1 Line1 git add . Line1 git commit Commit1 Line2 Line2 (Unique Hash#) Line3 Line3 File1V1 Comment
The state of the Repository after a successful: git add & git commit
46 Change the content of the file in the Working Directory
6. Edit/Modify the file: vim File1 7. Add a new line, Delete a line, Change a line 8. Save your edits: Esc Type :wq Enter
Modified Index History Working Directory Staging Area Committed Changes File1 File1 aaaaa Line1 Commit1 Line3 Line2 (Unique Hash#) Line4 Line3 File1V1 Comment
File1 Contents Changed in the Working Directory 47 9. Confirm file changes between the Working Directory & Index
Enter: git diff git diff shows changes between files in the Working Directory & the Index
Modified Index History Working Directory Staging Area Committed Changes File1 File1 aaaaa Line1 Commit1 Line3 Line2 (Unique Hash#) Line4 Line3 File1V1 Comment
File1 Contents Changed in the Working Directory
48 9. Confirm file changes - git diff output git diff output is presented as follows…
Diff command Unix Diff command style
File Metadata
Markers for the two file versions
Hunk Header
Hunk “changes” to records in a file A hunk == a “piece of change”
Diff answers the question “What would happen if I Stage a new version of a file?” 49 9. Interpret/Understand Diff Output
Diff answers the question: “What would happen to --- a/File1 +++ b/File1 the Staged version of a file upon git add . ?” Staged (Index) version Working Directory version - prefix) + prefix
--- a/File1 Reference to the Staged version of the file +++ b/File1 Reference to the Working Directory version
--- a/File1 ➔ Staged version of File1 +++ b/File1 ➔ Working Directory version of File1
@@ -1,3 + 1,3@@) • Staged File1 will have 3 changed lines • Working Directory File1 has 3 changed lines
- Line1 ➔ Record deleted from Staged version of File1 - Line2 ➔ Record deleted from Staged version of File1
+aaaaa ➔ New record in Working Directory version of File1 Line3 ➔ Same record – in both versions Hunk
+Line4 ➔ New record in Working Directory version of File1 Changed records the in file records Changed 50 Stage the file & compare to History (Compare to current committed File1)
10. Add the Working Directory files to the Index: git add . 11. Compare files in the Index to the previous Commit: git diff --staged
11. git diff --staged
10. git add . File1v1
“What would happen to the Local Repository’s File1 History upon git commit ?”
51 Stage the file & Compare to History (Compare to current committed version)
10. Add the Working Directory files to the Index: git add . 11. Compare files in the Index to the previous Commit: git diff --staged
11. git diff --staged
10. git add . File1v1
“What would happen to the Local Repository’s History of File1 upon git commit ?” git diff –-staged
Used to compare Index (Staged file) version to previous 52 commit point in History Compare the Working Directory Version to the (Latest) Commit
Enter the following command: git diff HEAD Compares the Working Directory version of a file to the latest committed version
Modified Index History Working Directory Staging Area Committed Changes File1 File1 Commit1 aaaaa aaaaa (Unique Hash#) Line3 Line3 File1V1 Comment Line4 Line4
53 Commit the Staged Files - View the Repository Status using git log
12. Commit the Staged files: git commit –m "File1V2" 13. Obtain a status of the Repository’s Commits: git log
git commit…
Current commit
git log File1v2
Prior commit
File1v1
54 Commit Staged files - View the Repository’s status using git show
git log displays the commit author, hash# and message To view that plus file changes made between the current & previous commit use: git show
Current commit log
git show
Diff between Commit Points in History: • Current • Prior git show provides a Diff between the
55 last two commit points HEAD~n An Option for Diff between Specific Commit Points
git log returns a list of all $ git log commit c1a11e6a98cd404e230ba70cb529fb (HEAD -> master) Commit Points in the Repository History Author: Jon
different Commit Points in one of Commit File3 two ways: commit 05169171a0f6137133e5842bf54ab51fa11267ec 1. Reference the Hash# unique Author: Jon
HEAD ➔ Latest Commit Point HEAD~2 Commit HEAD~1 ➔ Previous Commit Point File2 HEAD~2 ➔ Previous Commit Point HEAD~3 ➔ Previous Commit Point commit a206fdd0d596010183ae15f4c37d7de0269eb986 … Author: Jon
Note that relative referencing HEAD~3 with the HEAD pointer is similar Commit File1 to the relative DSN(0) (-1) (-2) notation for z/OS GDG Datasets 56 $ git diff HEAD HEAD~2 -- File1 git diff HEAD HEAD~n diff --git a/File1 b/File1 index e4be987..66328ee 100644 --- a/File1 git diff HEAD HEAD~2 –- File1 +++ b/File1 @@ -1,4 +1,3 @@ Two dashes w/space before & after Line1a Line3 -Line4a -Line5 +Line4
Compare a copy of File1 from the most recent Commit Point to a copy two Commit Points back in History
57 Hash#s Another Option for Diff between Specific Commit Points Compare a copy of File1 from the most recent Commit Point to a copy in History using unique Hash numbers git log $ git log commit 94750e922d1cf68244ae745afd86ba311c0bce43 (HEAD -> master) Author: Jon
known as Sha-1 hashes File3
commit 05169171a0f6137133e5842bf54ab51fa11267ec Author: Jon
File2V2 git diff 94750 051691 –- File1 commit 2c558a16003b39be4718c06e8d3bf51b9b42ca6d Author: Jon
File2
commit a206fdd0d596010183ae15f4c37d7de0269eb986 Author: Jon
File1
58 Summary – Git Diff Options Use Case Git Diff Command Compare all files in the Working Tree with git diff their staged version in the Index Compare a specific file in the Working Tree git diff Filename with its staged version in the Index Compare Index with Commit Point git diff --staged Compare all files in the Working Tree with git diff HEAD all files in the current Commit Point Compare a specific file in the Working Tree git diff HEAD~n – Filename with a specific Commit Point version of the file Compare a specific file at two different git diff HEAD HEAD~n –- Filename Commit Points in History …or… • Relative HEAD~n git diff Hash# Hash# -- Filename • Specific Sha-1 Hash# • Get a list of all files that have been git log committed up to a given Hash# git ls-tree --name-only -r Hash# • Reference to the current commit point HEAD in the Repository History
59 Workshop – Resetting the Repository/Environment In order for you to understand “cause & effect” from the material & workshops in this section you should reset your environment – effectively deleting the Repository you created & built out in the previous section: ▪ If you’re using GitHub for Windows or some other PC/Local Git product, you will need to create a Working Directory on your local machine: ▪ Using Windows, delete the git-repo folder – then (just as you did for the first Section) create a new folder named: git-repo – Note that deleting the folder effectively deletes the Repository ▪ Right-Click on the folder & select: Git Bash Here
▪ If you’re using Katacoda, just close & reopen this link: https://www.katacoda.com/courses/git/playground
▪ If you’re using Instruqt close & reopen the link to the sandbox: https://instruqt.com/public/tracks/create-and-clone-a-git-repository/challenges/run-git/assignment
60 Workshop 2 – Project Walk-Thru with Git – 1 of 2 Setup and review:
1. Create a new file named File1 using vim If you need help, return to the slide titled: Use vim to Create and Modify files ▪ Create and save this text file
2. Put the directory under version control using: git init
3. Determine the project’s version control status: git status
4. Stage the file: git add .
5. Commit the file to the Repository: git commit –-m "FileV1"
As you are working through the above steps, be sure that you visualize what’s happening in the Working Directory, in the Index and the Repository History
61 Workshop 2 – Project Walk-Thru with Git – 2 of 2 6. Edit/Modify the file: vim File1 Use the techniques shown on the slide titled: Use vim to Create and Modify files 1. Change a line 2. Delete a line Use the Backspace key to Delete a line 3. Add a line 4. Save changes Note that you can change text to anything you want, but you will need to verify Git Diff 7. Compare the version of File1 in the Working Directory against the File1 version in the Index: git diff ▪ Make sure that you understand the different output messages Refer to the slide(s) titled: 9. Interpret/Understand Git Diff Output
8. Stage all of the Working Directory files
9. Commit the Staged file and then run: git show – What does git show do? 10. Compare Staged files to the most recent Commit: git diff --staged
62 Optional Workshop – Comparing Committed and Staged File Commands 1. Create a new file in the Working Directory named: File2 2. Run git status – and note the messages 3. Stage and Commit your new file with an appropriate message: git commit File2 -m "CommitFile2" 4. Modify both files (File1 & File2) in the Working Directory It doesn’t matter what records you change 5. Run git status – and (again) note the messages 6. Run git diff – note that text both files are compared 7. Stage and Commit all files in the Working Directory 8. Run git log – and note the Hash#s for your commit points 9. Run a git diff between the current and previous Commit Points, using both: Relative HEAD~n and specific Hash#s to differentiate Commit Points
63 Optional Workshop – New & Exciting Git Commands to Experiment With 1. Run the following new Git commands: git log –-name-only git ls-tree –-name-only master 2. Note the new SCM behaviors & features exercised. 3. Use Google to figure out what these commands do 4. Create a new file named: File3 5. Run: ls git ls-files -s 6. Stage all of the files in the Working Directory 7. Run the following – if you can’t tell what each command does Google it: git ls-files –s git ls-tree –-name-only master git log git ls-tree --name-only -r
64 Optional Workshop – Use your own programs with Git Merge Note that if you are using Katacoda.com or Instruqt.com you may need to consider corporate Intellectual capital and/or Legal concerns before doing this workshop. ▪ Use your own programs with git: Delete your Git Repository and recreate it (git init) Launch IDz and from a Test LPAR, open (browse or edit) one of your copybooks or programs ▪ Select & copy the code ▪ Paste the copied code into a new file (named anything you want) in the Git environment Add and Commit this file Edit/Modify the file in the Working Directory and make a few changes to the source Reconcile (git diff) the changes you’ve made between the Working Directory & Repository History (committed) version your file
▪ If your shop allows access to YouTube, watch David Mahler’s video on Git Core Concepts: https://www.youtube.com/watch?v=uR6G2v_WsRA&list=PLf6wuaD-31jdZRVA-YuHWAgiVykP_Si56 ▪ If you are using Katacoda.com or instruqt.com find and complete the associated lesson for Branching & Merging
65 Section Review Having completed this section you should be able to: ▪ Describe and the process of comparing files and file versions Between the Working Directory and Repository Between the Working Directory and Staged files ▪ Interpret the symbols and characters in a Git diff command ▪ Overwrite files in the Working Directory: From the latest Commit point From a specific Commit point Overwrite all files in the Working Directory from the latest Commit point ▪ Use the vim Editor to: Create, modify files and save files Copy files ▪ Employ the following Git commands: diff status log show
66 UNIT Intro to Git - for z/OS Developers
Topics: ▪ Overview of Git – Initial Git terms, vocabulary, syntax ▪ Comparing, working with and committing files ▪ Branches, Positioning and the HEAD Pointer ▪ Remote Git Repositories
As an introduction to Git for ISPF developers we have simplified concepts throughout the course. At no point will this be more apparent than in this section – especially Git Merge. Merge is the subject of many published white papers & YouTube videos. And while, if you’re a developer the material presented here is a good start, if you intend to work as a Git Server administrator you will be well-served to research Git Merge beyond what is presented in this course.
67 Specific topics in this section After completing this section you will be able to: ▪ Define Git branches What they are How they’re used in a project lifecycle How to create, switch to, and delete branches How to do Git Repo work from within a branch ▪ Define what the "master" branch is - and how it's created ▪ Describe the use of the HEAD pointer ▪ Merge code in branches - using: Fast-Forward 3-Way Merge ▪ Handle conflicts that arise from merge operations
68 What is a Git Branch? ▪ Physically: A Git branch is a named pointer to a Commit Point in the Repository History ▪ Use in your Project/Workflow: A git branch represents a separate line of development – independent from the default (master) baseline/branch you’ve used so far in this class At the time of creation, a branch has addressability to all of the code at the latest Commit Point Branches allow you to isolate code revisions and do parallel development without affecting the broader team ▪ You can think of them as providing a new: Working Directory, Index (Staging Area), Project History (Commits) – basically the concept of a “sandbox” ▪ You’ve seen the term “master” in earlier sections. master is the first branch in a Repository: master is a default branch, automatically created by Git upon the first Commit Often, but not always, custom project branches are created off master master Test
Rel. 2.1 Rel. 2.2 69 More - about the use of Branches? ▪ Branches are a key element in the Git software control system They allow you to work on different versions of the same files Your edits on one branch are independent from work in other branches ▪ Allowing you to have branches for different purposes – Prototyping – Hot-Fixes for production – Different release cycles You can merge branches back into master on a case-by-case basis ▪ Branches are sometimes created to model different lifecycle stages in your development architecture: Sandbox Dev Test QA ("Hot Fix") - etc. ▪ You can also create what are known as “feature branches” for your own prototyping or development requirements Assuming that you have the necessary Git Server permissions 70 Visualizing Branches & Commit Points Because branches are "references to commit points" they are often depicted visually using what is called a “Commit Graph”
Legend
Commit Point: 49163 Files and File1, File2 Commit Points
dev Branches master Latest HEAD Commit Point 71 The HEAD Pointer HEAD is a special pointer that references the current "checked-out" branch. When you do a git checkout to a branch, the HEAD pointer moves to that branch. You develop in that branch and your file revisions, staging and commits occur in that branch until you checkout*** to another branch
File1, File2 master HEAD Commit Point: 751043
File1, File2 Commit Point: 1389d4
dev File1, File2
Commit Point: 49163
File1, File2 Commit Point: 6829d3
*** In some SCMs, the term checkout means to pull/copy file(s) out of an SCM Repository. Git checkout simply moves the HEAD pointer to a specific branch. In Git, all branches have access to all files in File1 Commit Point: f989d3 the Repository at the time the branch is created. 72 Setup – Workflow for Git Branching
1. Create a new Repository git init 2. Create File1: vim File1 abc 3. Add and Commit File1: git add File1 ; git commit –m "Add File1" 4. Copy File1 to File2: cp File1 File2 5. Add and Commit File2: git add File1 ; git commit –m "Add File2" 6. git log – then create the following alias: alias graph="git log --all --decorate --oneline --graph" $ graph
Commit Point: dd39ebe File1, File2 master HEAD
Commit Point: dd39ebe File1 So far, master is the first and only branch in this scenario. Note also that HEAD points
73 to master at the latest commit. Creating Git Branches in our Workflow git branch
$ git branch dev Define two new branches: dev & qa ➔ $ git branch qa git branch lists the current branches in the Repository $ git branch dev The * asterisk denotes the current “checked out” branch * master Note that the HEAD pointer is still pointing to the master branch qa
Issue the graph command. Note that all three branches point to the same Commit
74 Checkout – to Git Branches git checkout
This statement allows you to work with code in a branch ▪ Edit files, and use the git add/commit commands as shown previously git checkout dev $ git checkout dev Switched to branch 'dev’
$ graph * dd39ebe (HEAD -> dev, qa, master) Add File2 * 9df7657 Add File1
$ git status On branch dev…
qa
Commit Point: dd39ebe File1, File2 master
dev HEAD
Commit Point: dd39ebe File1 checkout moves HEAD to a new branch 75 Workflow – $ git checkout dev Develop, Stage & Commit in dev Switched to branch 'dev' $ graph git checkout dev * dd39ebe (HEAD -> dev, qa, master) Add File2 graph • 9df7657 Add File1 HEAD now cat File1 $ cat File1 abc points to dev vim File1 ➔ Line1 Modify File1 Line2 $ vim File1 Line3 $ git add File1 Add new lines… Line4 $ git commit -m "dev for File1" git add File1 [dev 55ce1ab] dev for File1 git commit –m "dev for File1" 1 file changed, 4 insertions(+), 1 deletion(-) graph $ graph * 55ce1ab (HEAD -> dev) dev for File1 * dd39ebe (qa, master) Add File2 * 9df7657 Add File1
New Commit in dev
76 Workflow – Develop, Stage & Commit in qa $ git checkout qa 1 of 2 Switched to branch 'qa' $ git branch git checkout qa dev master git branch * qa graph $ graph * 55ce1ab (dev) dev for File1 * dd39ebe (HEAD -> qa, master) Add File2 * 9df7657 Add File1 (qa) cat File1 $ cat File1 abc abc $ git checkout dev Switched to branch 'dev' git checkout dev $ cat File1 Line1 cat File1 line1 Line2 line2 LIne3 line3 Line4 Line4
$ git checkout qa Switched to branch ‘qa' git checkout qa $ vim File1 vim File1 Line1 $ cat File1 Line2a Line1 cat File1 Line3 Line2a Line3 Line4 Line4 Line5 Line5 77 Workflow - Develop, Stage & Commit in qa – 2 of 2 git checkout qa git add File1 ; git commit –m "qa for File1" graph
HEAD qa File1, File2 File1, File2 dev Commit Point: 55cela Commit Point: c104702
File1, File2 master Commit Point: dd39ebe
Commit Point: dd39ebe File1 78 Integrating File Changes in Different Branches – Merge ▪ Isolating development program features & even development cycles (Prod, QA, Test, etc.) into different branches is a crucial practice for any z/OS Enterprise.
▪ By separating code content, fixes, function points, etc. you avoid problems and keep your development environment – as represented by the git branches off of master – clean.
▪ Ultimately, code in branches that has passed quality measures must be integrated back into the project. This is what git merge does. The result of Git Merge is a single collection of files that contains changes from different branches
79 Integrating File Changes from different Branches – Merge Options To integrate the committed file changes you’ve made in qa & dev into master you do a git merge Merge comes in two flavors: 1. Fast Forward Merge: When Git can move branch pointers directly from one commit point to another it will do a Fast Forward Merge 2. Three-Way Merge: When Git needs to merge changes from (divergent) commit points it will perform a Three-Way Merge, so as to not lose committed work from any of the branches
HEAD
80 Fast Forward Merge When you merge a new commit point with an older commit point that can be reached (directly) by following the parent commit’s history, Git moves master and HEAD forward to the new commit point This is called a Fast-Forward Merge $ git checkout master $ git merge dev
Commit Point: 55celab dev qa File1, File2 File1, File2 master HEAD Commit Point: c10470
File1, File2 Commit Point: dd39ebe
File1 Commit Point: dd39ebe
After the Fast Forward merge, File1 & File2 will have the contents as of Commit Point: 55celab 81 Workflow – Fast Forward Merge Switch to the master branch ➔ $ git checkout master $ git merge dev Fast-Forward merge➔ Updating dd39ebe..55ce1ab Fast-forward File1 | 5 ++++- File1 modifications ➔ 1 file changed, 4 insertions(+), 1 deletion(-) $ graph HEAD, master & dev all point * c104702 (qa) qa for File1 to the same commit➔ | * 55ce1ab (HEAD -> master, dev) dev for File1 |/ * dd39ebe Add File2 • 9df7657 Add File1
Contents of File1 after $ cat File1 Fast Forward Merge ➔ line1 line2 line3 line4
82 Three-Way Merge In a Three-Way Merge Git uses three commits to generate the merge – incorporating changes from the target branch into the current branch – using: 1. Current branch 2. Target branch 3. Starting from the ancestor commit point for both branches
dev 2. File1, File2 File1, File2 1. master qa Commit dev Commit HEAD Divergent Branch 3. File1, File2 master (ancestor) Commit
In the above Three-Way Merge, Git cannot do File1 a Fast-Forward Merge, because you would lose dev Commit/changes 83 Three-Way Merge – File & Record Conflicts There is a high potential for merge conflicts in Three-Way Merges, and you will have to manually evaluate discrepancies. So we will create a new (clean) Repository and utilize a simplified version of the equip.cpy (copybook) to better show the Merge process
01 WS-EQUIPMENT-REC. 05 EQUIP-TABLE-REC OCCURS 100 TIMES INDEXED BY ROW-IDX. 10 EQUIPMENT-ID PIC X(08). 10 EQUIP-CATEGORY PIC X(04). 88 HEATING-PAD VALUE "HEAT". 88 MONITOR VALUE "MON ". 88 SHUNT VALUE "SHNT". 88 MISCELLANEOUS VALUE "MISC". 10 EQUIP-COST PIC 9(5)V99. 10 PRESCRIBING-PHYS PIC X(08). 10 DIAG-CDE PIC X(05). 10 EQUIP-LONG-DESCRIPTION PIC X(39).
84 Three-Way Merge – with File/Record Conflicts In this example, we'll use 3 different versions of equip.cpy – with different modifications - on three different branches:
qa dev master 01 WS-EQUIPMENT-REC. 05 EQUIP-TABLE-REC OCCURS 100 TIMES. 10 EQUIPMENT-ID PIC X(08). 10 EQUIP-CATEGORY PIC X(04). 88 HEATING-PAD VALUE "HEAT". 88 MONITOR VALUE "MON ". 88 SHUNT VALUE "SHNT". 88 MISCELLANEOUS VALUE "MISC". 10 EQUIP-COST PIC 9(5)V99. 10 PRESCRIBING-PHYS PIC X(08). 10 DIAG-CDE PIC X(05). 10 EQUIP-LONG-DESCRIPTION PIC X(39).
85 Workflow & Fast Forward Merge– master/dev branches equip.cpy master $ git init 01 WS-EQUIPMENT-REC. 05 EQUIP-TABLE-REC OCCURS 100 TIMES. $ vim equip.cpy 10 EQUIPMENT-ID PIC X(08). $ git add . 10 EQUIP-CATEGORY PIC X(04). 88 HEATING-PAD VALUE "HEAT". $ git commit -m "equip.cpy master" 88 MONITOR VALUE "MON ". 88 SHUNT VALUE "SHNT". $ git branch dev 88 MISCELLANEOUS VALUE "MISC". 10 EQUIP-COST PIC 9(5)V99. $ git branch qa 10 PRESCRIBING-PHYS PIC X(08). $ git checkout dev 10 DIAG-CDE PIC X(05). 10 EQUIP-LONG-DESCRIPTION PIC X(39). $ vim equip.cpy $ git add . dev $ git commit -m "equip.cpy dev" Work in dev branch $ git checkout qa $ vim equip.cpy $ git add . $ git commit -m "equip.cpy qa" Work in qa branch $ git checkout master $ git merge dev Fast-Forward Merge qa
86 $ git checkout master Three-Way Merge $ git merge qa CONFLICT (content): Merge conflict in equip.cpy Automatic merge failed; fix conflicts… $ git status On branch master You have unmerged paths. (fix conflicts and run "git commit") (use "git merge --abort" to abort … Unmerged paths: (use "git add
both modified: equip.cpy
no changes added to commit (use "git add“…
$ vim equip.cpy
Fix Merge conflicts $ git add . $ git commit -m "equip.cpy 3-way Merge" To fix this merge conflict: 1. Edit the copy in master • Resolve source conflicts 2. git add . 3. git commit 87 Resolve Merge Conflicts
<<<<<<< HEAD (currently points to master) branch indicator ➔ Changed line in master branch commit➔ ======Separator for branch conflicts ➔ Changed line in qa branch commit ➔ >>>>>>> qa branch indicator➔
<<<<<<< HEAD - master branch indicator ➔ Changed lines in master branch commit➔
======Separator for branch conflicts ➔ Changed lines in qa branch commit ➔
>>>>>>> qa branch indicator➔
Accept/Reject branch changes Delete Merge markers Save changes $ git add . $ git commit –m "Msg"
88 Deleting Branches When you are finished with a branch you can delete it using: git branch –d
$ git branch –d qa Error: The branch ‘qa’ is not fully merged. If you are sure you want to delete it, run ‘git branch –D qa’.
Notes: ▪ Uppercase -D forces Git to delete the branch Losing whatever files & file work that’s gone down – on that particular branch ▪ Using –D could result in a loss of un-committed but meaningful branch-content
89 Summary – Git Branch/Merge Commands Use Case Git Diff Command Create a new branch/commit point git branch
Delete a branch git branch –d
Cancel a Merge operation git merge --abort
90 Workshop – Resetting the Repository/Environment In order for you to understand “cause & effect” from the material & workshops in this section you should reset your environment – effectively deleting the Repository you created & built out in the previous section: ▪ If you’re using GitHub for Windows or some other PC/Local Git product, you will need to create a Working Directory on your local machine: ▪ Using Windows, delete the git-repo folder – then (just as you did for the first Section) create a new folder named: git-repo – Note that deleting the folder effectively deletes the Repository ▪ Right-Click on the folder & select: Git Bash Here
▪ If you’re using Katacoda, just close & reopen this link: https://www.katacoda.com/courses/git/playground
▪ If you’re using Instruqt close & reopen the link to the sandbox: https://instruqt.com/public/tracks/create-and-clone-a-git-repository/challenges/run-git/assignment
91 Workshop – Create branches off of master 1. Create a new Repository in your Git CLI environment 2. Create File1 – add some content to it; A line or two of simple text 3. After saving File1, in single command, add and commit File1 $ git add File1 ; git commit –m "File1V1" 4. Create the following Linux alias to graph the Repository state: alias graph="git log --all --decorate --oneline --graph" 5. Issue the graph command 6. Create two new branches; Name them whatever you’d like 7. git checkout (select) one of your branches 8. In the branch you’ve checked out, edit File1 – Notice the initial file contents 9. Make a few source modifications: Add a line, change a line, delete a line 10. Add and commit File1 – then issue the graph command 11. git checkout to your other (new) branch 12. Edit File1 from that branch – Again note: The contents == original master branch 13. Make a few source modifications: Add a line, change and delete a line 14. Add and commit File1 – then issue the graph command 15. Issue the command: git diff master:File1
92 Workshop – Merge branches and Manage Conflicts 16. Make sure that you understand the previous Diff report 17. Checkout to master then issue the graph command Note where HEAD is now pointing 18. Merge one of your branches 19. Issue a read-only/browse (cat) of File1 Verify the Fast Forward Merge 20. Merge your other branch – Note that the merge will not succeed 21. Do a git status – Understand the problem & read the Git directions 22. Edit File1 and fix the Merge conflicts: Read the Git Merge Markers. If you need help understanding the annotations review the slide in this section titled “Resolve Merge Conflicts” Edit (clean-up) the marked File1: ▪ Decide which conflict-lines to keep/delete ▪ Delete the Git Merge Markers ▪ Save your changes 23. Do a: git branch merged command
24. Add and Commit File1 93 25. Delete both of your branches Optional Workshop – Use your own programs with Git Merge Note that if you are using Katacoda.com or Instruqt.com you may need to consider corporate Intellectual capital and/or Legal concerns before doing this workshop. ▪ Use your own programs with git Delete your Git Repository and recreate it (git init) Create a few new branches off of master – then: ▪ Launch IDz and from a Test LPAR, open (browse or edit) one of your copybooks or programs. Select & copy the code. Paste the copied code into a new file in the Git master branch Repeat all of the steps from the Workshop slides in this section, beginning with step #4
Reconcile the changes you’ve made in the branches with the Git Merge messages
▪ If your shop allows access to YouTube, watch David Mahler’s video on Git Branching: https://www.youtube.com/watch?v=uR6G2v_WsRA&list=PLf6wuaD-31jdZRVA-YuHWAgiVykP_Si56&index=1 ▪ If you are using Katacoda.com or instruqt.com find and complete the associated lesson for Branching & Merging
94 Review – Git Branching and Merging Having completing this section you should be able to: ▪ Define Git branches What they are How they’re used in a project lifecycle How to create, switch to, and delete branches How to do Git Repo work from within a branch ▪ Define what the "master" branch is - and how it's created ▪ Describe the use of the HEAD pointer ▪ Merge code in branches - using: Fast-Forward 3-Way Merge ▪ Handle conflicts that arise from merge operations
95 UNIT Intro to Git - for z/OS Developers
Topics: ▪ Overview of Git – Initial Git terms, vocabulary, syntax ▪ Comparing, working with and committing files ▪ Branches, Positioning and HEAD ▪ Working with Remote Git Repositories
96 Specific topics in this section After completing this section you will be able to: ▪ Define a Remote Git Repository What they are (options) How they’re used in a project lifecycle How to do Git Repo work from within a branch ▪ Clone the GitHub Remote Repository to a local Git instance ▪ Make changes to the Remote Repository And fetch the changes to your local Git Repo ▪ Make changes on your local Git Repo Then push the changes to the Remote Repository ▪ Forking Fork versus Clone
97 What is a Remote? Technically: A Remote is simply a Repository in another location from the Local Git Repository you’re currently working in ▪ Web-Based hosting service: – GitHub, GitLab, Bitbucket, etc. ▪ Co-worker’s laptop ▪ Corporate Git Server ▪ Another Repository on your laptop Practically: A Remote is a community Git Repository that your project uses to share & exchange source and code modifications. In most cases, a remote Repository is stored on a code hosting service like GitLab/GitHub/Bitbucket or it could be an internal server at your company
98 Remote Repository – Options GitHub GitLab Repository … Repository Commit3 Repository Commit2Repository Commit3 Repository Commit3 Commit1 Commit2 Repository Commit3 Commit3 Commit1Commit2 Commit3 Commit2 Commit1 Commit2 Commit1Commit2 Repository on your laptop Commit1 Commit1
Repository Repository Commit3 Commit3 Commit2 Commit2 Commit1 Commit1
Repository a colleague’s laptop
Corporate Git Repository 99 Local vs. Remote Repository ▪ Local Git Repositories reside on your team’s PCs In contrast, Remote Repositories are hosted on a server that is accessible to all team members - most likely on the internet or on a local network.
▪ Local vs. Remote Repository Feature Set A Remote Repository doesn't differ from a local Repository – it has: ▪ Files, Branches ▪ Staging (Index), Commits However, a local repository has a Working Directory ▪ This is where some version of your project files are checked out - and where you're working ▪ A Remote Repository doesn't have a working directory. It consists of a .git repository folder
▪ You can think of a Remote Repository like a "file server" a means of sharing and exchanging code among your project team
▪ Typical usage/workflow: You start by downloading a copy of the Remote Repository to your local Repository – using git clone Your project work happens only in your local repository ▪ All modifications are made, staged & committed locally ▪ Changes can be uploaded to a Remote Repository
100 Git Commands to Work With Remote Repositories
git clone Remote Repository ▪ Replicate (take a snapshot) of a Remote Commit3 Repository as a working copy on your laptop Commit2 git fetch Commit1 ▪ Update your Local Repository with source git push changes from the Remote Repository git clone git merge git fetch ▪ Update your Snapshot Directory with git merge fetched updates from the Remote Repository git push ▪ Uploads current the latest commit points from your Local Repository (current HEAD pointer) to its Remote counterpart branches
There are a few other options for working with Remotes (notably git pull). But we will use the above set of commands - Local Repository which some professionals consider "Best Practices" 101 Working with Remotes – A Typical Workflow 1. Create a Remote Repository*** Populate it with code 2. Clone the Repository Verify the Remote Repository Terms & Concepts 3. Configure user.email/user.name in Local Repo Understand Remote Repo terminology 4. Modify the Remote Repository 5. Fetch/Merge the Remote changes locally 6. Update the copy in the Local Repository Stage ➔ Commit 7. Push the Local commit to the Remote Repository
*** Note that when working with your production code
102 Workflow – 1. Create a Remote Repository on GitHub
1. Create a GitHub account: jsguitargeek 2. Create a Remote Repository: hosp 3. Add code (uploaded files) https://github.com/
GitHub created master branch
103 2. Clone a Remote Repository – Syntax
Local Repository Remote Repository Commit1 Commit1 GitHub CDAT1.cbl CDAT2.cbl
Local Laptop
git clone https://github.com/jsguitargeek/hosp.git
104 2. Clone a Remote Repository – CLI
Commit1
hosp Jsguitargeek/hosp
$ git clone https://github.com/jsguitargeek/hosp.git Cloning into 'hosp'... remote: Enumerating objects: 4, done. remote: Counting objects: 100% (4/4), done. remote: Compressing objects: 100% (4/4), done. remote: Total 4 (delta 0), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (4/4), done.
105 2. Clone a Remote Repository – What Just Happened? After a successful git clone Git created a new subdirectory named: hosp on your laptop, and: ▪ Downloaded the files from GitHub to the folder jsguitargeek/hosp is pointed to as a Remote Repository from your local Repository ▪ You can git fetch updates from GitHub when changes are made in the Remote Repository ▪ You can git push updates from your local Repository to GitHub Created a new (remote) branch named: origin (default name for Remote Repository) ▪ Verified by using : git remote -v $ cd hosp $ ls CDAT1.cbl CDAT2.cbl $ git remote origin $ git remote -v git fetch & origin https://github.com/jsguitargeek/hosp.git (fetch) git push to origin origin https://github.com/jsguitargeek/hosp.git (push) resolve to this GitHub URL hosp
106 Workflow – 3. Housekeeping & Graphing the Remote Do this only if you're Configure your user.email & user.name using Katacoda.com or Instruqt.com Create the Alias to graph the Commits and Branches
$ git config --local user.email "[email protected]" $ git config --local user.name "Jon"
$ alias graph='git log --decorate --all --oneline --graph'
$ graph * fcc1851 (HEAD -> master, origin/master, origin/HEAD) Add files via upload
Single Commit|Pointer to master | Remote Tracking | Reference representing Hash# | which is checked | branch | a local copy of the HEAD Pointer GitHub | out | | in the Remote Repository graph tells us that: 1. master is the current Local branch 2. origin/master is the name of a Remote Tracking Branch 3. The Remote master and Local master branches are in-synch • They're pointing to the same Commit
107 Workflow – 4. Modify the Remote Repository From GitHub: Upload CDAT3.cbl Commit
108 5. Git Fetch Remote Changes git fetch Before git fetch origin Local Git does not automatically track remote changes in origin $ git status On branch master Your branch is up to date with 'origin/master'. nothing to commit, working tree clean
$ git fetch origin remote: Enumerating objects: 4, done. remote: Counting objects: 100% (4/4), done. remote: Compressing objects: 100% (3/3), done. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (3/3), done. From https://github.com/jsguitargeek/hosp fcc1851..7fde9f6 master -> origin/master $ git status On branch master Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded. (use "git pull" to update your local branch)
$ graph * 7fde9f6 (origin/master, origin/HEAD) Add files via upload * fcc1851 (HEAD -> master) Add files via upload After git fetch origin Git finds the new Remote/Commit & brings it down to the Working Directory 109 Git Merge With Remotes As a result of the git fetch graph shows two commits:
7fde9f6 – New commit on GitHub fcc1851 – Local – still on previous commit Downloads remote commit point data, but places it in a reserved location. git merge the commit point referenced by origin/master – into the Local Commit Point $ ls CDAT1.cbl CDAT2.cbl $ git merge origin/master Updating fcc1851..7fde9f6 Fast-forward CDAT3.cbl | 111 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 111 insertions(+) create mode 100644 CDAT3.cbl
$ graph * 7fde9f6 (HEAD -> master, origin/master, origin/HEAD) Add files via upload * fcc1851 Add files via upload Now Local is caught up and points to the same commit 110 Working With Remotes – Review
Local Repository
3. Both origin/master & Local HEAD 5. GitHub ➔ Commit2 GitHub git merge
origin/master ➔ Commit2 git fetch … Commit2 Upload Local HEAD ➔ Commit1 CDAT3.cbl 4. 3.
origin/master & Local HEAD ➔ Commit1 GitHub git clone … Commit1 Upload CDAT1.cbl 2. 1. CDAT2.cbl
Local Laptop origin/master == “Remote Tracking Branch” 111 Workflow – 6. Update the copy in the Local Repository Edit your local copy of CDAT1.cbl – and make source code changes $ vim CDAT1.cbl
$ git commit -a -m "CDAT1 Revision" [master b244faa] CDAT1 Revision 1 file changed, 4 insertions(+), 4 deletions(-) Commit the changes using a single line: git commit –a –m "xxxx"
112 Workflow – 6. Push Local Commit to origin/master $ graph After previous commit – and before git push… * b244faa (HEAD -> master) CDAT1 Revision • New Local Commit (b244faa) * 7fde9f6 (origin/master, origin/HEAD) Add files via upload • Pointer to GitHub Repository commits * fcc1851 Add files via upload unchanged $ git status git status shows messages about current On branch master branch being “ahead” of Remote (origin/master) Your branch is ahead of 'origin/master' by 1 commit. (use "git push" to publish your local commits)
$ git push origin master Counting objects: 3, done. Delta compression using up to 8 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 360 bytes | 360.00 KiB/s, done. Total 3 (delta 1), reused 0 (delta 0) remote: Resolving deltas: 100% (1/1), completed with 1 local object. To https://github.com/jsguitargeek/hosp.git 7fde9f6..b244faa master -> master $ git status On branch master After git push origin master Your branch is up to date with 'origin/master'. • Local and GitHub Repository pointers nothing to commit, working tree clean in synch
113 GitHub – After git push origin master
(New) Local Commit and push to origin/master reflected
114 Backup Slides
115 DevOps Acceleration Program - Overview
The program is a no-charge IBM service, a "jump-start" designed to assist shops with "z/DevOps in the real world" • Assessment of the "current state" of your DevOps client & server • A hands-on product workshop, where you & your development staff work in a z/DevOps environment: • Tools and functionality • Architecture • Process • Assistance for product deployment • A migration approach (tools & techniques) and an initial/representative migration of your code from an existing monolithic SCM model to an Agile/Distributed model • Knowledge transfer for all of the above
• Public DBB Community on GitHub: Steps: Contact your IBM’s Sales representative or • https://github.com/ibm/dbb Email directly to: Jay Manickam: [email protected]
• Migration best practices White Paper: • http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102772 • Z Trial - an open environment for hands-on experience: • https://www.ibm.com/it-infrastructure/z/resources/trial
116