10-01-2016, 11:45 AM
This page (where you also download the default windows client) has a quick overview:
https://desktop.github.com/
(Using the command line git from the git bash console is actually a lot more flexible, but it's got a much steeper learning curve if you aren't familiar with bash)
I did a quick google of "github tutorial" and found dozens.
* http://kbroman.org/github_tutorial/ seems good for command-line
* https://www.youtube.com/watch?v=XdhuWDdu-rk is a nice 3-minute overview of the basics including a fork and a pull request
Basically you think of your source code as the "trunk of a tree". If you "sliced" the tree at any point you would be able to see a where each tube/cell/etc was at that point in the tree. (Sorry, I'm not much of a biologist, but the analogy will become important.) Each time you make a new change to a file or set of files a new copy is added - the trunk grows a bit. All previous historical revisions are always kept and any commit of a new change should always have a comment describing what the change accomplished or why it was done. So you have a log of when every change was made and you can easily grab the code as a "snapshot" of all changes as of a particular time.
If you are a single individual working on the project in a very linear fashion then that's probably all you need to know. And the benefit you would get would be simply that it keeps track of the history of the project and you can backtrack without difficulty if you find you've made a mistake or need to go back to a certain point in time. It's basically a really nice but somewhat overpowered backup system.
But if you start work on version 5.0 while you are still developing features for 4.2 and bug-fixes for 4.1.5 and 3.3 and 2.2 and 1.1 and 0.000001 then github can become your best friend.
We started with the analogy of a "tree trunk" of source code with each change being recorded linearly on top of the change that occurred before. Now we go to "branches". Let's say I want to try something with US, but I'm not sure if I'm going in a good direction - it's an experiment. I will create a new branch ("my-experiment") and check it out - now I have a full backup, an exact copy of the trunk ("trunk"="master") at the time I made the branch. It's set up in a separate folder on my computer and I can do anything I want with it.
Meanwhile someone reports a bug. If I fix it on my experimental code then I am going to be rushed into releasing something that at best isn't done and at worst isn't even something I want to do. So I check out a version of the master (the "trunk") and make the changes and check it back in.
Now I'm in the middle of developing my experiment and something goes wrong. Later I will find out that my 2-year-old played patty-cake with my keyboard while I was out, but for now all I can figure out is what was working is no longer working. In a click or 2 I can see every change made on this branch - wait! What's that patty-cake text at line 119 - I didn't do that. And suddenly it's fixed. (This also shows why it is better to make little changes at a time, committing after each change when you get to a point where things are semi-stable or fully stable -- a key concept in effective use of git.)
I finish my experiment and it's awesome! Of course the whole world will want this new feature, but I would really rather not have to implement the bug-fix that happened in between. That's OK, because when I merge my-experiment branch back into the trunk Git will check carefully if there were any conflicts (a change you made in my-experiment that took place in the same area of the same file as the bug-fix was made on the master) and if there are no conflicts then it checks everything in and your new master ("trunk") now contains both the bug-fix and my-experiment.
Now that small example begins to show the advantages of git. Now let's say that you have 3 (or 30) developers all making changes at the same time. Some changes are bug-fixes on 4.1.5 heading towards 4.1.6 but already someone else has started changes aiming towards the new features of 4.2 and someone else is thinking long-term towards 5.0. (Sound like a familiar situation?) So the bug-fix buy checks out 4.1.5, makes a new branch and fixes the problem and merges it back in. The person working on 4.2 sees that this bug-fix is needed there as well so (this is key!) they take the branch between the start of the bug-fix branch and the end of the bug-fix branch and apply it back onto the trunk heading for 4.2. The person working on 5.0 realizes that change has been completely re-worked already so doesn't bother ... or they see that it's needed and so they merge it into their copy.
Now some total newb comes in who just found US a month ago and has all kinds of hare-brained ideas. (Sound familiar again? :-) ) Write access to the main github repository would be crazy in this situation. So he just forks the whole project into his own account. Now he makes his branches, makes his changes, etc. And then he creates what's called a "Pull Request" (PR). A PR is basically the changes between one snapshot of the source code and another snapshot. And it's no problem if one snapshot is on one account (mudmin) and another is on another account (pbowers). So the newb creates a PR on the main trunk of US and the real developers are thus (by means of the PR) notified that there is a proposed change.
(Think of all the pastebins that I've been putting out there. Instead of a pastebin I would have created a branch on my forked copy of US and then submitted a PR for you to look at. You could have chosen to look at the PR as either diff output or as the actual source code files that I've submitted.)
If the US developers look at the change and evaluate it and agree that it's a good contribution then they merge it into whichever branch(es)/trunk is appropriate and close the PR. If they don't like it then they just comment on the PR and close it. These PRs become the primary way the open source community of volunteer developers contribute to the project.
https://desktop.github.com/
(Using the command line git from the git bash console is actually a lot more flexible, but it's got a much steeper learning curve if you aren't familiar with bash)
I did a quick google of "github tutorial" and found dozens.
* http://kbroman.org/github_tutorial/ seems good for command-line
* https://www.youtube.com/watch?v=XdhuWDdu-rk is a nice 3-minute overview of the basics including a fork and a pull request
Basically you think of your source code as the "trunk of a tree". If you "sliced" the tree at any point you would be able to see a where each tube/cell/etc was at that point in the tree. (Sorry, I'm not much of a biologist, but the analogy will become important.) Each time you make a new change to a file or set of files a new copy is added - the trunk grows a bit. All previous historical revisions are always kept and any commit of a new change should always have a comment describing what the change accomplished or why it was done. So you have a log of when every change was made and you can easily grab the code as a "snapshot" of all changes as of a particular time.
If you are a single individual working on the project in a very linear fashion then that's probably all you need to know. And the benefit you would get would be simply that it keeps track of the history of the project and you can backtrack without difficulty if you find you've made a mistake or need to go back to a certain point in time. It's basically a really nice but somewhat overpowered backup system.
But if you start work on version 5.0 while you are still developing features for 4.2 and bug-fixes for 4.1.5 and 3.3 and 2.2 and 1.1 and 0.000001 then github can become your best friend.
We started with the analogy of a "tree trunk" of source code with each change being recorded linearly on top of the change that occurred before. Now we go to "branches". Let's say I want to try something with US, but I'm not sure if I'm going in a good direction - it's an experiment. I will create a new branch ("my-experiment") and check it out - now I have a full backup, an exact copy of the trunk ("trunk"="master") at the time I made the branch. It's set up in a separate folder on my computer and I can do anything I want with it.
Meanwhile someone reports a bug. If I fix it on my experimental code then I am going to be rushed into releasing something that at best isn't done and at worst isn't even something I want to do. So I check out a version of the master (the "trunk") and make the changes and check it back in.
Now I'm in the middle of developing my experiment and something goes wrong. Later I will find out that my 2-year-old played patty-cake with my keyboard while I was out, but for now all I can figure out is what was working is no longer working. In a click or 2 I can see every change made on this branch - wait! What's that patty-cake text at line 119 - I didn't do that. And suddenly it's fixed. (This also shows why it is better to make little changes at a time, committing after each change when you get to a point where things are semi-stable or fully stable -- a key concept in effective use of git.)
I finish my experiment and it's awesome! Of course the whole world will want this new feature, but I would really rather not have to implement the bug-fix that happened in between. That's OK, because when I merge my-experiment branch back into the trunk Git will check carefully if there were any conflicts (a change you made in my-experiment that took place in the same area of the same file as the bug-fix was made on the master) and if there are no conflicts then it checks everything in and your new master ("trunk") now contains both the bug-fix and my-experiment.
Now that small example begins to show the advantages of git. Now let's say that you have 3 (or 30) developers all making changes at the same time. Some changes are bug-fixes on 4.1.5 heading towards 4.1.6 but already someone else has started changes aiming towards the new features of 4.2 and someone else is thinking long-term towards 5.0. (Sound like a familiar situation?) So the bug-fix buy checks out 4.1.5, makes a new branch and fixes the problem and merges it back in. The person working on 4.2 sees that this bug-fix is needed there as well so (this is key!) they take the branch between the start of the bug-fix branch and the end of the bug-fix branch and apply it back onto the trunk heading for 4.2. The person working on 5.0 realizes that change has been completely re-worked already so doesn't bother ... or they see that it's needed and so they merge it into their copy.
Now some total newb comes in who just found US a month ago and has all kinds of hare-brained ideas. (Sound familiar again? :-) ) Write access to the main github repository would be crazy in this situation. So he just forks the whole project into his own account. Now he makes his branches, makes his changes, etc. And then he creates what's called a "Pull Request" (PR). A PR is basically the changes between one snapshot of the source code and another snapshot. And it's no problem if one snapshot is on one account (mudmin) and another is on another account (pbowers). So the newb creates a PR on the main trunk of US and the real developers are thus (by means of the PR) notified that there is a proposed change.
(Think of all the pastebins that I've been putting out there. Instead of a pastebin I would have created a branch on my forked copy of US and then submitted a PR for you to look at. You could have chosen to look at the PR as either diff output or as the actual source code files that I've submitted.)
If the US developers look at the change and evaluate it and agree that it's a good contribution then they merge it into whichever branch(es)/trunk is appropriate and close the PR. If they don't like it then they just comment on the PR and close it. These PRs become the primary way the open source community of volunteer developers contribute to the project.