Mitch Hoffman

All right, let’s go ahead and kick this off. Here we go. Welcome, everyone. Thank you for joining us for Git demystified true modern DevOps tooling for IBM i developers. As experienced IBM i organizations, you’ve likely heard about adopting Git and modern DevOps corporate standards like GitHub and Azure DevOps GitLab pipelines. Jenkins but is that really a fit for the unique requirements of the IBM i platform? Well, today we have the right person to answer that question. Our speaker, Dan Maggot, is an IBM i evangelist and CEO of Eradani, the makers of Eradani Connect, the API integration software, and Eradani DevOps, the one repo, enterprise wide DevOps solution for IBM i. He’ll start off slow and then get very technical. This session is being recorded and will be sent out to you to everybody who’s registered, along with Dan’s slides and responses to any questions we can’t get to in time. Please ask your questions using the Zoom, Q and A feature. It’s the button at the bottom. And Dan and I will respond to as many as possible during the event or in the last ten minutes. Now let’s shine some light on using Git for IBM i. Dan, over to you.

Dan Magid

Sounds great. Thanks, Mitch. Yeah, I’m really excited by the response we’ve had for this webinar. We have people from all over the world. So good morning, good afternoon, or good evening, depending on where you are. The reason we’re doing this is that I’ve been working with a lot of IBM i customers who have had corporate mandates where they need to use git for all of their code, including their IBM i code, or they’ve heard a lot about git and they want to start using git and it looks very exciting at first, and then they actually get into start to use it and find that it works differently than what they’re used to. It doesn’t work the same way as things typically work on the IBM i. So what I wanted to do is get into a little bit about how Git works, how it’s different than the IBM i, so that we can start to introduce IBM i users to working in the way that Git is designed to work. And so we’re going to start out, talk a little bit about why would you want to do this? Why go through the trouble of learning this new thing? And then we’ll talk about that Git architecture and the terminology that’s used in the Git environment. What’s different about Git and the IBM i? So what’s different about how you do things in Git versus how we’ve been used to doing things in the IBM i world? And then I’ll actually go through some examples of day to day operations using Git with IBM i code. And we’ll look at that both from a green screen environment, from an RDI environment. We’ll look at it from a couple of different views, and then we’ll talk about some of the power that Git has in managing things like parallel development, where you can have multiple people working on the same things at the same time without having to worry about am I going to lose a set of changes? Am I going to overlay things? Because Git is really designed to manage that and allow people to get to work on whatever it is they need to do, rather than having to wait until somebody else is done before they can get started. And as part of that, we’ll talk about Git’s branching functions because it’s a really important part of it. And as we’re going through it, if you have questions, please feel free to post the questions in the Q A. We can answer them as we go, or we’ll have some time at the end to answer them as well. So let’s get into it and take a look. So, starting out with, well, why do you want to use Git? Well, let me set a little context for that by talking a little bit of the history of Git and where it comes from. Back in 2005, the developers of the Linux operating system under the leadership of Linux Tortvalds, they were using a product called Beekeeper for doing version control. And the Beekeeper people decided that they wanted to start charging license fees for that. And so Linux decided he didn’t want to do that. And so he created a version control system specifically for the Linux operating system development. And there were hundreds and hundreds and hundreds of developers all around the world working on that project. So we had to figure out, how do I manage an environment where people are not all working in one central system, but are working in different places, and yet we’re merging all that code into a central environment so that we can deploy the operating system. So he created a system designed specifically to allow that kind of development, where lots of developers are working on things. They don’t necessarily know what each other is doing, but they have a very powerful function for merging the code together as they move the project forward. Then in 2008, GitHub was founded. GitHub was designed to be a repository, a place to host your repositories in the cloud. So Git is the software tool. GitHub is a place to host your GitHub repositories. And the reason they saw the need for that is after the Linux thing was being developed, other open source projects thought, hey, this is a great tool to use. Let’s start using it for that. And then companies started to use it. So we started to see widespread adoption of Git as a version control tool. And so GitHub was founded as a way to host that in the same year, actually, a couple other hosting sites. GitLab was founded also, and then Bitbucket over at Lassian. So there were other places to host Git repositories. And then in 2018, Microsoft acquired GitHub with its $28 million, 28 million users for seven and a half billion dollars. So they’re sort of putting their imprimatur, their stamp of approval on this way of doing things. And Git has been growing ever since. So if you look at the speed at which Git is being adopted, we’re now somewhere just on GitHub alone. This is just GitHub repositories. There’s somewhere close to 200 million repositories now on GitHub. And again, that doesn’t include what’s on Azure DevOps. It doesn’t include what’s on GitLab and Bitbucket. So there are just millions and millions and millions of repositories, and again, on GitHub, 100 million developers, and again, doesn’t include the developers using other hosting systems. So it’s being adopted very rapidly because of the power it has for doing version control and the productivity that people are seeing in using Git as their version control system. So one of the reasons for us to think about this is IBM i users, why should we not be able to use the same thing that everybody else is using? And that’s really in line with what IBM is doing. IBM is really also on board with this idea of using Git for managing development. This is a slide from Steve Wills presentation. For those who don’t know, Steve is the chief architect of the IBM i, and in his presentation, he talks about the future of application development. On the IBM i is a blended environment where you’re going to have IBM i traditional code, RPG, Cobalt, CL, DB Two, all this traditional IBM i stuff. But you’re going to combine that with new technologies. And new technologies may be in different languages, and it may be using different kinds of tools. And you see over here on the right side, under the open source, he’s got DevOps. So you’re seeing IBM i moving into this environment of using open source tools for DevOps, for the IBM i community. And so you do have, almost by nature, you have in the modern development environment, this blended environment to the IBM i, an environment where you have lots of different technologies. So you’ve got your RPG and your Cobalt code, your DB Two stuff, your display files, all the standard IBM i stuff. But you’re also doing JavaScript development, or Python development, or net, or PHP development. So you’re also developing in other languages, and oftentimes those things are communicating with each other. And so you need to be able to manage those things together. You need to be able to have a single place where you can go to see what are all the changes I’m making for a particular thing that I’m doing, regardless of what platform those changes may be targeted for.

Dan Magid

In addition to that, to giving you that kind of single tool for managing everything, git has lots and lots of very powerful functions for manning versions. So you can imagine as there are hundreds of millions of people using Git, and there are many, many developers who are working on it. As Git itself is an open source project. It has lots and lots of capabilities, so there’s a lot of things that you can do it, and one of the biggest, most important things is its ability to track all of the changes that you’re making. So you don’t need to put comments into each line of code to say, hey, I changed this, and here’s the project I was working on, or comment out deleted code, so you have documentation of that. Most of that stuff is going to be handled for you automatically through Git. And so let me give you sort of an example of what that means. So here I’m looking at the browser screen now, and I’m actually looking at GitHub. So I have the demo stuff set up here in GitHub, but this could be any other system. So for example, here I’ve also got a demo environment set up here under Bitbucket, same thing. You see what looks like a lot of IBM i kinds of things. And I’m going to go into some detail about that in just a minute. But you see folders out here that look like source files, which is exactly what they are. And then here is GitLab, same thing. So I can see all the stuff on GitLab. So it doesn’t really matter where you host it, you can host it wherever you want because the underlying tool that you’re using is git. So you’re using git. And so if I’m looking here at my repository, I have lots and lots of ways now to go in and look at the history of the changes that I’m making. So if I want to go in and see what’s been going on, I can take a look at those changes. So for example, what I want to do is I just want to see for a particular program, show me all the changes that have been made to this program. I can go into Qrpg Lesrc, so I can go to my RPG source file and I can see, I’ve got a few members in there and I can open up a program, I can see the source for that program. And then I have this wonderful button here called Blame. I love the way they’ve named that. And again, this is standard Git stuff, so I can go in here and say Blame. And what that’s going to do for me? Is it’s now going to show me for every line of code that’s been changed, it’s going to give me information about who made the change, why they made the change, what changes they made. So I’ve got all kinds of information specifically about this particular line of code. So again, you no longer have to put comments into the code or put project Identifiers in the code. All that stuff is here in Git. And what’s even more cool is that I can say, well, I’m really trying to figure out what went wrong with this program. So show me what was the last change I made. So now it’ll step back and show you here’s the previous change. And I can keep hitting this button and it’ll keep going back and showing me the change before that and the change before that and the change before that. So I can step back through history. So again, when I’m putting comments into the code or project Identifiers and lines of code, the moment I make another change to that line of code, I lose the previous one. But this way I can go back and I can see every change that’s ever been made. So I can go back all the way through the history to the beginning of time and see exactly what changes were made to each of these lines of code. So that would be if I wanted to look at things based on specifically a particular program. But the other thing I can do is I can look at what Git calls a commit. I can look at each commit that’s been made. And I’m going to talk a little bit more detail about this in a few minutes. But Git is a commit based system. What that means is the way it tracks changes is it tracks changes based on you as a developer saying, okay, I’ve changed a bunch of different things. Now I’ve got the code to a state that I’m comfortable with. I mean, I may not be done with the project, but I’m comfortable with this state. I am going to commit these things to the repository and I may have multiple programs, multiple things that I’ve changed. I’m going to create this commit. So a commit is basically a snapshot at a known point in time where you’re saying, okay, I want to update the repository with this set of changes that I’ve just made. And so I can actually look at the history of commits. So you can see here I’ve got 121 commits for this task, one that I’m working on. So if I hit the commit button now, I can see a history of all the commits that I’ve made. So you can see each one has a little comment here that says here’s what I was doing. So I added some new columns, I updated the program to add some new functions. Here’s a bug fix. So I can see each time I said here’s a set of changes. I can see information about that particular commit, about that particular thing that I was doing. And if I’m interested in, I can go over here and I can say, well, show me what was changed. And I can see for that commit exactly what was changed. Let’s see if we go to one that’s a little more interesting than this.

Dan Magid

Yeah. So here I can see I changed a physical file, and here are the changes I actually made in the physical file. Here’s an RPG program that I changed. Here’s a SQL table that I changed. So for this particular commit, these are the things that I have changed. And you can actually even go to the system and say, well, you know what? I want to see actually all the changes I’ve made within a particular time frame. So, for example, here you can see each commit gets this identifier. This is something that tells you a little bit about that particular commit. It’s a unique identifier for that commit. So I can actually go in and I can look at this particular moment in time. So I can say, you know what, I want to compare this moment in time. I can come over here and say, I want to do a compare, and I can give it two of those commit IDs so I can say from this moment in time to this moment in time down here. And when I hit enter, it actually then will show me all the changes between those snapshots of the code. So you have a way to go in and say, well, gee, it was working until three weeks ago and now it’s not working. Let me go see what are all the changes that we made over the last three weeks, and you can see all the changes that were made to the system during that period of time.

Mitch Hoffman

Hey, Dan, again, just where do you see what project by the going to? Dan and I agreed in advance, if questions come up that are timely, I’m going to go ahead and jump in. And he’s good with that. Dan, where do you see what project it changes related to?

Dan Magid

So here I can go in and I can look at the list of issues that I’m working on. So here’s the list of all the issues that I’ve been working on, and I can go into any particular issue and I can say, okay, open this one up and I can see information about the issue. And then again, I can see every change that was made to this particular project, this particular issue. So that’s looking at my list of issues. And one of the things that’s actually really cool about that is you can say, you know what, I want to cut a release. In other words, I want to develop my software instead of just making changes, putting them in production, I want to develop by releases so I can go in and I can generate a release. And when I create a release, GitHub actually will create documentation of that release for me. So here it’ll show me, well, what are all the tasks that were associated with that release? And I could drill into any one of these tasks, and I can see exactly what was changed for each of those tasks. I can go in and I can look at all of the changes that were made for that task. So this is every change that was made for the task, and I can see all that information, so I can look at information by the particular issues that I’m working with.

Mitch Hoffman

Right. Thank you, Dan.

Dan Magid

Yep.

Dan Magid

Okay, so those are just some of the ways that you can look at the changes that you’ve been making. So, again, all of this is being tracked for you automatically by Git as you make the changes to your code.

Dan Magid

Now, one of the things, one of the very powerful functions of Git is that you can branch your development. What that means is you can have parallel development going on. So I can say, you know what, we’ve got our main production version of the code, and we’re working on task one and Task Two and Task Three simultaneously. We started task One first, but task Three is going to be done before task One is. So I want to actually move that one forward first. And by branching it, you can choose which of those tasks to move at which point in time. So even if you’re changing the same file, you’re changing the exact same programs. Git actually knows which changes in that program were made for Task One, which changes were made for Task Two, which changes were made for Task Three. So you can move those things independently. You can decide which ones you want to actually test with, so you can combine them or you can move them separately. And as I said, you can manage things by releases and then later on, when you need to, let’s say I’m working on Task One and Two and Three, and I make changes, and I’m changing some of the same files, and I move task Three forward before I’m done with Task One. Later on, I can merge the changes that I made in Task Three with the changes I made in Task One so that I don’t lose any of the changes. And Git has very powerful functions for merging. We’ll actually take a look at some of how it does that. The other thing that’s very cool about Git is that everything plugs into it because it’s so popular, because there are literally 100 million developers or more out there using the product. Anybody who wants to sell things to people or create new kind of functions for people, they create plugins to get. So Visual Studio code has plugins for Git, salesforce has plugins for Git, jira has plugins for Git. You go through any kind of tool you might have out there, and almost anything you can think of they’re going to have plugins to allow you to work with git. So it gives you this capability to work with anything you want. The other thing that you should take advantage of is there is a massive number of online education programs available. I mean, you just go to YouTube and you can get all kinds of videos about how to use git and how git works. But also sites like Pluralsight and Coursera and Udemy have detailed courses in how to use git and all the things you can do with git, because git has many, many functions. We’re going to just scratch the surface in this webinar. There are many things you can do with git that you can learn about in these online education courses. So some of the things that you can do with git, why for the IBM i? Well, obviously all the same reasons we just talked about, because all those things are applicable to the things you’re doing on the IBM i. But the other nice thing is you can have a single repository for all your code. So you can have your IBM i source code in the same place. You have your net code and your Java code and your JavaScript code. You can have everything in one place. So you can coordinate changes across all of the places where you’re developing. You can see all the change history in one place. And you have a simplified way of backing up your source code. If you’re using something like GitHub or Bitbucket or one of the online repositories, then you automatically have a backup of your source code. And one of the nice things about that, if, God forbid, something gets corrupted on your IBM i in your source repositories, you can always go up to the cloud based repository and pull it all down again. So it has all that code, it’s all backed up for you and it’s secure in either the Microsoft Data centers or in the Atlassian data centers or whoever happens to be hosting the thing that you’re using. So you have this very protected environment for your source code. And the important thing is you have then the ability to access it via RDI, via PDM University, whatever tools it is that you want to use for doing your development.

Mitch Hoffman

Hey Dan, we have some great questions coming up and I think we have to hit one. Can I install git on RDI to manage my source code? And if I can, why would I need GitHub when I already have it on?

Dan Magid

So where you would install git is you can install git on your IBM i, IBM supports git on the IBM i, and you could have the git repository on IBM i and you don’t need anything else other than that. You can have it installed and runs on your IBM i. The reason you’d want to use something like GitHub, like Bitbucket. So if I go back over here, if you look at all this kind of stuff. I was showing you the whole graphical user interface that’s coming from GitHub. So GitHub is providing a lot of the graphical ways of viewing what’s happening here. If you’re using Git by itself without some other sort of wrapper for giving you that graphical user interface, then it’s all command driven. And I’m going to actually show you some of the commands you can run. But you can run Git in a completely command, line driven fashion, in which case you don’t need all of these other things. But the advantages is that with GitHub, with Bitbucket, with the different online repositories, they give you things like the issue tracking, like the graphical display of the differences between files. So they give you a lot of things that you don’t get out of the box with RDI. So again, you can, if you want to, you can run Git. Actually, our team has actually been running Git on the IBM i for I think, eleven years. So they’ve had it out there on the IBM i for a very long time. So Git will run perfectly fine on the IBM i.

Mitch Hoffman

Thanks Dan.

Dan Magid

Yep.

Mitch Hoffman

And everybody else, I’m trying to save up some of your questions for the end.

Dan Magid

Okay, so some of the things that Git is not. So Git is a version control tool. That’s what it does. It does version control. It does not do things like creating your objects. So if you’re used to using an typical IBM i traditional change management system, you know, you make changes to things and then you promote it and it does the build of the code, it builds all the dependencies, it deploys the code out to wherever it is it needs to run. Git doesn’t do those things. Git does the management of the source code and it will give you the source code and put it wherever you want it. But it’s up to you to figure out how you’re going to actually do the creates. So it doesn’t do the build, it doesn’t understand IBM i dependencies, it doesn’t work with IBM i library lists out of the box. In fact, it doesn’t work with libraries at all out of the box. And I’m going to talk about that in a minute. It doesn’t manage objects and it doesn’t do deployments. That’s not part of what it does. Now typically it’s used as part of a tool chain where you have a whole bunch of tools that work together to give you that kind of functionality. So you have an IDE where you’re doing your development, you have Git where you’re managing your source code and that could be hosted again wherever you want. You’re using something like Jira or Salesforce or something else for managing the projects that you’re working on, so managing your tickets. And then you use something like Azure Pipelines, Bitbucket Pipelines, Jenkins for actually automating the process of moving code through a lifecycle. And what those tools will do is they will call something to do your creates. So they’ll call something to actually build the code and build the dependencies and then to deploy the code out. So typically you would tie these tools together in order to provide that kind of end to end change management. That’s how typically things work in the non IBM i world is use Git for managing your versions and then Git ties into one of these other tools for actually doing the process automation, for getting the kinds of things that we typically see on the IBM i. Okay, so let’s talk a little bit about Git architecture and terminology. This is where Mitch said, I’m going to get a little bit technical. I’m not going to get tremendously technical, but I’m going to get a little bit into the architecture and terminology, because it’s really important to understand the difference between how Git works and how things are typically done on the IBM i so that you can understand the metaphor, the way it’s doing things. Because otherwise the operations you perform don’t really make a lot of sense. So if you look at typically how we do things on the IBM i, let’s say you’re not using a change management system on the your, you have your production libraries that has your production source code in it, and you copy something out from the production environment into your developer library. You make some changes and then you send it back up. Either you copy it back up to the production library, you copy it to a test library, and you do a create there. So you’re copying source code around out of the box. There’s no real change tracking there. You’re making changes and then you’re moving it back in order to make the changes. In order to track the changes, you put comments into the code, kind of like what we talked about before. You comment out the deleted code. So there’s stuff that you’re doing to try to manage that. You do have the potential of losing changes because you got to make sure that if two developers are working on things that either you say, well, once one person has it, nobody else can work on it. And we’ve actually seen people rename source members to stop people from working on the same things at the same time. So you have things that you have to do to manage that. But typically you copy things out, make changes, and you copy them back in. If you’re using a change management system, it’s going to keep track of stuff like that. Yet you’re still working in your IBM i library, so you’re doing all your stuff, all your code is still in your libraries and your source files and your source members. You may check something out and then the system will make sure that if you’re working on something, somebody else can’t change it, or if they do change it, it’ll track it for you so you can merge them later on. But you’re still working in. Your libraries. The system is simply putting a layer around your existing libraries to manage what’s happening in those libraries. So that’s typically how things work in the sort of IBM i traditional way of doing things. So what happens differently in git is git actually separates where you’re working from where it’s doing all its tracking and keeping track of everything. So you have your working area where you’re making the changes to your code. And again, I’m going to talk about this can be in your libraries and your source files and your source members, or it could be in directories in the ifs, but you’re making your changes in one place. Git is then keeping a repository, which is its thing, of where it’s actually tracking everything. So when you make a change, you change a file, it is going to put a copy of that file into its repository, so into this separate repository. So it’s going to track that file and it keeps every copy that you ever make of any file that you’re changing. So each time you change a file, it’s going to take a snapshot of that. Actually, when you do an ad, when you do a git ad, it will take that and it puts it into the repository. So there are these operations that typically you perform if you’re working in a git environment. So one is you make your changes. So with git, you don’t have to check anything out, you just start making changes to the code. So you go in and you make changes to the code. And one of the things that bring up for you is, well, how do I get the code? In a git environment, you work with fully populated source environments. So in other words, if developers are working on the code, each developer will have a fully populated environment that has all of the code in it, and they just go in and they start making changes. So you can go in and you change some things and then you do what’s called a git add to say, okay, I’ve made a bunch of changes, I’m about ready to commit these to my repository. You do what’s called a git add. When you do the git add, git actually takes a copy of those files that you’ve changed and it puts it into this git repository. So it now has in a blob, in a compressed blob, it has a copy of the things that you’ve changed. So that says that they’re staged. When you’re actually at a known state, when you’re at a place where you’re comfortable, that’s when you do a git. Commit. Commit says, okay, I finished fixing bug, one, two, three, I’ve made the changes, I need to do that, commit those changes to my repository. When it does that, it creates a couple of records. It creates a commit record that says, okay, you did this, commit. And it says who did it? And when they did it and why they did it. So there’s information about the commit and it also creates what’s called a tree record. The tree record actually has a list of all the files with their version identifiers that are in the repository at that moment in time. So basically what that looks like make that a little bit clearer. So what happens is I’ve got everything sitting here in my git repository. So I have a list of all the files that I’m working with. So here I’ve got source 123456, bunch of different sources. And git creates this hash identifier for that version of that file so that uniquely identifies that file. So the repository has the compressed version of the actual source and this identifier, this hash that identifies that version of that file, then it also has a tree record. The tree record says at this moment in time, this is the list of files with their hashes for the versions of those files. And trees can have trees within trees within trees to represent directories within directories. So I’ve got the list of all the files that are in my application and then I’ve got the list of the versions of those files at a particular moment in time. Now at the very beginning, those two things will match. The list of files in the repository and the list of files in the tree will match before I make any changes. Once I start making changes, this will start to change. So basically you have in that git vault, that git repository. I’ve got all of the files with their unique identifiers, with their hashes. I’ve got the tree that says at this particular moment in time, these are the versions of the file that made up the repository. And then each time I do a commit, I get a commit record that says here’s what I did, here’s why I did it, information about a date and timestamp and then an identifier that identifies the tree record that says here’s what was in the repository at that moment in time. So basically if I go from there,

Dan Magid

so what I’ve got now if you look at this, and I don’t know if you can see this real well, but down here you can see I’ve got source One. So I changed source one. So I now have a new record for source One, which is the version two version of source One with its unique hash identifier. And I can have a version two of source Three. So I changed, I have new entries in the Blob file for each of those changed files. So that Blob file is going to continue to grow each time I change things because it’s putting in copies of those files with a unique identifier. The tree record will now show me at this moment in time I had version two of source One, version two of source Three, and version one of all the other files. So it says here’s what the repository looked like at that moment in time. And then it has this new commit ID that says what I was doing for that change. So that makes sense. When I load the repository, it loads all my sources into that repository. It creates a unique hash for all those files that identifies them. And then as I make changes, it adds records to that file, the list of files, and it adds these tree records to say at this moment in time, at this snapshot, this is what the versions of all the files were. So that’s how it keeps track of the changes. It’s a little bit sort of under the covers. Now, I will say that most people who use git actually don’t know a whole lot about this. They just use it and they just trust it’s doing whatever it’s doing. But this is basically what’s going on under the covers. And there’s actually about eight other different kinds of things that git is tracking, but these are the basics. So now I’ve got that repository.

Mitch Hoffman

Hey Dan, should the hash of v one and v two be different?

Dan Magid

Yeah, I probably just did a copy and paste in when I created that. So yes, that is an inaccurate thing. Very good catch. Those things should not be different. Should not be the same. Thank you. Yes, that is a unique identifier. When I made the slide I should have put a new hash there. So yes, those absolutely would be different because that’s how it knows. That’s how it knows to identify which file is. In fact, one of the interesting things about git is git does not care about the file name at all. It does not care about the file name. What it cares about is this hash because the hash is actually what tells it which files it needs to be concerned with and which versions of those files. So yes, they definitely should be unique, they should be different.

Mitch Hoffman

Great.

Dan Magid

Thank you. Okay, so once I have that repository loaded, so let’s say I’ve got my git repository I’ve created and another developer wants to work, well, they can have their own copy of that repository, so they can create their own copy of the repository and they can do their work and make changes. And their repository will get updated individually, separately from mine. So each developer can have their own copy of the repository and they’re making changes. Then the way you share things in git is you do pushes or pulls. So when you want to go from one repository to another, you say, I want to push the changes I’ve made into the shared repository, for example. So as a developer I’ve made all the stuff and I’ve done my unit testing, I’m okay with everything I’ve done. Push my stuff into the shared repository so other people can get it. Then another developer can say, okay, I want to get the latest changes they do a poll and they will then get whatever changes you just pushed up there. So if developer three made some changes, did a push up to the shared repository, developer two then did a pull, they would then get developers three’s changes. Now, if they had changed some of the things that developer three had changed, then git will automatically do that merge for them as it pulls the code down.

Mitch Hoffman

Dan, I got two questions that came in. One was can you have both IBM i and non IBM i code in the same repository? And then related to that, does githandle converting punch card code to free format? I assume it could not show the check too well.

Dan Magid

I love that somebody is from my generation. Yeah, I remember the 96 column cards in a system three.

Dan Magid

In fact, I have here, if you look here, you can see I’ve got a bunch of stuff looks like IBM i source member source files, but I also have a bunch of files here that are non IBM i files. So yeah, you can have the same things and they can be in the same project. So you can have a single repository that has files that are both IBM i type files and non IBM i type files. So you can manage them all in the same repository.

Dan Magid

So yes, but I don’t think you can’t store punch cards.

Mitch Hoffman

No, but I think the question was more.

Dan Magid

What about change? Git does not do a conversion, a free format. It doesn’t have a tool that does a free format conversion. Now you could do that. So you could start working on a file and say, you know what, I want to run a tool that will convert this from the original sort of structured IBM i file type into free format and you would do that. Now, what you would see is a whole lot of changes when you did that commit of that file. You’d see a whole lot of changes to that code. But you could do that and then you’d actually still have all the history. So you actually go through the history and you could see what the code looked like before and what it looked like after, but it’s not going to do the actual conversion for.

Dan Magid

So just a quick sort of side note the difference between git and things like GitHub and Azure DevOps and GitLab. So Git is the version control tool. They all use Git, which is the version control tool itself. Again, what these are, are places where you can host your git repositories and tools that provide lots and lots of additional function that wrap around the basic version control tool that is git.

Dan Magid

Okay, so let’s talk about populating the repository. So how do you get stuff into the git repository in the first place? And the problem you have is the IBM i works with libraries and source files and source members and Git wants to work with directories. It doesn’t have a clue about libraries and source files and source members and it won’t work directly with those things. So how do you do that translation. And then once you’ve done it, how do you keep those things in sync if you still want to be able to work out of the libraries and source files and source members. So you’ve got this situation where I’ve got stuff sitting in some libraries on the IBM i, and then I also now want to get them into a directory structure for git so that git can use them. So this is where you use the git init function. So git init says I want to initialize a repository, so let’s go in and take a look at actually doing a git init. So what I want to do is I want to initialize something. So what I’m going to do, I’m going to do a quick copy live. So I’m going to create a new library here and I’m going to take my existing library that I’ve got out there and I’m going to create a webinar library.

Dan Magid

And so now if I go on a look at that library,

Dan Magid

I’ve just got a standard kind of IBM library with a bunch of source files in it and source members in those source files. So what I’m going to do is I’m saying, okay, I want to get this stuff into git. I’m just starting and I want to get all that stuff into git. So what I’m going to do is I’m going to go over here now, back to my git window here, and I’m going to move the controls out of the way here. All right? So I’m going to say I want to create a new repository and we’re going to call this repository webinar one just to make a match, they don’t have to. And I’m going to make this a private repository and I’m going to create it. So I’ve now created this new repository called webinar one up in GitHub. But it doesn’t have anything in it, it’s empty. So what I’m going to do is I’m going to say I want to populate that repository. So I’m going to copy this repository location. So I’m going to copy this. This is the repository location. And I’m going to go back over here to my green screen and I’m going to run the get init function. Now get init. This is something that Eradani provides. It’s actually a standard git function. Git in is a standard git function, but we’ve modified it to allow for you to work with IBM i code. And what I’m going to do is I’m going to have it do two things. I’m going to have it create a local repository for me, that is for my local development. Getting back to that question asked earlier, can I just work on the IBM i? I’m going to say, yeah, I want to create my development repository right here on the IBM i in the ifs. So I’m going to have it do that and I’m going to give it a location for that

Dan Magid

and I’ll give it a commit message,

Dan Magid

whatever. Now I don’t have to do this, but let’s say, yeah, I also want to populate that remote repository. I also want to get stuff up into GitHub because that’s how I’m going to share code with other developers is we’re going to do it via GitHub. So I’m going to give it that location

Dan Magid

and go ahead and run that. So now what it’s doing is it’s actually creating that local repository for me. And if I go over here to GitHub and I refresh my screen, I now have all that code up here in GitHub. So I now have the repository and I’m ready to work. Now I can go in and start doing whatever it is I want to do with that environment. So I got myself started. Everything now is in the directory structures that git needs and I can work with it. And I’m going to show you in a minute that I still can work in the libraries and source files if I want. And under the covers, one of the things Eradani does is we’re going to keep the things in sync, we’re going to keep the libraries in sync with the repository. So if you’re making changes in the library, we’ll make sure that that’s getting reflected in the git repository. So we’ll take care of that so you don’t have to worry about how are you going to keep the things in sync. Eradani is going to do that for you automatically. But anyway, that’s getting the one repo for each library, not necessarily so you can actually have in fact, I think I may have an example of that. You can have repositories that have multiple libraries in them, so you can create one. And I think this one is that way I can go in here. And so I’ve got my QSys library. So I’ve got a couple of different libraries in here. So I can see, I’ve got this git demo one library here and I’ve got the git demo two library here. So I’ve got a couple of different libraries here. Within that repository you could have as many libraries as you want and again, that you would just identify as you do your git init, you would just identify the libraries that you want to initialize that repository with. Let me go back to that, right, go back to the webinar repository. Okay, so now I, as a developer, I’m set up, I could start making changes and do whatever I want to do. But let’s say I’m another developer and I want to work on the same thing. So I want to work on that same, use that same repository. So what I’m going to do is I’m going to create a library. I’m going to call this one Webinar Two and I’m going to do a git clone. So git clone says, I’m a new person, I want to start working with that repository. So again I’m going to put in that repository location and I’m going to have it create my development repository.

Dan Magid

So basically now I’m saying I want to get started working. So now if I go, and I go into my Webinar Two library,

Dan Magid

it’s populated it for me with all that data, with those source files and source members, and now I can start working. And again, we’re now working together on that same repository. So basically that’s getting your repository set up.

Dan Magid

Okay, so now let me go back over here real quick and we’ll just go get into actually working the sort of day to day working with it. So we did the git clone, now developing with git. So again, remember, here is the process. You make your changes, you stage your changes by doing a git ad saying hey, I’ve made some changes, I’m ready with those changes, but I’m not really ready to commit because I’m not at a known state yet. So you make changes, do ads, make some more changes, do ads, and then you say, okay, now I’m ready to do a commit. And when you do the commit, that’s when it actually takes a snapshot of the repository, says, okay, this is where you were at the moment that you did that. So you can roll back to that state, you can do a lot of things with the information in that commit. So that’s basically the process. Make your changes, do a git add, do a git commit. And again, you can have multiple developers who are sharing that repository and they work on their own until they’re ready. And then they can do a git push which actually sends it up to the shared repository, where other developers then can pull down your changes or can see your changes. And again, you can have multiple developers you can pull down to a production repository and then do your build for production. Out of that you could have a test repository where you pull the source down to do your test. You can have as many of these repositories as you want, and you can pull the changes down from any version to that repository to work with. So again, here’s the process. Make your code changes, do a git add to get them into the staging area, do a git commit to update the repository, and then do a git push to get it to the shared repository. So let’s actually take a look at doing that. So here I am back again on my IBM i, I’m going to go into workmember PDM. So here I am in my development library. Let me go over to Qrpg Lesrc in my development library, and I’m going to go in and say, okay, I want to make a change. So I’m going to make a change to this program. And I can go in and say, okay, go ahead. And we’ll delete this line of code, and we’ll add some additional functions. But we’ll say for the webinar, we’ve made some changes here, can make that change. Maybe I want to change this program. There’s a program that doesn’t do anything,

Dan Magid

whatever.

Dan Magid

And then maybe I want to

Dan Magid

change a file.

Mitch Hoffman

Hey, Dan, we’re down to ten minutes, and we’ve got more questions than I can keep up with.

Dan Magid

Okay, all right, great. All right, so now I’ve made the changes. I’ve made my changes. So again, if you think about it, what was the next thing we needed to do? We need to do a git add. Now, I could add individual files, so I could do a ga right here, and that would simply add that physical file change to the things that are staged for the commit. But I’m going to say, you know, I want you to go out and find everything that I’ve changed. So I’m going to do a git add of everything.

Dan Magid

And now if I do a git status, and git status is your best friend when you’re using git, because it’ll tell you exactly where you are. So I look at git status, it tells me, oh, you’ve modified these three things. Here’s what you have. And it also tells you that I’m working on a branch. I’m working in a branch called Task One. So it says that I now have these changes to be committed, so they’re not committed yet. But it does tell me that I’ve got these things modified. Now, if I want to, I could unstage them and say, you know what, actually I don’t want to move these things, but I’m going to say, that’s great. I want to go ahead and commit these.

Dan Magid

So remember, git wants to keep track of why you’re doing things. So I can say this is a commit for the webinar.

Dan Magid

So now I’ve done that commit. So again, if I do my git status to see where I am, I don’t see the modified things anymore. It now says that your branch is ahead of the origin. So I cloned off of the shared repository up in GitHub, and it’s saying you’re ahead of that by one commit. So you have this stuff in your development environment, but you’re ahead of the origin. Now, what I could do at this point is I could push them up, or I could say, you know what, actually no, I want to create all the objects for this. So what I’m going to do is I’m going to go into working in this library, demo dev one OBJ, which is where I keep my development objects. And I say, okay, there’s nothing in there. I want to go ahead and create everything I change and everything that uses the things I create. And so this is another command that we provide, that Eradani provides, which allows me to do a make, which says I want to build everything out in that library so I can go in and say, okay, I want to do a make and I want to build it into my demo dev One OBJ library.

Dan Magid

And I run that process. So what this is going to do is it’s going to go out now and create just the things I changed and everything that uses the things I’ve changed. So you can have it automatically use the git information, what it knows from git, to go out and create the objects for you so you can go out and do your testing. So now if I go in and go back into do the work live into that DMO de V One OBJ library, I can see it’s not empty anymore, it now has the objects in it. So I can say, okay, I’m happy with that, did everything I wanted it to do. Now I want to actually push the code up to the git repository. So now I can do a git push to say, move this stuff up to the git repository.

Dan Magid

So I did the git push. So now if I come back over here to my environment and I was working on my demo repository, so let’s go over here to my demo repository and I was working on Task One. So now I can see here’s the commit for the webinar. And again, if I wanted to go into it, I could go and look at it, say here’s the commit for the webinar, show me what I did. And here I can see the changes that I’ve made to the code for that. So I can see all the changes that were made in order to affect the change that I wanted to make. So that’s kind of the getting things up in the repository. Now let’s say I want to move them through some kind of a lifecycle. So I want to go from development to test to QA to production. You do that using pull requests to move things from one stage to the next. So now I can say, you know what, I’m done with Task One. I want to move Task One up to what we call our integration environment. So here I’ve got Task One and I can say, okay, let’s move that to release one integration. And I’m going to say create a pull request. Now a pull request is just what it says. It’s a request. It’s saying, I’ve made some changes, I would like them to be moved forward, but maybe somebody else is going to actually have to look at that code. So maybe somebody else needs to do something before so I could set this up for an approval. And only somebody who is authorized to can actually do the merge of that stuff into the next stage of the lifecycle. So I’m allowed to do that. I’m going to go ahead and say, go ahead and merge that. And that’s now going to move that stuff into the next stage into the repository associated with my integration environment. And again, I could do a create or I could do a build from there, so I can do the build code from there. So that’s kind of just the lifecycle of making a change to the code. Mitch, were there any questions specifically about that?

Mitch Hoffman

Are you kidding? Yes, plenty. Where do you want me to start? There’s a lot of security questions here. The security of open source, sharing your code with the rest of the world, security settings for GitHub.

Dan Magid

Okay, just on that real quickly. When you set up a repository remember when I set up that repository, I said that it was a private repository. So on GitHub, bitbucket, all the repositories, you can determine whether a particular repository is going to be open to the public or whether it is simply for your use. So you don’t have to share that repository, you don’t have to make it public. If you’re working on an open source project, obviously you probably want to make it public so that other developers can get to it. But if it’s something that you’re doing for your own internal development, you probably don’t want to make that public. You probably want to make that a private repository. So you can do that. And then git has all kinds of security that you can set up over who can actually get to those repositories. And then you can use obviously for the repositories on the IBM i, you can use the IBM i functions for that. So you can use your standard IBM i security functions because it’s just stuff that’s sitting in the it’s, it’s just standard.

Mitch Hoffman

So let’s great, thank you. Paul, let’s address Nick’s question. He’s not clear. There are three place for the code library source file, source member. Can you clarify?

Dan Magid

Yes, basically everything started in the libraries and the source files in the source members. Right. So the standard place where you find in the IBM i, can any of those be with, can any of those be changed?

Mitch Hoffman

The other half of that question, can any of those be changed?

Dan Magid

What do you mean?

Mitch Hoffman

The three places for the code library. Oh, I see. Sorry Nick.

Dan Magid

That’s standard. That’s where everything is on the IBM i sort of out of the box.

Mitch Hoffman

And there’s the ifs folder as the local git repo. And you promote repository on a tool like GitHub or azure DevOps or bitbucket.

Dan Magid

Right. The question is, can those be changed.

Mitch Hoffman

And swapped out, in and out? Can you use different?

Dan Magid

Yeah, so basically if I’ve got a git repository sitting on my IBM i and I was using GitHub, and now I want to use GitLab, I can simply push that repository, I can clone that repository up into GitLab, and now I have that code in GitLab. So that’s what’s so cool about the repository, is a self contained thing that you can move around and you. Can put it in different places so you can change things fairly easily if you want to do that. Now, I know we’re waiting right up against time. Let me just do one more thing here just to show that you can also do all of these functions from if you’re an RDI user, I can go in and I can make changes to things here directly in RDI. So I can go in and know I want to change an RPG program here inside of RDI and I have access to all the git functions directly from here. So I go in and make a change.

Mitch Hoffman

Oh, there’s a really good question.

Dan Magid

I can make my change and then save the change here and then I can do the same things we were looking at before where I can go in now and say, okay, I want to do a git add so I can go here and do the add. I can go in and do a Git status.

Dan Magid

So again, shows me that I’ve got that one modified program. I can go in and do my git commits from here if I want to. I can run a build from here if I want to do that. I’ve got the build function here that would allow me to build it so I can do all those same kinds of things that I was doing from the IBM i I can do directly from here. I can also do things, some of the things we didn’t look at, like if I want to, I can do a git diff where I can say I want to see the difference between versions so I can see here’s the change that you made. So all of those functions are available via the green screen or via RDI.

Mitch Hoffman

Dan, there’s so many good questions but I’m worried it’s already a minute past the.

Dan Magid

Basic architecture. So we looked at the architecture of Git, the difference between how these things work on the IBM i and they work in Git. The idea that Git has this repository that’s separate where it’s keeping everything and doing all its record keeping and so you have that add and commit process that you go through with Git. Those were really the key ideas I wanted to get across and we looked a little bit at know, the task branch versus moving things up through the integration branch and the release branch.

Mitch Hoffman

So I’m going to put a link in the chat for everybody and Dan, you’re going to put this up on a slide. We kind of had a feeling there would be more questions and talking than time with an hour. So we came up with the idea of doing a part two of this event and we’re going to do that right after Common at the beginning of November. The sign up page is already live and if you go to the chat button it’s go Eradani.com slash git. We tried to make it really easy. There are so many great questions. Wickus you have a fantastic one out there. I would love to get these answered live, but it’s disrespectful to go too far over. So we will email out a list of all the questions and our responses to everybody. We will email out a PDF of the slide deck and we will email out a recording to all of you. So I think I have to wrap it up. I hate to do that because I love to talk, but it’s the right thing to do. All right, thank you, everybody, for your participation. Have a terrific morning, afternoon, evening, or night, wherever you are in the world. And go get. Yeah, yeah.

Mitch Hoffman

Go Git.

Mitch Hoffman

Oh, boy.

Dan Magid

Great. Thanks, everybody.

Mitch Hoffman

Dan, you got a lot of thank you very much. Very interesting. Thank you. Thank you. Lots of good feedback.

Dan Magid

Great.