Updated 063 Proposed Collaborative Workflow in JCB (markdown)

Amigo 2019-11-01 16:53:51 +02:00
parent 6b33d52179
commit cedefa2852

@ -72,7 +72,7 @@ The first thing you do is you go back to your component where it's installed on
[00:12:49](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h12m49s) [00:12:49](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h12m49s)
I need to create those files in my local developing environment. I'll do that via command line. First, I will make a directory, then I'm going to change that directory. In that directory I'm going to create another directory called, 'Git', change that directory as well. This is the directory where my components are going to be placed. At the moment if we look inside this directory, there is really nothing showing. The first time I will compile a component [00:13:34](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h13m34s) and I will say to the compiler to add my files to the Git repository. It's going to create a folder with all the code inside it automatically. You will remember that I cloned this repository on GitHub Joomla Questions And Answers. [00:13:54](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h13m54s) To continue I need to get the JCB package for this installed into my JCB program. The way this is done, we go to the JCB package area and select the Questions And Answers package. We will get the package. [00:14:18](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h14m18s) We add the key. At the moment there are not any components on this install. It's fine to leave '_Merge_' to 'Yes'. I'm going to Force Local Update of anything. We can just check again that it is the right package. It's the correct package. The checksum you can read. There is a checksum for the package and at the moment it seems that everything is fine, you can make a final check by clicking this link(https://raw.githubusercontent.com/vdm.io) [00:14:50](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h14m50s) and make sure that this number is the same as the one seeing on the page. All is good, click continue. There you have it. We've the component in our system. I need to create those files in my local developing environment. I'll do that via the command line. First, I will make a directory, then I'm going to change that directory. In that directory, I'm going to create another directory called, 'Git', change that directory as well. This is the directory where my components are going to be placed. At the moment if we look inside this directory, there is really nothing showing. The first time I will compile a component [00:13:34](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h13m34s) and I will say to the compiler to add my files to the Git repository. It's going to create a folder with all the code inside it automatically. You will remember that I cloned this repository on GitHub Joomla Questions And Answers. [00:13:54](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h13m54s) To continue I need to get the JCB package for this installed into my JCB program. The way this is done, we go to the JCB package area and select the Questions And Answers package. We will get the package. [00:14:18](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h14m18s) We add the key. At the moment there are not any components on this install. It's fine to leave '_Merge_' to 'Yes'. I'm going to Force Local Update of anything. We can just check again that it is the right package. It's the correct package. The checksum you can read. There is a checksum for the package and at the moment it seems that everything is fine, you can make a final check by clicking this link(https://raw.githubusercontent.com/vdm.io) [00:14:50](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h14m50s) and make sure that this number is the same as the one seeing on the page. All is good, click continue. There you have it. We've got the component in our system.
### Compile For The First Time - Add To Repository Folder - Yes ### Compile For The First Time - Add To Repository Folder - Yes
@ -96,31 +96,31 @@ We are going to start by pulling the files down from GitHub. First say: `git ini
[00:18:24](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t24) [00:18:24](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t24)
The next thing to do is to pull down the master branch. This is done with: `git pull origin master`. This will now get all the information from GitHub which is the same as what you have behind my command line screen. If we are going to do `Ls-la` we'll see that all the files are back as they should be. We have `git` here as well. My [00:19:01](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h19m01s) command line shows us that we have a git repository and we are on the master branch. That was to get us linked to this repository. Now we can go and compile it again. At the moment if we do `git status`, it should say that everything is fine and clean and there is no difference between these two. But the moment we will do another compile, [00:19:30](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h19m30s) it's going to change the files. If we do: `git status`, we'll see that all these files were modified and we can check to see what was modified by doing: `git diff`, we'll see it added more lines(see video). The compiled version was the 24th of April [00:20:03](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h20m03s) and now it's the 5th of May. Scroll down. Here is another one that have changed. There's some XML that changed. We have made an improvement to the `jsonToString` in JCB. It also updated those functions. We have removed the prefix [00:20:41](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h20m41s) to the name. That's been updated. So you can look through the diff to see all the changes that has been made. The reason why the XML file format is changed, is because we are using different XML compiler. I can show you that in a moment. The next thing to do is to pull down the master branch. This is done with: `git pull origin master`. This will now get all the information from GitHub which is the same as what you have behind my command line screen. If we are going to do `Ls-la` we'll see that all the files are back as they should be. We have `git` here as well. My [00:19:01](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h19m01s) command line shows us that we have a git repository and we are on the master branch. That was to get us linked to this repository. Now we can go and compile it again. At the moment if we do `git status`, it should say that everything is fine and clean and there is no difference between these two. But the moment we will do another compile, [00:19:30](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h19m30s) it's going to change the files. If we do: `git status`, we'll see that all these files were modified and we can check to see what was modified by doing: `git diff`, we'll see it added more lines(see video). The compiled version was the 24th of April [00:20:03](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h20m03s) and now it's the 5th of May. Scroll down. Here is another one that has changed. There's some XML that changed. We have made an improvement to the `jsonToString` in JCB. It also updated those functions. We have removed the prefix [00:20:41](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h20m41s) to the name. That's been updated. So you can look through the diff to see all the changes that have been made. The reason why the XML file format is changed is because we are using different XML compiler. I can show you that in a moment.
### Global Options - Two Ways To Compile XML In JCB - SimleXMLElement - String Manipulation Option ### Global Options - Two Ways To Compile XML In JCB - SimleXMLElement - String Manipulation Option
[00:21:05](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h21m05s) [00:21:05](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h21m05s)
In the Global Options there are two ways to compile the XML in JCB. The reason why there are two ways is because some servers don't support this one, this SimpleXMLElement Class option. It doesn't support it and mostly because it doesn't have all the PHP models of things applications activated. What we then have is a String Manipulation option which doesn't use the SimpleXMLElement but does [00:21:41](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h21m41s) replace most of the time and building all these XML field string by string. This one 'String Manipulation' is how JCB started and it is most certainly working very well. I like using it. But it isn't necessarily the best option. It's faster. If we compile it again, [00:22:03](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h22m03s) we will probably see less changes to the XML. Because I remember that package did use the String Manipulation option. To exit this just press 'Q' and again to go back in. Let's see what have changed. [00:22:28](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h22m28s) In fact I don't see any XML changes. It's just the date that has changed. It's talking about the build date. This is something we might need to look at because the reason why it's changed, is because we imported it. Your application things that you have build only started [00:22:51](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h22m51s) today. We have all the changes which are primarily the build date, and JCB itself has improved. It has improved this variable, determines that external value that's with the json string(see video). Remember, I said that we've done a little improvement. It is reflecting the JCB improvements which is the way it should be. In the Global Options there are two ways to compile the XML in JCB. The reason why there are two ways is that some servers don't support this one, this SimpleXMLElement Class option. It doesn't support it and mostly because it doesn't have all the PHP models of things applications activated. What we then have is a String Manipulation option which doesn't use the SimpleXMLElement but does [00:21:41](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h21m41s) replace most of the time and building all these XML field string by string. This one 'String Manipulation' is how JCB started and it is most certainly working very well. I like using it. But it isn't necessarily the best option. It's faster. If we compile it again, [00:22:03](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h22m03s) we will probably see fewer changes to the XML. Because I remember that package did use the String Manipulation option. To exit this just press 'Q' and again to go back in. Let's see what has changed. [00:22:28](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h22m28s) In fact I don't see any XML changes. It's just the date that has changed. It's talking about the build date. This is something we might need to look at because the reason why it's changed, is because we imported it. So your application thinks that your 'build' has only started [00:22:51](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h22m51s) today. We have all the changes which are primarily the build date, and JCB itself has improved. It has improved this variable, determines that external value that's with the JSON string(see video). Remember, I said that we've done a little improvement. It is reflecting the JCB improvements which are the way it should be.
### git add - git commit -am"Updated the component with improvements made to JCB" - git push ### git add - git commit -am"Updated the component with improvements made to JCB" - git push
[00:23:36](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h23m36s) [00:23:36](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h23m36s)
If we are going to make a pull request, we'll most probably will say, 'thank you', because you are updating the JCB improvements to the component. Let's show you how that will work. You would now make a commit. It should look something like this and remember. I always show you the the simple easiest way to do it. There are more better, maybe difficult ways. `git commit -am"Updated the component with improvements made to JCB"`. Click enter. Obviously you sign [00:24:19](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h24m19s) your commit, and `git push`. At this point you have made a change to component via your JCB install and you're pushing it back to your forked version of this Joomla Component which is on GitHub. If we are going to make a pull request, we'll most probably say, 'thank you', because you are updating the JCB improvements to the component. Let's show you how that will work. You would now make a commit. It should look something like this and remember. I always show you the simple easiest way to do it. There are better, maybe difficult ways. `git commit -am"Updated the component with improvements made to JCB"`. Click enter. Obviously you sign [00:24:19](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h24m19s) your commit, and `git push`. At this point, you have made a change to component via your JCB install and you're pushing it back to your forked version of this Joomla Component which is on GitHub.
### Refresh Page - One Commit Ahead - Discussion How Many Changes Before Making A Pull Request ### Refresh Page - One Commit Ahead - Discussion How Many Changes Before Making A Pull Request
[00:24:42](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h24m42s) [00:24:42](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h24m42s)
If you refresh the page, it'll say that it is 1 commit ahead. Now I think at this point we need to discuss how many changes should you make before you make a Pull request. If 5-6-7 people make the same changes regarding implementing JCBs improvements, who will be accepted, [00:25:09](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h25m09s) and all those kind of things. I suppose it'll still be ironed out as we go. But at this point you could click, 'Pull request'. It will automatically take the components and show that it can be merged, then if you click on that Pull request, your comment should usually end up in the title area. We will for every package that we manage, we'll add a Pull request template [00:25:42](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h25m42s) with instructions and how to manage it from here further. At this point you're saying I've made changes to the JCB package. These are the changes I have made, test it and please let me know if you like what I've done. [00:26:01](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h26m01s) There will be discussions and please do not be discouraged if it doesn't go quickly. There are reasons for us to always go through things quite slowly and thoroughly. I know in our own in-house developing team, things are going quite fast at this point because we have come to a place of understanding each other's perspective. It goes quickly but working with strangers and people we don't know [00:26:30](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h26m30s) is obviously going to be more difficult and slower. You won't have the option of editing all these values like I do because I actually own this repository. But you most probably will be able to come up to here and put in the necessary information that we will ask for and then click, 'Create Pull Request'. If I did that it will create a pull request and [00:26:57](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h26m57s) the developers will be notified and will start communicating from here. If you refresh the page, it'll say that it is 1 commit ahead. Now I think at this point we need to discuss how many changes should you make before you make a Pull Request. If 5-6-7 people make the same changes regarding implementing JCBs improvements, who will be accepted, [00:25:09](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h25m09s) and all those kind of things. I suppose it'll still be ironed out as we go. But at this point, you could click, 'Pull request'. It will automatically take the components and show that it can be merged, then if you click on that Pull request, your comment should usually end up in the title area. We will for every package that we manage, we'll add a Pull request template [00:25:42](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h25m42s) with instructions and how to manage it from here further. At this point, you're saying I've made changes to the JCB package. These are the changes I have made, test it and please let me know if you like what I've done. [00:26:01](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h26m01s) There will be discussions and please do not be discouraged if it doesn't go quickly. There are reasons for us to always go through things quite slowly and thoroughly. I know in our own in-house developing team, things are going quite fast at this point because we have come to a place of understanding each other's perspectives. It goes quickly but working with strangers and people we don't know [00:26:30](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h26m30s) is obviously going to be more difficult and slower. You won't have the option of editing all these values as I do because I actually own this repository. But you most probably will be able to come up to here and put in the necessary information that we will ask for and then click, 'Create Pull Request'. If I did that it will create a pull request and [00:26:57](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h26m57s) the developers will be notified and will start communicating from here.
### What Has Happened So Far ### What Has Happened So Far
[00:27:02](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h27m02s) [00:27:02](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h27m02s)
Now when this pull request with your changes have been fully accepted and you haven't made further changes to this component, then the next part of the process needs to happen. If I can illustrate what has happened so far, your first forked the component, then you imported components JCB package, you have made changes, in this case we didn't make changes, but you could have added a new field or a new view. Then compile it. In your local development you committed to changes to the Git repository. Also linked [00:27:47](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h27m47s) and commited the changes to Git. You have put the changes to the forked version. You have made a Pull request. Now when this pull request with your changes has been fully accepted and you haven't made further changes to this component, then the next part of the process needs to happen. If I can illustrate what has happened so far, your first forked the component, then you imported components JCB package, you have made changes, in this case, we didn't make changes, but you could have added a new field or a new view. Then compile it. In your local development, you committed to changes to the Git repository. Also linked [00:27:47](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h27m47s) and committed the changes to Git. You have put the changes to the forked version. You have made a Pull request.
### Contribute To Joomla Component - Finalize - Contribute To JCB Mapped Components ### Contribute To Joomla Component - Finalize - Contribute To JCB Mapped Components
@ -132,59 +132,59 @@ The next step is the place where the JCB package manager is going to come into p
[00:28:42](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h28m42s) [00:28:42](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h28m42s)
We're going to demonstrate the next step. Let's say at this point your commit has been accepted and merged into the root master branch of the repository. Then it should look like this, it will say: 'Merged'. If we are going to look at Commit it says: Updated the component with the improvements made by JCB. That was the point and the next step must take place, only once the changes you've made has been accepted in the Joomla Component [00:29:20](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h29m20s) source of the project. The Next Step is to do that with JCB package as well. All VDM JCB packages are kept in the JCB packages repository. The next thing you will need to do is you will need to fork this repository. I have already forked this repository a few days ago, but you'll see that [00:29:47](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h29m47s) it's already 4 commits behind the master branch. I can't really do anything until I get in sync again with this master branch. Making any commits now will mess things up and the first thing I'm going to do is make sure that this group, this repository is in sync with the master branch. This repository needs to be cloned down to my local system. For those of you that have quite a number of repositories and keeping them all in sync, it is a pain. We're going to demonstrate the next step. Let's say at this point your commit has been accepted and merged into the root master branch of the repository. Then it should look like this, it will say: 'Merged'. If we are going to look at Commit it says: Updated the component with the improvements made by JCB. That was the point and the next step must take place, only once the changes you've made have been accepted in the Joomla Component [00:29:20](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h29m20s) source of the project. The Next Step is to do that with JCB package as well. All VDM JCB packages are kept in the JCB packages repository. The next thing you will need to do is you will need to fork this repository. I have already forked this repository a few days ago, but you'll see that [00:29:47](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h29m47s) it's already 4 commits behind the master branch. I can't really do anything until I get in sync again with this master branch. Making any commits now will mess things up and the first thing I'm going to do is make sure that this group, this repository is in sync with the master branch. This repository needs to be cloned down to my local system. For those of you that have quite a number of repositories and keeping them all in sync, it is a pain.
### Shell Script - UpdateForks ### Shell Script - UpdateForks
[00:30:22](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h30m22s) [00:30:22](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h30m22s)
We have this little shell script UpdateForks which is very useful. Even if you're going to run the shell script itself, you can at least peek at some of the commands, how to get this done. What it does, it runs to get all the repositories that you have forked and then it updates them. There are a number of [00:30:49](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h30m49s) SSH files that you should have a look at. I'm going to open the UpdateRepos.sh. I have the file open and I realize this is not going to work, unless you are able to understand 'Bash', you most probably not going to be able to follow this. Let me rather do the commands one at the time [00:31:13](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h31m13s) inside of that Repo. But at least you know that there is a package here and if you do know Bash, then this is most certainly something to try out. It's working very well. I'm using it quite a lot. It's keeping all my forked repositories up to date and in sync with the master branch. If I work with them that are ready and I'm able to jump in and do it. But it's not that hard to do it manually. We have this little shell script UpdateForks which is very useful. Even if you're going to run the shell script itself, you can at least peek at some of the commands, how to get this done. What it does, it runs to get all the repositories that you have forked and then it updates them. There are a number of [00:30:49](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h30m49s) SSH files that you should have a look at. I'm going to open the UpdateRepos.sh. I have the file open and I realize this is not going to work unless you are able to understand 'Bash', you most probably not going to be able to follow this. Let me rather do the commands one at the time [00:31:13](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h31m13s) inside of that Repo. But at least you know that there is a package here and if you do know Bash, then this is most certainly something to try out. It's working very well. I'm using it quite a lot. It's keeping all my forked repositories up to date and in sync with the master branch. If I work with them that are ready and I'm able to jump in and do it. But it's not that hard to do it manually.
### First Clone Your Repository ### First Clone Your Repository
[00:31:48](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h31m48s) [00:31:48](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h31m48s)
If you haven't cloned down the repository to your local developing environment, then you will need to do that first. Nothing of what I'm going to show you will work unless you've done that. There are a few documentations that GitHub has that helps with this quite a lot. If you have Windows or Mac or Linux, you can go to these URLs or type in Google: update my fork Repo and do a search. [00:32:19](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h32m19s) This is a place you want end up at: you must first configure your Repo to see the remote upstream. Click on that and do this first. We'll come back to this one. First, we are going to check out in our Repo what is the remote branches. We will see that it only has this two remote branches and it fetch and pulls from those. [00:32:52](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h32m52s) Now we want to add the remote branch which is the upstream branch. We are going to use this one `$ git remote add upstream https://github.com/ORIGANL_OWNER/ORIGAL_REPOSITORY.git` and add the original owner. This one is your name `https://github.com/YOUR_USERNAME/YOUR_FORK.git`. This one must be the original owners name and the original repositories name. Those two values you will need to update. The way to get them is go back to your Repo [00:33:17](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h33m17s) and click on vdm-io/JCB-Packages value. This should take you to the original branch. You can have it by copying the value from 'Clone or Download'. Then you will type: `git remote add upstream`. [00:33:33](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h33m33s) Like it says there on GitHub. You will use control, shift, v, to paste in a command line. You can also paste with the mouse. There is the repository. I have a little [00:33:54](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h33m54s) change to my SSH which means I use VDM to identify the server name. That is something most of you wouldn't need to do. We'll click enter. If you haven't cloned down the repository to your local developing environment, then you will need to do that first. Nothing of what I'm going to show you will work unless you've done that. There are a few documentations that GitHub has that helps with this quite a lot. If you have Windows or Mac or Linux, you can go to these URLs or type in Google: update my fork Repo and do a search. [00:32:19](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h32m19s) This is a place you want to end up at: you must first configure your Repo to see the remote upstream. Click on that and do this first. We'll come back to this one. First, we are going to check out in our Repo what is the remote branches. We will see that it only has these two remote branches and it fetch and pulls from those. [00:32:52](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h32m52s) Now we want to add the remote branch which is the upstream branch. We are going to use this one `$ git remote add upstream https://github.com/ORIGANL_OWNER/ORIGAL_REPOSITORY.git` and add the original owner. This one is your name `https://github.com/YOUR_USERNAME/YOUR_FORK.git`. This one must be the original owners' name and the original repositories name. Those two values you will need to update. The way to get them is to go back to your Repo [00:33:17](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h33m17s) and click on vdm-io/JCB-Packages value. This should take you to the original branch. You can have it by copying the value from 'Clone or Download'. Then you will type: `git remote add upstream`. [00:33:33](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h33m33s) Like it says there on GitHub. You will use control, shift, v, to paste in a command line. You can also paste with the mouse. There is the repository. I have a little [00:33:54](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h33m54s) change to my SSH which means I use VDM to identify the server name. That is something most of you wouldn't need to do. We'll click enter.
### Two Remote Branches - First One is The Origin - Second One is the Upstream ### Two Remote Branches - First One is The Origin - Second One is the Upstream
[00:34:07](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h34m07s) [00:34:07](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h34m07s)
If we do that remote branche we will see that there are two remote branches. The one is the origin and the other one is the upstream. Now it is time for the Next Step which is to sync the fork. First, what we will do, we will fetch the upstream. This will fetch the files that has changed from the upstream which at this stage we know [00:34:42](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h34m42s) is the main master branch. To make sure that you are on the Master Branch, we are going to say: `git checkout master`. Next we are going to [00:35:09](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h35m09s) merge the upstream branch into your master branch. Now this will look differently depending on what happened. But it will give you a bunch of information and then this branch is the local branch and is now in sync with the upstream master branch. To get this [00:35:34](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h35m34s) you also need to update your branch on GitHub. you need to do: git push. This will push the changes back to Git. There are many things that can go wrong, or work out differently in Git. I'm not here to teach you how to use Git. [00:35:57](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h35m57s) If you run into some grey areas or difficult issues, you will need to Google and figure out how to get this done. If we do that remote branch we will see that there are two remote branches. The one is the 'origin' and the other one is 'upstream'. Now it is time for the Next Step which is to sync the fork. First, what we will do, we will fetch the upstream. This will fetch the files that have changed from the upstream which at this stage we know [00:34:42](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h34m42s) is the main master branch. To make sure that you are on the Master Branch, we are going to say: `git checkout master`. Next, we are going to [00:35:09](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h35m09s) merge the upstream branch into your master branch. Now this will look differently depending on what happened. But it will give you a bunch of information and then this branch is the local branch and is now in sync with the upstream master branch. To get this [00:35:34](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h35m34s) you also need to update your branch on GitHub. you need to do: git push. This will push the changes back to Git. There are many things that can go wrong, or work out differently in Git. I'm not here to teach you how to use Git. [00:35:57](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h35m57s) If you run into some grey areas or difficult issues, you will need to Google and figure out how to get this done.
### Illustrating The Workflow Of Developing Components In JCB While Collaborating With Greater Community Around JCB Packages ### Illustrating The Workflow Of Developing Components In JCB While Collaborating With Greater Community Around JCB Packages
[00:36:05](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h36m05s) [00:36:05](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h36m05s)
This is illustrating the proposed workflow of developing components in JCB while collaborating with the greater community around a JCB package. Those of you that watched the tutorial on how to contribute to the Community Directory of JCB packages, much of what I'm going to explain further is already covered in that previous tutorial. We are almost finished with the circle. [00:36:41](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h36m41s) We started by forking the Joomla component, importing the JCB package. Making changes to that and compiled it, pushed those changes to the Joomla Repo and when those changes were accepted into that Repo, we went to the place where we found the JCB package which is in VDMs case [00:37:06](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h37m06s) the VDM package area. Where if it was a community component, you would follow the explanation given to you in that previous tutorial. At this point what we are going to do is, we are going to export the JCB package, add it to these packages that we have here, run our hash so if we look at this `ls-la`, we've a `hash.sh` file. If we run it now, there should be no changes to the Repo. [00:37:42](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h37m42s) Just as we expected nothing changed. Everything is up to date at the moment and the only file we are going to change is these three files(`questions and answers`), because we are going to update this package by exporting it from JCB with the changes we've made. Since you've contributed those changes to this question and answers, [00:38:09](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h38m09s) Joomla Component Repository, those who are going to validate this push which we're about to make, going back to that repository and make sure that you're not changing things other than we should contributed there. At some point my anticipation is to build a bot which would validate this for us. At this stage it will still be a little bit slow, but eventually will speed it up and the validation will happen faster and more efficient. This is illustrating the proposed workflow of developing components in JCB while collaborating with the greater community around a JCB package. Those of you that watched the tutorial on how to contribute to the Community Directory of JCB packages, much of what I'm going to explain further is already covered in that previous tutorial. We are almost finished with the circle. [00:36:41](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h36m41s) We started by forking the Joomla component, importing the JCB package. Making changes to that and compiled it, pushed those changes to the Joomla Repo and when those changes were accepted into that Repo, we went to the place where we found the JCB package which is in VDMs case [00:37:06](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h37m06s) the VDM package area. Where if it was a community component, you would follow the explanation given to you in that previous tutorial. At this point what we are going to do is, we are going to export the JCB package, add it to these packages that we have here, run our hash so if we look at this `ls-la`, we have a `hash.sh` file. If we run it now, there should be no changes to the Repo. [00:37:42](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h37m42s) Just as we expected nothing changed. Everything is up to date at the moment and the only file we are going to change is these three files(`questions and answers`), because we are going to update this package by exporting it from JCB with the changes we've made. Since you've contributed those changes to this question and answers, [00:38:09](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h38m09s) Joomla Component Repository, those who are going to validate this push which we're about to make, going back to that repository and make sure that you're not changing things other than we should contribute there. At some point, my anticipation is to build a bot that would validate this for us. At this stage, it will still be a little bit slow, but eventually will speed it up and the validation will happen faster and more efficient.
### Will Need The Same Key For The Package In The Component As The One The Developer Uses ### Will Need The Same Key For The Package In The Component As The One The Developer Uses
[00:38:42](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h38m42s) [00:38:42](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h38m42s)
Here in JCB we click on Questions and Answers and there is one little snag here which I realized I haven't resolved. It is that you will need to have the same key for this package set in the admin or rather in the component as the one that the developer uses. That can only be given to you by the original owner of this package. [00:39:13](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h39m13s) Which in this case is myself. What does it means, it means that this export key must be the same one as the one that the package was compiled with originally. If you have imported this and you see a key here, you can be 100 % sure it is not the same key because this is an encrypted field. You are seeing the encrypted value, not the actual key. The actual key was never exported [00:39:45](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h39m45s) un-encrypted, it always remains encrypted. That's why we have the encrypted fields all around JCB. Not because we think it is going to make the database more secure necessarily. When we export and move data around which is secret, stay secret. Only within that specific component developing environment are those keys unique. The way you can have this is you will need to communicate with that developer and ask him permission, whether you can extend on this package and then he will need to manually give you this key. [00:40:22](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h40m22s) I can ask that from myself, I'm going to add that key here to be sure that it is the same key which it originally was compiled with. Those keys are the same and it's the way to tell everyone that you and that other developer are in an agreement. It possibly could happen that once your pull request to the Joomla Component's [00:40:53](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h40m53s) Repo has been merged and accepted, that team needs to give you the key. That's how I think it'll work. I'm not hundred percent sure this is going to be cemented or is going to be changed. But do realize that trust and collaboration goes hand in hand. They will need to give you the key. If it's not a JCB package that requires a key, then it is a different story. The same procedure will reply, except the exchange of keys won't be necessary. Now that you've the key in place, click Questions and Answers, click Export JCB Package. Here in JCB we click on Questions and Answers and there is one little snag here which I realized I haven't resolved. It is that you will need to have the same key for this package set in the admin or rather in the component as the one that the developer uses. That can only be given to you by the original owner of this package. [00:39:13](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h39m13s) Which in this case is me. What does it mean, it means that this export key must be the same one as the one that the package was compiled with originally. If you have imported this and you see a key here, you can be 100 % sure it is not the same key because this is an encrypted field. You are seeing the encrypted value, not the actual key. The actual key was never exported [00:39:45](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h39m45s) un-encrypted, it always remains encrypted. That's why we have the encrypted fields all around JCB. Not because we think it is going to make the database more secure necessarily. When we export and move data around which is secret, stay secret. Only within that specific component developing environment are those keys unique. The way you can have this is you will need to communicate with that developer and ask him permission, whether you can extend on this package and then he will need to manually give you this key. [00:40:22](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h40m22s) I can ask that from myself, I'm going to add that key here to be sure that it is the same key which it originally was compiled with. Those keys are the same and it's the way to tell everyone that you and that other developer are in an agreement. It possibly could happen once your pull request to the Joomla Component's [00:40:53](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h40m53s) Repo has been merged and accepted, that team needs to give you the key. That's how I think it'll work. I'm not a hundred percent sure this is going to be cemented or is going to be changed. But do realize that trust and collaboration go hand in hand. They will need to give you the key. If it's not a JCB package that requires a key, then it is a different story. The same procedure will reply, except the exchange of keys won't be necessary. Now that you have the key in place, click Questions and Answers, click Export JCB Package.
### Need To Move The Package Into The Repository ### Need To Move The Package Into The Repository
[00:41:35](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h41m35s) [00:41:35](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h41m35s)
We now have this package in this folder and we will need to move it into the repository which is also the one we have synchronized with our forked version. I have it here. I'm going to cut [00:41:54](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h41m54s) it from my temporal folder in my Joomla website to this repository, paste it in. It is going to ask if it should be replace and we're going to say: 'Yes' replace it. There we go, we've the package updated. We can go back to command line and we do: [00:42:17](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h42m17s) `git diff`. We'll see that the file had changed. We also need to run the hash file to update it. Now type in: `git status`. [00:42:36](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h42m36s) We'll see if those files have been updated. We now have this package in this folder and we will need to move it into the repository which is also the one we have synchronized with our forked version. I have it here. I'm going to cut [00:41:54](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h41m54s) it from my temporal folder in my Joomla website to this repository, paste it in. It is going to ask if it should be replaced and we're going to say: 'Yes' replace it. There we go, we have the package updated. We can go back to command line and we do [00:42:17](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h42m17s) `git diff`. We'll see that the file had changed. We also need to run the hash file to update it. Now type in: `git status`. [00:42:36](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h42m36s) We'll see if those files have been updated.
The ID of that could possibly be useful here. It's just to give a heads up and validate that you did first contribute the code to the actual Joomla Component and it was accepted. [00:43:08](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h43m08s) This is the change to the package which also needs to be looked at. In our case this is the pull request, the URL. I think we are going to use that in our commit message. Use the same commit message. It should look something like this: `git commit -am"Update the component with the improvements made in JCB ref.."` [00:43:45](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h43m45s) then the repositories username or organisation name. The repository name with this `#1`, since the pull request was number one. We will submit that and push those changes to our version of the repository. The ID of that could possibly be useful here. It's just to give a heads up and validate that you did first contribute the code to the actual Joomla Component and it was accepted. [00:43:08](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h43m08s) This is the change to the package which also needs to be looked at. In our case, this is the pull request, the URL. I think we are going to use that in our commit message. Use the same commit message. It should look something like this: `git commit -am"Update the component with the improvements made in JCB ref.."` [00:43:45](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h43m45s) then the repositories username or organization name. The repository name with this `#1`, since the pull request was number one. We will submit that and push those changes to our version of the repository.
### Going back To GitHub - Push Was Submitted - Will See A Link ### Going back To GitHub - Push Was Submitted - Will See A Link
[00:44:24](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h44m24s) [00:44:24](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h44m24s)
Going back to GitHub then after the push has been submitted and we've look at this commit. You will see it has a link, and this link is to that issue on GitHub, so it will be easy for us to trace where you have contributed it to the Joomla Component, and why it's all happened being the same comment message. [00:44:45](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h44m45s) At this stage you would again make a pull request to the master branch where we will review the changes. At this stage we don't have pull request templates and everything in place, but as soon as they do get to be placed there, then please follow those instructions. We will try to be as thorough as we can. But being a community is always up for discussion and we will try and [00:45:17](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h45m17s) do this the right way. At the moment we can put the 'Ref' in the description and then just again the comment in the title. If it's a long comment then just put a summary, a short one and put the long comment back in here. Then you create the pull request. At this point the discussion will begin validating to see that you followed all the procedures and that this package is stable and ready to become part of the [00:45:49](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h45m49s) Repo. Once it is accepted, it will be merged into the master branch, become available to the rest of the community. That's at the moment an illustration of what I consider a collaborative workflow in JCB. We were at Next Step [00:46:09](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h46m09s) and we had to move to JCB where they have accepted and merged the changes you made to the Joomla Component. Going back to GitHub then after the push has been submitted and we've looked at this commit. You will see it has a link, and this link is to that issue on GitHub, so it will be easy for us to trace where you have contributed it to the Joomla Component, and why it's all happened to be the same comment message. [00:44:45](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h44m45s) At this stage you would again make a pull request to the master branch where we will review the changes. At this stage, we don't have pull request templates and everything in place, but as soon as they do get to be placed there, then please follow those instructions. We will try to be as thorough as we can. But being a community is always up for discussion and we will try and [00:45:17](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h45m17s) do this the right way. At the moment we can put the 'Ref' in the description and then just again the comment in the title. If it's a long comment then just put a summary, a short one and put the long comment back in here. Then you create the pull request. At this point, the discussion will begin validating to see that you followed all the procedures and that this package is stable and ready to become part of the [00:45:49](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h45m49s) Repo. Once it is accepted, it will be merged into the master branch, become available to the rest of the community. That's at the moment an illustration of what I consider a collaborative workflow in JCB. We were at Next Step [00:46:09](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h46m09s) and we had to move to JCB where they have accepted and merged the changes you made to the Joomla Component.
### Owner Gave The Key - Trust The Changes - Forked The JCB Packages Repository ### Owner Gave The Key - Trust The Changes - Forked The JCB Packages Repository
[00:46:28](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h46m28s) [00:46:28](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h46m28s)
The owner has given you the original key, because they trust the changes you've made, and you have forked the JCB package repository. Make sure you have it in sync. If it's an old fork, update the key with the key from the owner. Then export it to JCB package, add it to the local Repo with a commit message and the reference as illustrated. Then push the change to your forked Repo and make a pull request. Here is the workflow. This could [00:46:55](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h46m55s) become nicely documented I suppose. Someone can take that upon them to even make some nice chart. I maybe not the correct guy for the job and this might expand and become maybe much more advanced or it could be made more simple. This is the explanation of the Collaborative Workflow with external partners around a JCB package. Once this pull request gets merged, we are back, and this 'Forked Joomla Component REPO' is in sync, [00:47:42](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h47m42s) and this 'Fork the JCB Package REPO' is in sync. This will continue and I'll go on and on. Others will contribute and there are some other complexities also in this process. But that is what I can see happening. The owner has given you the original key, because they trust the changes you've made, and you have forked the JCB package repository. Make sure you have it in sync. If it's an old fork, update the key with the key from the owner. Then export it to JCB package, add it to the local Repo with a commit message and the reference as illustrated. Then push the change to your forked Repo and make a pull request. Here is the workflow. This could [00:46:55](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h46m55s) become nicely documented I suppose. Someone can take that upon them to even make some nice chart. I maybe not the correct guy for the job and this might expand and become may be much more advanced or it could be made more simple. This is the explanation of the Collaborative Workflow with external partners around a JCB package. Once this pull request gets merged, we are back, and this 'Forked Joomla Component REPO' is in sync, [00:47:42](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h47m42s) and this 'Fork the JCB Package REPO' is in sync. This will continue and I'll go on and on. Others will contribute and there are some other complexities also in this process. But that is what I can see happening.
### Import As A Clone Or Import It With Merge ### Import As A Clone Or Import It With Merge
[00:48:00](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h48m00s) [00:48:00](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h48m00s)
I know that when you pull the changes from the previous package, the import of the JCB package, there is the option to import it as a clone or to import it with a merge. The idea would be that you will only import and merge your JCB package with the Global Repo as they accept this pull requests and that you would always stay in sync with what is currently the community version of the package. [00:48:37](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h48m37s) You could import it as a clone and make changes to the Clone and effect that will not effect the main master version. But this all is a trial and error process which you would teach yourself how that works. My idea is to do that within a blank install, try it out, pull in some of the free version, play around with it until you become confident. [00:49:06](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h49m06s) Then you are able to start contributing, not only to the community packages, but also to the VDM packages, to which you've access and help improve those components for everyone. I hope this is insightful and I'm sure there might be things that some of you would not be able to follow and I would encourage you to Google and do some tutorials and [00:49:33](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h49m33s) I'm sure your will manage. I know that when you pull the changes from the previous package, the import of the JCB package, there is the option to import it as a clone or to import it with a merge. The idea would be that you will only import and merge your JCB package with the Global Repo as they accept these pull requests and that you would always stay in sync with what is currently the community version of the package. [00:48:37](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h48m37s) You could import it as a clone and make changes to the Clone and effect that will not affect the main master version. But this all is a trial and error process in which you would teach yourself how that works. My idea is to do that within a blank install, try it out, pull in some of the free version, play around with it until you become confident. [00:49:06](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h49m06s) Then you are able to start contributing, not only to the community packages but also to the VDM packages, to which you've access and help improve those components for everyone. I hope this is insightful and I'm sure there might be things that some of you would not be able to follow and I would encourage you to Google and do some tutorials and [00:49:33](https://www.youtube.com/watch?v=zlhFyrCGWik&list=PLQRGFI8XZ_wtGvPQZWBfDzzlERLQgpMRE&index=63&t=00h49m33s) I'm sure you will manage.