It has taken me quite a while to work it out and I thought I understood version control! I am now starting to understand how to use it. As every with really powerful tools like git, they do take some patience and time (not a criticism) but sometimes it is just better to give it to someone else to ‘do’ that bit 
.
1 Like
My way is the best. <Where’s the ‘conceited’ emoticon when I need it?>
I can’t see how, once it’s downloaded, you can see what version you have from Github, and reading the ‘Howto’, it read as if I have to hand control over at least part of my machine to some 3rd party heaven knows where in the world. I’d had enough of M$ doing that and switched to Linux, so I gave up on it. It wasn’t worth the effort.
1 Like
Too late to start on that sort of discussion!
That is definitely not the case 
GitHub is just a public place to host git repo’s. What is on your machine is simply a copy of a git repo. If you’re the only one with write access to the git repo you push up to Github, then only you can make changes in there. Other’s can submit “Pull Requests” (PRs) to suggest changes but you have the say on whether you accept those or not.
As for your machine, all activity on the git repo on your machine is controlled locally, either edits, or “pulls” from the gitHub repo if you choose to accept PRs.
[EDIT] It’s worth adding that you don’t have to use GitHub to use git for version control. I have numerous git repo’s that are only on my computer.
Nah, its first thing in the morning!
2 Likes
I reckon I need you to write an understandable guide. The one I tried seemed to assume I knew how it worked from page 1.
The definitive guide for git is the book called “Pro Git”. You can download a PDF/ePub/mobi of it for free here: Git - Book
Its all about git (not GitHub) and describes workflows and version control etc.
It also describes how you can add GitHub into those workflows for wider collaboration and why you might want to do that. It is worth pointing out that you can collaborate with other people without Github and there are competing public git hosting services as well… but OEM are using GitHub.
I found it a very useful book - it assumed very little knowledge in version control or git and it walks you through setting it up and using it. I found myself reading through only one chapter at a time and letting that sink in - there’s a lot of stuff in there to digest if you’ve ever used other version control systems for source code, as git is totally different to those 
I’ll also say that I use git infrequently enough that I have to go back to my own cheat sheets every time I need to do anything more complex than committing a set of changed files.
Maybe this should go into a separate thread?
2 Likes
The best reference I keep going back to is this one Learn Git - Tutorials, Workflows and Commands | Atlassian.
The key concept that, once I got it, made things easier was understanding what upstream, origin and local were. This answer helps git - What is the difference between origin and upstream on GitHub? - Stack Overflow - note the directions of flow of changes between the repositories.
- upstream - for instance emoncms/emoncms
- origin - the ‘origin’ of your local repository. You will ‘fork’ into an origin (e.g. borpin/emoncms). This is usually a remote repository (GitHub or an alternative).
- local - the local copy on your machine.
The usual flow of changes is:
- I pull changes from upstream to local (keeps local in sync with upstream)
- I push those changes from local to origin (keeps my fork origin in sync with the upstream)
- Any changes I make, are made in local (preferably to a new branch I create), I then commit these changes to local and push that commit to origin.
Each one of these repositories can have different branches - usually a copy of the ‘master’ branch.
What I have found, when making changes, is to make sure my local master branch is level with the upstream master, then create a new branch in which I make my edits.
The final concept is the Pull Request - me asking the maintainers of the upstream repository, if they could pull my changes, from origin/my branch into the upstream master branch.
I have not yet done anything that involves me directly collaborating with anyone else at the same time on the same code, so I have yet to discover how that works .
You mentioned about how you know what version you have ‘pulled’. The answer there is to create a tag, but that is another conversation, although by looking at the last commit (or the HEAD) will tell you the last change made.
I really struggled with understanding these concepts of git at first but I stuck with it as I wanted to be able to contribute to various projects. I also started using GitHub Desktop which made a world of difference to me (no Linux port it seems) and there seems to be quite a bit of effort going into developing this product. VSCode is also integrating git more and more I see.
I started there too ages ago when I was originally using the Atlassian client…
If you’ve never read the Pro Git book, I strongly recommend it for anyone at all interested in understanding and using git. It’s easy to read and it leads you logically through all you need to know whether you’re using it for your own local version control (which is how I started using git) through to very complex branching, forking and merging scenarios.
2 Likes
Its worth mentioning that Microsoft have moved all of their source code to GitHub and late last year, they bought them. They have a vested interest in making their products integrate into it (ref)
Yes and they do seem to be working hard to integrate it, putting resources in where they were lacking before. Quite an interesting strategy. Most of what they are doing is being kept open source and multi platform as well.
Here’s a very useful resource for those struggling with Github.
. https://git-man-page-generator.lokaltog.net/
