So I should be upfront about this. I have never actively participated in a github project. Passively yes, but never made a pull request or anything. I have also never designed a PCB or ordered them from a factory before either but here we are.
I’m a bit confused by this:
To add to the firmware, you can choose the webcontrol or maslow firmware. They are “related” but to get one to update from the other, you have to PR from one to the other.
Do you mean the Maslow firmware in the WebControl repository or the master firmware in the Maslow Repository. Bar has requested that I submit a PR request to the Maslow master firmware repository and I plan on doing this. As I understand your recomendation I need to also submit a paralell PR to the WebControl repository. If so which branch first, triangular or Holey?
the maslowcnc master is triangular… the master branch in webcontrol is triangular. the maslowcnc repo was at version 1.26 with sone outstanding PR’s. The webcontrol firmware was at version 1.28 (triangular) and actively developed, so I’ve only used the webcontrol firmware as the source. Holey is only a webcontrol thing (version 51.xx) and there was some chatter a while back about folding them together, but that hasn’t happened yet.
As one who was newly initiated to the github scene, I found github desktop to be very useful when actually working with the files. You start by creating a github account from a web page. Once you are logged in online, you visit the github repository of interest and you click the fork button in the upper right hand corner. This creates your own copy in your account and your fork is listed in the original repository fork list. Then in github desktop, you clone repository and make a local copy. From there I open the repository in visual basic code and create a new branch based on the master and make the changes of interest. Once I have a useful change or several changes and it is at a good stopping point, I save those changes by committing them back to the repository trying to be descriptive about what those changes are in the commit title and note listing what the changes are and why they are useful. Committing the changes basically saves them in that branch as the current version on the local machine. Then by “pushing” them, they go to the branch in my fork of the repoository on the github server, effectively syncing them. When the changes are complete to accomplish the task, then you can do a pull request (PR) back to the original repository master branch (or whatever branch you select) where you describe the useful changes and how to test them. You need one or more reviewers to verify and OK it and then your changes get “pulled” back in to the originating repository. Since webcontrolcnc firmware is a fork of maslowcncn firmware, changes from webcontrolcnc can be pull requested back to maslowcnc firmware, though they can likely go either way. Webcontrolcnc can merge changes from maslowcnc and pull request updates to maslowcnc, though if you look at the repository stats, with the recent activity on maslowcnc firmware, it was ahead, but is now quite a bit off:
18 changes in the holey firmware from the maslowcnc repository when it forked and then there are 21 changes it does not have. they are different. The master branch of webcontrolcnc, which is triangular, is now
4 commits behind the maslowcnc branch.
to keep your local branch up to date, you merge in changes from the master by selecting the master branch to merge into your branch when there are recent commits of changes that put it “ahead” of your branch. once you merge, commit, push, your repo is synced with your changes and the latest other changes. It makes the organization of monitoring and approving changes much simpler than trying to keep track with a spreadsheet. and the diff function to view two files side by side is super useful.
@Orob, it certaintly wasnt my intention to get you to provide such a detailed explanation but I’m really glad you did. The process is starting to make a lot more sense now.
To make sure I am clear:
Forking a repository creates a copy of the repository in your own github acocunt and lists your fork in the master repository.
Cloning the forked repository will create a local copy of the fork in which to make the actual changes to the code that you wan to implement (this should should/would be the firmware that I am testing).
Once the changes are made to the local clone, I push them to the Fork I created in my github.
I then submit a Pull Request to the master that I originaly forked in order for it to be reviewed and hopefully approved.
One approved, the changes will get Pulled from my Fork of the master and merged into the master.
Bar has sent me a link to his github turtorial. Between that and this I am starting to pull things together.
One question. What is the differnece between Forks, Branches, and clones?
A fork is your own private copy of the project where you are the king and you can do anything you want. When you make a “fork” of the firmware you make your own version where you don’t need anyone’s permission to make changes.
A clone is basically just fancy git speak for “download a copy of” when you clone your fork it basically just means you are downloading it to your machine. If you are using the command line version of git this makes sense because the command to download your fork to your machine is “git clone” but if you are using the graphical interface you probably won’t see that word anywhere.
A branch is a place in your fork to try something out. Basically if you have an idea for something that you want to try, but you aren’t sure how it’s going to go you can make a fork and try it out. If it turns out to be a bad idea you can just switch back to your ‘main’ branch (sometimes called ‘master’). If you like the idea in your branch you can create a pull request to merge your new branch into your main branch. This is exactly like making a pull request to someone else’s project, but since its your new branch into your main branch you have the power to merge the pull request whenever you are ready.
If this all sounds a bit excessive keep in mind that some projects have 1,000s of people working on them across many teams so the tools are built to handle that. In our case it’s a bit overkill.
Kind of but it’s way more powerful than that. It keeps track of every version of every file and does a pretty good job of letting you merge two different versions together. It’s like google docs but distributed.
a file manager with multiple file versions where you can compare the files from one version to the other line by line… in a graphical marked-up fashion. It is very powerful. Linux users have been using SVN for years. It was a local server version. Github basically made it online so you can browse it and fork it easily. MS owns github now I believe. It is quite powerful from what I’ve seen and yet there are features I’ve only heard about such as automation scripts to get it to take new commits or merges and automatically build binaries or check syntax or formatting to make sure things are all good that go well beyond what I comprehend with it. It is a very useful tool though.
