2. Managing Your Code in GitHub
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 2 | |
| Number of Parts | 6 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/14931 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language | ||
| Producer | ||
| Production Year | 2013 | |
| Production Place | Oxford |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Machine codeMathematicsRevision controlControl flowComputer fileLocal ringOperations researchVirtual machineRepetitionView (database)Software repositoryMereologyOpen setRing (mathematics)Slide ruleSpecial unitary groupComa BerenicesComputer-generated imageryVideoconferencingCommon Intermediate LanguageSoftware configuration managementQuicksortProduct (business)Insertion lossStructural loadAreaComputer programmingState of matterBitOptical disc drivePhysical systemVideo gameRevision controlSystem callData structureOperator (mathematics)Software maintenanceProgram codeMachine codeVirtual machineWeb 2.0Installation artDistribution (mathematics)WindowMatching (graph theory)Network topology1 (number)View (database)Moment (mathematics)MathematicsMetropolitan area networkGroup actionImplementationGame controllerMultiplication signTable (information)Projective planeCASE <Informatik>Computer configurationMessage passingMereologyCollaborationismComplex (psychology)Point (geometry)FrequencyBuildingProgrammer (hardware)Execution unitRight angleComputer fileAuthorizationSign (mathematics)FreezingTerm (mathematics)Special unitary groupPlastikkarteProcess (computing)Context awarenessDescriptive statisticsParticle systemLocal ringSystem identificationTrailUtility softwareSimilarity (geometry)Web pageDemosceneVector potentialPrice indexSet (mathematics)Cartesian coordinate systemWeb browserControl systemFunctional (mathematics)Rule of inferenceSoftwareDistanceError messageStrategy gameEmailSatelliteWhiteboardMilitary baseIdentifiabilityWebsiteGame theoryEvent horizonAdditionResultantEuler anglesDivision (mathematics)Lattice (order)Level (video gaming)Endliche ModelltheorieNumberPasswordLine (geometry)Range (statistics)Universe (mathematics)Address spacePhysical lawMobile WebDirection (geometry)Software developerStochasticHypermediaOnline helpBand matrixCentralizer and normalizerDirectory serviceWaveVotingRepository (publishing)Interface (computing)Pointer (computer programming)Demo (music)Server (computing)InterleavingAvatar (2009 film)Heat transferLoginPerspective (visual)UsabilityInformationTheory of relativityMaxima and minimaSocial classSeries (mathematics)Uniform resource locatorDisk read-and-write headScripting languageLaptopPhase transitionTouchscreenComputer fontVideoconferencingElectronic mailing listExtension (kinesiology)SynchronizationText editorCheat <Computerspiel>Open setThumbnailSheaf (mathematics)Type theorySystem administratorTime zoneGraphical user interfaceNumbering schemeComputer-assisted translationCommitment schemeWordGraph coloringClient (computing)Content (media)Computer scienceTask (computing)Public domainOrder (biology)Doubling the cubeVirtualizationStandard deviationInternet service providerElement (mathematics)Function (mathematics)Scaling (geometry)Home pageConfiguration spaceData miningGreatest elementPeer-to-peerNeuroinformatikBootingForm (programming)Basis <Mathematik>Attribute grammar
Transcript: English(auto-generated)
00:05
Hey everyone. Right, so the idea of these lectures, well we're sort of calling them lightning lectures within the sort of scheme of things because the idea isn't to get you in here and bore you to death with loads of stuff for an hour. It's literally, they're going to be a bite-sized series of lectures throughout the course, such as this one,
00:23
such as data licensing tomorrow and so on and so forth, that provide you with 20 or 30 minutes each day of sort of a few pointers and tips and techniques that you'll
00:46
need to integrate into your working practices. In terms of today's, this one's slightly different to the others. The other lectures I imagine will have much more sort of novel information for all of you. The experienced programmers here today, could you please bear with me?
01:03
As I know I've already spoken to some of the groups, obviously a lot of you have come in with a wide range of experience. Some of you are actually computer scientists who can program in seven different languages, probably in your sleep. Others have come to the DTC with more minimal programming experience. So if the experienced ones amongst
01:22
you could just bear with me for this lecture today. Obviously I do need to take you through all of it, but even if there's a lot of information for the experienced programmers, the stuff that you obviously really already understand to a very high level, could you actually try and look at this lecture from the perspective of someone who's actually going to have to assist other people that are less experienced at programming
01:45
with it? So try and look at it from more of a teaching perspective in terms of how you're going to help other, help your peers with this kind of stuff, rather than me trying to tell you stuff that you've already known for quite a while. So a brief bit of intro to why use version control.
02:03
As I say, a lot of you will be familiar with version control systems from programming. We've got a five minute video that admittedly is slower paced than I would like, but hopefully it will get a lot of the ideas across overall. So again, if you already know everything about version control, just bear with me on that. Then we'll actually just talk for a couple of minutes
02:21
about the structure of Git, just to give you some idea of how you're going to be using GitHub to actually manage your code development and ultimately to actually deliver the hand-in of all of the stuff for phases one and two. And then just to finish up, there'll be a GitHub demo. I'll just go through a couple of basics using
02:41
the actual GitHub for Windows interface, which you're going to have to install on your machines, but that's a very quick process. And I'll actually show you both that Windows based interface and also the sort of online view of your GitHub repository, which you'll be using to actually view what's on that central server. Okay, so as we already saw this
03:01
morning, over the course of any period of research, and particularly in the computational work you're going to be doing over the next week and a half, you're going to be producing all these sorts of things. Now, traditionally, it's the coders, it's the programmers that are very familiar with version control. So version control is basically a system that's based on a computer on some server
03:21
somewhere that enables you to sort of manage your project as it develops. As you keep working on different files, you will add files, you will modify them in different ways. You might even be just working on the project that's just you yourself in some cases. So I've actually got version control on all of the software I develop in my research, even though often it's just me working
03:41
on it, it's really, really useful for me to be able to track the changes. And then if something goes horribly wrong, to revert my file to an earlier version of something and obviously it saves a lot of wasted research time that way you don't otherwise have problems with files that you've destroyed, lost, have problems with or are corrupted in some way. But version control is also
04:01
used by a lot of other people to deal with non-code items, so version control of documents. And this is kind of more of a, what I'm about to show you is more of a code perspective intro. As I say, you may find this quite slow. It is five minutes, so just go with it for now. Okay?
04:28
I'm Matthew McCullough with GitHub and I'd like to take the opportunity today for those of you who are new to version control to describe at an abstract level what it does and how it relates to your job as a knowledge worker. I want to begin by
04:42
describing at a very high level the standard tasks and steps that a knowledge worker might go through in creating some content. This could be a designer, a person who works with documents, or as is most frequently the case in the realm that Git is talked about, a developer or someone who writes
05:02
code. All of those roles have the common behavior in place that we create things, author new files, write the content, we save them. We then subsequently make some edits or changes to those files, corrections, additions, requested modifications,
05:22
and then we save them again. This seems like a simple set of steps, but how would you graphically represent that? That saving the thing again and again is the goal and where version control helps, providing you clarity as to when you did it, why you
05:42
did it, and what the contents of the change were. Open for review at any time in the future. If we drew a picture of the activities of you working on one of those files that we just described, you might, for each of the points in time, describe what you did to the file,
06:04
why you changed it, and then you'd like the tool itself to record what the contents of that change were. From one word to another, a spelling correction, the change of a color or a background, or adding a company logo to the top of a web page or even a Word document. For a single individual,
06:24
this doesn't seem too hard, and for a single file, it seems relatively straightforward. Many individual products are putting this into the product themselves, this idea of keeping a history. What would this look like in terms of a graphical client that sits atop of Git? Here's GitHub for Mac,
06:44
at which point I can look at any entry that I've done in the past, I can see the before and after of the change, and I can go into the details of that with the description in context and make sense of why did I make this modification? For a single individual, I repeat, this is again
07:04
rather straightforward and rather simple. But where Git really shines is when we start talking about this in a collaborative sense. You and other team members trying to do the same thing, even worse, on the same files.
07:20
When you do that, you need something much more capable than a simple revision history of a single file for a single person. You need the idea of keeping track of who changed it, when they changed it, why they changed it, but the capability of the tool to unify these back together in what is typically referred to as a merge. These actions, these interleavings
07:45
of you and the team members working on the same similar or adjacent files is handled adeptly by a full-fledged version control system like that of Git. This idea of bringing these changes together is shown here in the same graphical user interface. Tim, making
08:05
modifications, in some cases literally at the same time that I'm making them. But the tool handling it with precision and relative ease simply show who changed what when, and if there needs to be a unification of the two, bring up a concept that we call merge and help me bring
08:25
the two sets of changes, mine and Tim's, back into a unified and resolved good and final state. Let's recap what Git brings to the table and why it's a good implementation of a version control system. It's very lightweight, it's one of the newest implementations out
08:45
there, even though it's had a full seven years to mature, and it's extremely fast, which is important to users because the tool just gets out of the way. It provides you that history, which we said some individual tools, document editing and so on, might provide on an individual basis. But Git can give you
09:05
the history of all of the files that compose a project, graphics, designs, documents, and in many cases, even some form of programming code. Next, Git facilitates this not for just one person
09:20
making modifications to changes, but actually bringing them together, facilitating collaboration, people simultaneously changing the same or adjacent files and bringing them together for a unified effect, making sense of this we're all working at the same time kind of idea. Lastly, Git is approachable for any type of knowledge worker. This is not focused just
09:45
on programmers, but equally serves designers and document authors. The graphical user interfaces provide a very pleasant experience with this version control system, a visual way of reviewing the history, and
10:00
a simple double click and right click for navigation and changes through those versioned elements. I hope you give Git a try and appreciate that you've given me a few minutes to talk about what this might bring to your job as a knowledge worker. So hopefully that's provided. I realize it's quite a basic introduction and a lot of that you will have already been
10:22
very aware of. Hopefully those of you who maybe haven't encountered virtual version control before will get the sense of following on from what we talked about this morning about needing to collaborate on a grand scale to solve a lot of big science problems, and also the need to actually unify all of our research outputs. The version control that you're going to meet over the next
10:42
week and a half is a really good way of assisting you in managing that workflow as a group. So you can maintain a history of work as it progresses, facilitate collaboration, and as you'll see, you'll have an ongoing record of who's changed which files and what those modifications actually were. So in terms of the structure of GitHub,
11:03
I know a lot of you will probably, particularly those of you with a very computer science background, will possibly prefer other version control systems like Mercurial or SVN or so forth. We're going to be using Git. So in terms of how it's structured, if you think of your repository, that's the sort of
11:22
collecting zone for all of your code that you're actually saving on this version control system, you can imagine that as a sort of folder that's got all of the files in that you need. On the central server, which you can actually access via the GitHub website, so you should think of the interface of the GitHub website as sort of being able to view what's on that central server,
11:43
you'll have a sort of main folder there that's got your repository in. However, what you're about to do when you go downstairs, well, it'll be lunchtime after this lecture, but when you come back this afternoon, you're going to start setting up the local machine side of things. So you're effectively going to take a local machine that you're working on
12:02
and you're going to install what's called the GitHub for Windows interface. So there's a distribution of the Git version control system already installed on your machines downstairs. You're going to need to install the GitHub for Windows interface that allows you to access that. So the majority of operations that you actually perform using this version control system
12:22
won't be on the central server. Most of what you do will be local. So if you imagine there's a couple of you sitting down at this particular local machine, you've downloaded the GitHub for Windows stuff and you're coding away MATLAB and then you've saved some files. OK? So there'll be a folder on your local machine that is your local copy of your repository.
12:42
Once you've actually added some files to that folder and modified them in particular ways, the local Git distribution will pick up the fact that you've altered those files and will start telling you that in the interface. So most of the work that you're doing is local. But then what you actually need to do once you've worked from that local directory is do what we call a commit, which stages those files
13:01
on your local machine and then you perform what's called a push, which as the name would suggest, is where you're taking the committed copies of those new files and pushing them onto the central server. OK? So then you'll actually be able to potentially log into your GitHub account online in your web browser and you'll actually be able to see that commit
13:21
listed and actually access those files and sort of see what's happening with the main copy. So you can see the two aspects of this. There's that central server aspect and there's the local aspect. The GitHub for Windows overview is going to look a bit like this, but you'll see this again in a sec once we do a quick demo. And then this is what it's going to look like online.
13:43
OK? So what I'll do is just a couple of caveats and then we can get on with the demo. Inevitably, always check the terms of the system you're using. Earlier today we mentioned the issue of material transfer agreements and in some cases you may find you don't necessarily want to have your code out in the public domain instantly. So if you're ever using a version control system that
14:02
involves people potentially being able to access it online, make sure you actually understand what legal restraints your work will be under once it's uploaded. Now as it happens, I've checked all this out for you and it's fine. Anything that you put up on GitHub, you will be for this project you will be doing as a public repository, but it is for you to decide
14:22
after tomorrow's lecture how you're going to actually license all of that code. OK? So just be aware that if you use version control in other ways, whether or not it's available to the public and whether or not you need to think about licensing. Equally if you've got code from industrial collaborators you might not be allowed to release it publicly at all, in which case just make sure that you've got it on a sort of private
14:42
repository. So now we're just going to close that. So if you actually now pick up the handout I gave you, I'll just take you through this. Now understandably, even though I know I mentioned the groups I've seen this morning, there will be people that are very happy with
15:02
command line stuff and Linux. I actually prefer to use Linux on a day-to-day basis, but we do inevitably need to make sure that you're all reading from the same page on this assessment and there's not too much confusion coming in. So for this reason we needed to go with Windows for the whole project, so you're going to need to boot all of your machines into Windows in order to use the GitHub for Windows
15:22
interface so that those of you who need a bit more experience in terms of learning to use GitHub can actually do so via that without too much confusion. So what you'll need to do is go to GitHub Online and you can see there's the address here and you'll need to register for an account. As you can see that's basically what the website looks like. I'm actually
15:43
signed in here, but when you actually meet the homepage that you see on the handout, you'll be able to enter your details. One thing that we would like to remind you of, even though it sounds really obvious every year there's always a few hiccups when people end up not doing this, if you're choosing, when you're choosing a password for your GitHub account,
16:03
do make sure that it's not the same password that you actually use to access the email account of the email that you signed up with. You may not remember, but there was a point last year when the whole of the university, this wasn't a DTC related thing at all, but the whole of the university did get blocked by MSN and Hotmail for a while because of some issue
16:23
with spam coming from a Nexus account that had been hacked as a result of the same password being used in particular locations. So just be aware of that. So what you'll actually find, once you've signed up online, you've got your user account that you can view online that you think of as that central server. Once you've done that, you're going to have to deal with
16:44
getting onto your Windows machine and actually installing the GitHub for Windows interface. Now Owen has already kindly put all of the Git dependencies on there, so you don't need to worry about that. But if you go to the S drive on your machines, you'll see a little mini version of this icon. So it's like a little blue circle, little cat outline in the middle.
17:04
That will be the GitHub installer, so you just need to run that and it's a very quick process. You will follow all the instructions as and when they come up on screen and you'll need to log into that using the same credentials with which you've registered for GitHub online. So don't forget the passwords for that. So I've already
17:24
got an installed version, so I'll just open it up and show you what it looks like. So you'll notice it's asking me for my login details, so I'll enter my GitHub username.
17:45
There you go. That's brought me into a local copy of my repositories, which are actually held on my laptop. So for the purposes of this demo, this laptop is my local machine. You can see when I was actually making your handouts, I actually created a demonstration repository and you can see those there. And at the far right hand side, you can
18:03
actually see what the readme is telling you. So for example, if I go onto this one called defilled networks, this is a special repository that is not publicly accessible. I've actually got a private repository on GitHub and that contains a series of MATLAB functions that I actually use as part of my day-to-day research. So you can see that once you've actually set up that repository, you're starting to put
18:23
files into it, you should be filling in the readme as you go to identify what all the files are and what the function is. So I think what we'll actually do now is just take you through quickly adding a repository. So what we want to do, if you have a look at the top of this GitHub for Windows interface, there's a little plus button. So we'll
18:43
click on that and create a new repository. If you just call it class demo, put in a brief description about what
19:01
it is. Not very exciting. Keep push to GitHub checked and do not check, keep this code private. OK, you're going to be creating a public repository. Just click create and you now see class demo is showing up in my little pane here. If you notice at the far left hand side, there's two little headings. One is local.
19:21
You can see I'm clicked on that at the moment. This bit is highlighted. That's actually showing me what's on my local machine. Underneath GitHub, you can see my little avatar and my username. And if you click on that, that will tell me the repositories that are all held on the central server. There's either a few more here. There's a couple of repositories here that I haven't actually pulled to my local machine.
19:42
So just be aware when you're working on files, which bit you're trying to look at. OK. So the next bit. OK. So if you actually look at the bottom of page two, it will actually tell you roughly where to expect. Once you've installed GitHub, there's a particular location on your local machine
20:00
where you can expect to find all of those files. So if you're creating a project folder or anything, that's where you'll find it. So if we actually go into this class demo, we'll notice even though I haven't added any particular files at all to this repository yet, but we can see that automatically there's two basically configuration
20:20
files that Git wants to actually put into this called git attributes and git ignore. And as a result of these being only held locally at the moment, they're not on that central server, I'm going to do a quick commit. So if we type in here, initial file commit, you can put an extended description if you want. I'm not going to today. So if I commit them, you can see it's actually
20:44
effectively on my local machine, taken those extra files and put them into a sort of temporary holding zone. But it's still only on my local machine because what it's telling me now is we've got no uncommitted changes. So it's kind of given the thumbs up to everything locally. What we need to do now is that push that is going to send these files onto the main server. So here, when it's the first time that you're doing this in your repository, you need to
21:05
click publish. Sometimes it can take a while. But ultimately what it's doing is pushing those files onto the server. And if I now go and log into the GitHub interface online via the browser and just flow through and find my repositories, we'll actually see
21:20
this repository listed there and the fact that there's been this commit. So you can now see you've got this little tick saying in sync. I go to Firefox and click on my username. Depending on the speed of the internet, you bring it up. Right. So if we actually look at repositories, you can now see, even though I didn't do any of this online, that push that we just did by clicking publish has actually
21:44
given us class demo. Okay. Those two are shown there. When you actually get further into this, you'll want to start adding a readme. So if you click on this, this particular thing and follow the instructions on the demo sheet, that will take you through adding a readme where you can start listing what files you're using and when. So
22:05
probably it's best now if, rather than doing any, because I don't want to eat too much into your lunch time, if you were to, for example, create a file in MATLAB. So imagine if I have a MATLAB editor. I create a file and I save it. If I actually save it inside this GitHub, you see inside the
22:24
GitHub location that I've followed, there's a little folder that it's created for me called class demo. So you can see we've actually got that .git folder, the sort of .git files there. If I were to save my MATLAB script in that folder, your GitHub for Windows interface will then pick up those changes and you can go through that commit process again to push them onto the server.
22:45
The one thing I will warn you, it is a bit of a warning that's listed on the sheet. Purely because of some bizarre quirk of how things are configured on your DTC machines, you may find that the first time you try to run a commit from your GitHub for Windows interface that it throws a bit of a weird error message and doesn't want to play ball or it might freeze
23:04
during that refreshing process. What is actually happening, it seems to be initially losing some of your login credentials. So if you actually go to options, options on your main GitHub thing, it actually needs to have, to configure
23:22
Git, the name with which you signed up and the email address you signed up with. This is so that it can actually link to that central server, verify the fact that it's you and then is happy with the identification process when you're trying to push all of those files onto the central server. So don't be too deterred if that happens
23:41
first time around. Once you've actually gone and saved these login credentials again, it should all be okay. So now just onto really the final page. I know this is a bit of a whirlwind introduction, but I know most of you will be happy to just learn how to go through and familiarise yourself. The groups I've already seen this morning,
24:01
all of you have at least one or two slightly more techy codewear people. You need to elect one person in your group that's going to be the project administrator. That project administrator needs to be the one person in your group that's creating the repository. Because if you think about it, you don't need a separate repository for every single person in your group.
24:21
You just need one. Your project admin will actually create that. Then you need to go onto a section online and it will actually take you through on this sheet. Where you need to follow through on the actual settings for this particular repository. You can follow all of the instructions. You need to actually follow the settings tab here. And as you can see, it's bringing up the repository name
24:46
and there's a little tab on the left hand side that says collaborators. Once your tech person has actually set up your repository with an appropriate name, you'll need to put in each of your user names in turn to make sure that you're all collaborators. Which means then you can start dragging down all of the stuff from that repository
25:04
and using it when you're signed in on your local machine. The one other thing that you do need to do is you should add me as a collaborator, even if you don't want to. Because I'm going to need to actually access all of the files from your repository.
25:21
So if you just add me as a stiletto feed, that's one of our two Ts. I will be there as a collaborator on your project and of course that simplifies the hand in phase. So hopefully now you get some idea of how hand in is going to work. Basically by 5.30pm on Monday, you need to make sure that all of the files that constitute your hand in for phase one
25:41
are pushed up to GitHub. At 5.30pm on that day, I should be able to go through each of your repositories in turn and just sync my local copy on my machine with the stuff that's on that master repository. So you don't need to worry about emailing in different files. Just make sure it's upon GitHub by 5.30 and I can deal with the rest.
26:02
As well as needing to be in Windows, I know there's a lot of you that would like to use Git from the command line. We won't be providing extended support for that. I know that there's loads of you that will be more than happy to do so. Once you actually get using GitHub, you will notice if you click on options, whilst you're working on your repository, you can ask it to open a PowerShell where you will use various Git commands,
26:22
which are listed on a sort of cheat sheet list in the very last point of your handout. So hopefully if you just follow all of the instructions on this sheet and support one another as and when you need to, I will also be around for pretty much all of the course. So I'll either be downstairs or in the little meeting room there if you need to find me.
26:41
And that's about it. So I'm happy to just let you all come and enjoy lunch now. I will need to see, once we get back at 2 o'clock, I'll need to start talking in turn to each of the infectious disease modelling groups. But for now, if there are no questions, we'll be good to go. Excellent. Right, thanks guys.