@jamiek Hey, I see you forked Fluidnc, I am not very familiar with Github, and would like to ask some questions.
A) When you forked, what happens if Mitch/Bart make a change on theirs, can you bring down those changes? If so, how?
b) I saw a youtube on this, but if they wanted your changes, you submit a request and they add it correct?
I guess that is it for now. Github is one thing I have no experience with!
I am in the same boat, Jeff explained it to me somewhere… 
a) If you fork a repository, and that repository has new commits, you will get a “Sync fork” button:
If you have no conflicts, it’s as easy as clicking that button.
b) Yes, best workflow is usually to create a branch on your repository, make your commits, then submit a pull request. This keeps the main branch clean so that “Sync fork” can work without conflicts, and your local branch can be deleted and the changes pulled into the main branch when it is merged through the “Sync fork” process.
Man, this place is SO accomodating, thanks!!
So what if it conflicts with a change you made, does it highlight it before synching?
I think instead of “Update branch” it turns into a red button saying you have to delete your commit in order to sync
This is why it’s best to do all of your local changes on your own branch. Then you can deal with merge errors properly through rebase/merge/etc locally
Depending on the software you use for editing. VSCode will pull the changes in and show you the diff in your code so you can select whether to keep your changes or merge in the ones from master.
After you fork and checkout locally, there are three repositories:
If you want to maintain your sanity, never ever make changes to the original branches in your local copy or forked github copy. All changes get applied in new branches on your local copy. That way, when you get updates from the upstream version, there is never a chance of a merge conflict.
You make changes in your local copy (in a new branch). Then you push those changes to your fork on github, and then on github you submit a pull request so they can review and merge in those changes.
During the discussion of the pull request, changes can be made to your branch on github and those changes will appear in the final merge. Here’s one. If you grant permission to the maintainers, then they can make changes to the branch in your repository too.
At any time, you can bring down changes by updating your github fork from the upstream github, and then pull down the changes from your fork to your local copy. If these are clean (because you did what I said above) then these are always easy. Then on your local copy you merge from the original branch (“Devt” is what FluidNC uses) into your working branch(es) and if there are conflicts then you have to resolve them and commit.
It took me a while to kinda get the hang of it I used a GUI to learn it, Sourcetree. That helped me visualize what is going on. By far the hardest part is dealing with conflicts. I used kdiff, but will probably set up VScode next time I start fresh.
How these guys do it all in a terminal is nuts too me.
Well, I have another (loosely called) feature in my life, our developer left the company and now I need to maintain our software he developed. I have Microsoft Team Foundation Server, and then I was looking at Github and see the similarities, but very big differences. Thank you ALL for the information, it is all very useful!
This has been my recommended git GUI to everyone for a while. I use it everyday at work and have gotten everyone else to as well. Makes everything easier to see.
For free, I like Meld, but I have been using Beyond Compare for a very long time (17 years-ish) and I’ve never found anything that works better for me, and relatively inexpensive for the amount that I have to use it and the benefit.
Microsoft Github 
Looks just like kdiff, I will check out meld.
I’m sorry 
End of day, meds wearing off…
Don’t try to understand github. You will hurt yourself. Badly. It is an unorganized heap of unrelated, mostly abandoned projects uploaded by people with over-inflated egos and/or the inability to manage aforementioned projects.
Trying to understand git, the source control software used by github, can be nearly as painful, especially if you start getting down into the minutiae of cherry picking, reverting commits, stashes, and all the CI/CD hooks. Stick to the fetch/pull/commit/push and occasional branch/merge/pull request, and you’ll be fine.
Mostly i was just wanting info. Seems if i goto something it is on git And now using visual studio at work i saw git integrated. Just curious.
Meld is awesome. I have been using it for 17 years. It has some sane options for what to compare (like ignoring whitespace). But mostly it just does what it says on the label.
As a software developer, I have tried a few different “version control” systems. Version control has a lot of trouble. If you and someone else are editing the same code at the same time, there is going to be some problems. In Git, those are conflicts. In some other version control systems, only one of you can work on a file at a time. Or you both have to manually accept every change. It is nasty.
Git has the most effective system (IMO). But it is hard to learn the basics. And even once you have them, you sometimes have to really dig deep in the docs (or ask stack overflow) to solve some hairy problems.
Git really only works for text files. It will record any changes in text files as a “commit”. A commit is literally what changed in what files between the previous and next. A commit has a connection to a “parent” commit. To get a version of the code, you need to combine all the commits in the history of commits. A “branch” is a named commit. The actual commit it points to can change. Combining two commits (branches) into one is called a “merge commit”. If Git can’t figure out which changes it should do first. Or if two commits edit the same line, it will be a “conflict” and it needs a human to help out.
Those basics don’t help you do anything. But (IMO) you need to understand that and then start doing some basic tutorials. Understanding those basic mechanics will really help you understand what the difference between “git commit” and “git push” is. And help you see what “git branch” or forking in github is doing.
Github is not Git. Github is a web site that hosts the Git server and gives you a bunch of useful web tools (like pull requests, a code editor, issue tracker, wiki, CI, etc.). It is very useful, but there are good alternatives like gitlab or bit bucket if you want to avoid the M$ github. Everywhere I have worked has kept the Git server on the LAN, accessible through the VPN. We don’t put our private code on the Internet directly.
Source code that isn’t text files shouldn’t be kept in Git (generally) If you are trying to keep proprietary format files as source, then a version control system that forces each person to lock each file might work better. Or use some proprietary VCS custom built for those files (lile onshape for 3D files). All of our M$ office docs are in microsoft sharepoint, for example.
And guess who has two thumbs, a few existentially dubious goats, and gets to figure out how to develop a custom-file source control system after he finishes figuring out AWS?
git kicks my butt…
I created a github account and forked the jackpot FluidNC_Configs to throw my JL1 laser config into.
Then realized I should have made a separate folder named something like Jackpot_User_Examples.
So did that, and moved my directory JL1_laser directory and its config.yaml.
I’m sure a tangled mess of github state will ensue in 3… 2… 1…