 Aura Christians 커피 ni wwn ni. Aunga, eurangodlau anusatio,よji? Aunga, eurangodlau anusatio? Aunga, eurangodlau anusatio. Aunai, miw yma ycan langa. Aunga, i alumni, ndrubuo. Aunga, miw yma, achbarnia maenai rai amorau vanu apunia i dunga, ndi rangunatio, te aile kori gweldi ndrubuo, aunga, i hasu āli tuwa, gawai kajuta delawe. for the most part about the board and those own little thing with version control but for the most part these concepts will get you into version control. When I first got into version control it wasn't a container it was something called subversion the ideas I found as a learning curve and the entry point and to get a version control very hard and confusing especially if you come from a background, more as a front-end sort of person and you are sort of moving to the development space whereas really you are just expected to know this stuff to know the stuff and you have all this, these jargon of staging files and committing them and revision control and fast vision control and source control and trunks and you go, what does all this stuff mean and it's very hard to get into an entry point. So I work for a small business called Communica, I'm the developer there and you know we build sites in Drupal for the most part, there's a few other stuff we use. I haven't had the honour to contribute to Corge yet but I'm quite active in the contributed space, a lot of patches, I'm the maintainer for a couple of modules up there. The commercial account to account, which is the main one, is a DPS payment gateway even here in Aus, quite large in New Zealand and then an analytics firm in the UK. So vision control doesn't need to scare you. It's actually quite a simple concept and all vision control does, in the simplest terms, attract changes to files, specifically text based files. files so if you if you've ever used revisions in Drupal or nodes and you've turned on the diff module and you click that little button and what's changed and it shows you something like that that's version control at a code level nothing more nothing less it's worth mentioning that version control only really works well and text based documents so stuff like php files module files css files those kind of things even though you can stick binary based files in there like zip files or compressed files image files it'll track those changes but it will track the file as a whole it'll know that the file changed but it doesn't know that all the red pixels were slightly shifted to a darker red shape it'll just track the whole file so but on on a on a layer of text files it will track you know text changes pretty much what you see the red got removed the green got added so when you're comparing get to other larger um version control solutions probably the biggest one out there would be subversion or svn they're essentially the same uh get works quite different to those those other servers those other version control system uses something like a centralized server so if we were to do anything significant like you want to develop a new branch and i'll explain what those things are a little bit later but you've got a new feature that you're working on you have to have a connection to that server to do it just like if you want to be a website on the internet you need a connection to some kind of web host to make that work so get works different it works local so as soon as you make a copy of the vision control repository which which is the bit that tracks all the changes you have everything local all the history forever so if you like clone down Drupal from from Drupal.org you get all the changes tracked from Drupal 4 and so it's insane how much data is there so that that's a good thing a bad thing you can clean that up over time i mean if you take like the span of Drupal there's thousands and thousands and thousands of commits so that transparency is really a good thing because you can see how stuff changed it's not particularly useful to have Drupal 4 in there admittedly especially since we had seven but when bugs are discovered you can quite easily see how that came to be so because everything is local and you don't need a connection to any kind of server get is insanely fast to compare general tasks like merging complex branches and features to SVN when you first start using get if you've got experience you think something went wrong it couldn't possibly be this fast but it is each feature branch that you create each copy that gets created from version control is a backup in its own so if you've got a production branch which has got all your stable code and you clone that into some new my awesome feature that i'm working on you get all the history from the other branch so each branch surfaces serves as its own backup as well so this is really unique to to get there are other systems that do this as well but it's the idea of distributed version control and so if i have a copy it's like i mentioned just before in the previous slide really if i have a copy i have all the history for that project if you have a copy you have all the history of that project so the entire version control repository is distributed throughout all its users and that's a pretty cool thing because it means that you've got great concurrency you can have many people working in their own type of workflows on their own kind of computers until they ready and say yep this bit of stuff that i work on is now ready to contribute back and so you can do that so it's incredibly flexible from the workflow perspective because it's got its own distributed nature these sort of this distributed nature is simply not possible in svn like if you're on the plane flying somewhere you've got a 10 hour flight and you go well i've got some time to kill hey i'll work on this this bug because you haven't got access to like svn centralized server there's nothing you can do you can sort of like do your changes and then copy those changes to another file and eventually when you connect up you can do some kind of manual thing to go and fix it up but and and get us just simple tasking it's just that simple so branching is the idea of of that any development track can have branches that spawn off it so if you if you think of a of a tree and this is actually how get documentation explains this themselves is that you've got the tree trunk which is a stable branch and then you have these branches that shoot out from the trunk that describe a development track or it could be a feature track or a bug fix track or any kinds of those and even off those tracks you can branch off them so you've got quite a bit of of flexibility when it comes to branching and because how get handles its branching it's cheap it's quite easy to go and drupal and say oh well i want to try this idea i have and css that you don't know it's going to work so if you just create a branch you try those ideas out and if it works you just merge it back into the development track and you're done but it's it's it's a very simple and easy task to do so workflows um um this is where things start getting a little bit interesting in terms of the options that you have pretty much it means that with get you can do any kind of crazy workflow you can have a deed simple workflow where if you're a developer by yourself that you just have one development trade one one branch that you work on and you just do commits against that branch and that's it you're done you can move on some bigger spaces if you like start working on larger projects that has a testing team or security team or one of those kind of things or or have some more more critical business needs where you know these are business critical functions then maybe you've got some some requirement we have got a junior developer that creates a feature branch because they're working on some kind of some kind of feature that needs to be implemented and they merge that up to the development track where maybe there's some kind of peer review system and so another developer can check over the work and if that's happy they can move that into um and this slide is called the release branch but it's quite often to call the testing branch where they can have a testing go and review those changes and then I can eventually move up into the green area which is master so master is just not Drupal I mean gets default naming convention for what's considered the production branch and so you'll see that a lot you you can change these branch names it's it's you just go sort of like green name branch and there you go you can call it live or production or stage or whatever whatever you like and you can also apply tags to the different release points that you have so you can see you've got you know 0.1 0.2 and this is essentially how Drupal does this as well this this is the point releases that you get on Drupal.org when you get you know 7.3 or 7.33 those are just something called get tags and it's a particular point in time where a commit is that got tagged as as a stable release so the the thing that makes get a little bit unique is the idea of staging stuff and truth be told I've never really understand why they called it staging because it really doesn't make any sense to the idea that before you can contribute a change to version control you have to stage change and really I think a better description is it's a pre-commit area so if you change the file you first have to change it as ready to be committed so it's like saying here's some changes I would like to make a snapshot of to go into version control so that will become clear when I go through the file process but it's like if I draw an analogy to your general gestop working environment you have a file and you delete it the file is not deleted it gets put in your trash can until you clear trash can that is essentially what it is you have a file that you're putting someone say hey I would like to potentially commit this and of course it's open source right and we all like open source I mean most of our stuff that we use in Drupalus open source the operating systems are open source the databases are open source so that's really a good thing so the inner workings I'm not going to get too geeky about this because it's an introduction and we won't get too technical but essentially when you add a file to version control and get you're creating an index file that says this is the state of the file right now and this is everything that's in that file from that point on into the future the only thing you keep track of is changes to that file so if you change one line of cse's the entire file doesn't get committed to version control again it's just like line number 18 change and it is now this and when you make another commit against that same file that same file it says line number 28 change and it's now this and because of this idea of having this linear pattern every change that you have is based on the previous commit that happened and so since every change is also checksummed and hashed you're never ever going to have a corrupt file it simply doesn't exist so it's incredibly secure from that perspective if someone goes on fiddles in there the entire repository would go something is not right and so that's quite useful if you look at some vulnerabilities last year Drupal Gettin that came out if you had your entire Drupal code base in in version control it would have been a simple command and you would have instantly seen what someone had changed in the file system and it would have been a simple task to roll back it's also worth mentioning at this point that Gett does not track changes to the database and so this is where the where the big pushes in Drupal 8 to try and move all that stuff into configuration management because like views are stored in the database content types are stored in the base everything's in the database and it's very difficult to version control data because if you export the entire database from Drupal it's this massive file and you can add it to version control all you want it's text base so that's fine that's not an issue but then when you do the new dump six months later you know you've got all the content tables in there and the way it relates it just doesn't work so version control database short answer is forget about it's not going to happen anytime soon there are some workarounds that you can can do and at the end of the the presentation i've got some some research you can look at where someone has worked on this a lot but it's not an amazing solution and this is where the features module for Drupal 7 certainly comes into place because you can take a lot of this configuration views content types and sort of like exported and it's some kind of of manageable code version of what your Drupal site is like so when you initially initiate a a empty repository in a project what happens in the in sort of like behind the scenes that you can't see there's this folder that shows up you can't see this folder it's hidden unless you've got show hidden files turned on it's called dot get and everything lives in there so if you ever wanted to delete the repository for whatever reason your local machine you just delete that folder and it's gone and inside that folder there's a whole bunch of configuration stuff and for each commit that it makes it creates an object with a hash value that's checksum'd like i mentioned before so git only has three states and those states refer to the state in which a file can be i know there's four on there but the one is in an dashed lines for a reason so you've got your working directory this is quite commonly called it will refer to as the working tree this is where all your files are this is typically Drupal root if that's what your version controlling everything that goes in that folder and it's children gets vision control unless you add an ignore file which makes which makes sense an example of why you'd want to ignore something like the files folder in Drupal you don't vision control that because that's user content and it's it's not really vision controls job to know about that vision control keys about the code base so you you know your vision control your themes your modules your custom modules libraries things like that that you add to the project a bit of argument can go into that it's sort of like what works for you some developers is vision control the entire Drupal and Drupal core and all the contributed modules other developers will say why vision control that's already why vision control something that's already vision control i mean all the modules in Drupal they're all because already under vision control so do you really have to revision control that i think it's a choice for your own workflow for us at communica we use multi sites for even a single site in the store so we don't vision control anything but what we know is is different so we only vision control custom modules custom libraries and custom themes nothing else i don't care about as far as i'm concerned views as vision control the radio i don't need to revision control that again so in your working tree you'll have your files and so when you change a file it will show up in the working tree and you'll see that soon in the next few slides that come up so once you're ready and you're ready to make a change you're ready to to record that change and to the get repository you move that file into the staging area like i said this is your pre-committer area you're saying is hey here's a change so i would like to record once just in the staging area you can then contribute that or commit that that change into the history and and that is just a log file that's all it is once you've done that you're working your working tree returns back to blank not as in blank as in these no files as in blank there's no changes to those files anymore so as soon as you edit a file again the working tree will show that hey here's a file that's changed and you change that file and you go okay i'm happy i want to now commit that you stage the file and then you commit then it returns back so in the file left you've got this stashing thing so the way get works as as soon as you try and pull changes from a developer let's say you've got a colleague working on the same project and the colleague says hey i fixed this bug and you know i would like to have that bug fix in in my code base too and you go i want to pull those changes into my working tree get it's going to tell you know you can't do that because guess going to go you have changes to your files and he has changes to his file i don't know how to merge those things together so the the solution to that is one you can create your own branch where you can commit those changes to and then bring it back into the working tree at the end or you can simply like do a stash and that's just like temporary save these changes outside of version control so i can bring them back in later it's not something you use a lot but it can come up so if you look at the the lifecycle of a file for an individual file for an individual workflow the process is always the same it doesn't ever change first the file gets created even when you go new file and sublime or php storm or whatever it's you're using you're creating a balanc file then the next stage change the next stage is to change that file in some way and that could be i'm adding code to that file it could even be um if it's some php stuff maybe you want to change the permissions and who can execute commands on that file any kind of state change to that file get will pick that up so you change the file then you have to add the file and that get add is literally the command you'll fire so you'll get add to the staging area and then you'll commit that change and then it's inversion control so at this point you're working in a tree you're working tree returns back to blank there's no more changes and then the process just starts again and that happens for every single file in your project change a file you add it you commit it change a file add it commit it and that does not change ever so if you blow this up to a team because so often so often we work by ourselves lots of times we have a team of people so we've got a son or a person here john which has exactly the same flow grads file changes it adds it commits it until some until until such a point that john goes okay i'm happy to now contribute that to the rest of the team so at that point he files a get push command which pushes his changes into it into a hosted repository this could be get bucket a bit bucket it could be github it could be drupal.org it could be git labs these plenty of solutions out there that offer us hosted service you can even run your own hosted service if you want to do some projects like geto light or get osis well can do that for you but you have to install that in the server and it sort of like becomes admin thing some businesses find that important that they say hey we don't want to share our code in any kind of hosted service for security reasons especially if you start working like i'm banking stuff and like you know serious financial stuff then they can get a bit of effe about that so suffice it to say you push that up to some kind of shed seed centralized place this is not to be confused with the same as a centralized server like version control because each version of your repository is distributed so what john has is an exact copy of what's in the hosted server and so you could technically log on to the hosted server and do whatever you like there and it's its own unique copy until that changed as pull downstream somewhere this is something you'll hear or read up a lot about push this upstream push that downstream and all that means is push something up towards someone or pull something down towards yourself so upstream is away from you so if you push it up to a hosted server that's upstream and if you do a pull you're pulling it downstream then jane comes along and she wants to work on the on the same code base as john did maybe there's a new feature maybe it's it's just collaborative and so what she has to do is she first has to clone it and cloning is is virtually the same as going to drupper.org and downloading the zip file the difference is with drupper.org when you download the zip file they don't include the version control references so you don't get that with but if you fire the appropriate uh get cloned drupper.org whatever the URL is then it will pull on all those references so in order for jane to realistically contribute to the project she has to clone the get repository so she clones it down and then she has exactly the same process as john she changes the file she adds and she commits it and she does that process until it reaches a state where she's happy and she can do that process in any kind of way that she likes she might choose to create another branch and do those changes in another branch until she feels she's reached some kind of stable state that she wants to contribute that back even if she did that on another branch and she pushed back let's assume she did that changes on on a bugfix branch and she decided to push that bugfix branch up and john didn't have that as soon as john pulled the changes he'll automatically get that branch but it just it just works it's just there so jane on this case will go okay i'm done with my feature i'm going to push it back i'm going to contribute this back so she pushes the changes upstream to the hosted repository and now john has the ability to bring those changes into his because the moment he tries and does a push the server is going to say hey look something changed in the server that i don't know about please commit your changes that you have right now if if john hadn't done that and do a pull so in this case he's going to do a feature and then do a merge and so that's quite commonly referred to as pull and there's an actual get command that's called get pull which is the one you'll probably use but it's just firing those two commands for you and concurrency for you so it'll first do a feature and then i'll do a pull for you automatically and yep yep correct that's right because version control doesn't know how to run that task on the server right it's not it's not the service job to know how to how to merge those changes for that we know uh jane and john edited exactly the same file and most likely they did and even worse they might have edited exactly the same line numbers so it'll then be up to john to take those changes from jane which is on the hosted server and go these are how i resolve these conflicts and it sounds incredibly complicated it's not really it's just going to tell you hey that the things don't match up please do a pull so you do a pull and then it's going to say either it's going to work successfully which is what happens 90% of the time and then sometimes it'll go look there's some conflict and then you have to go in and resolve that conflict and it's not incredibly difficult to do it it quite marks it out and and the code i don't have an example of it here if there's time i'm more than happy to show that uh but i will show that hey this is what it's before this is what it's now i don't know how to merge that and quite often it's not like like it'll be like a hundred lines of code it's like five or six and it's just like usually just go oh yeah that makes sense i'll just move this over here move that over there and then you're done yeah so get fetch sounds it's a little bit confusing it's not get fetch it says go to the hosted repository and this up there and there's a little round dot and it says fetch the changes and tell me what those changes are don't do anything with the changes just tell me if they are changes okay completely get status show you the current status of a repository where get fetches it says download the references that's changed in the repository and so we okay so get pool will attempt to fetch the changes remember it's not fetch it's it's just fetching it's just saying is what is different on your copy of their mind it doesn't do anything with that information just says tell me what's different do you have some commits that i don't know about and if you do then you can act on that where get pool will do a fetch that will go to the server and say fetch the changes tell me what they are and then try and take those changes and merge it into my into my working tree so get pool is just a shorthand for doing good fetch and then get merge manually yeah well get clone is just the process of getting the repository on a computer if she's done if she's done the first but she's done a get clone she can instantly do a get fetch right there and then good right now she can yeah yeah she has to first clone it to get it and then she can do a fetch and so because john gets that bit to fetch the changes and merge it so does Jane and so that process just continue and so whether there's two people working it or 100 or 1000 the process is the same it doesn't change at all so when the when we blow this up to the flow of how a project works like i mentioned earlier on gets very flexible with your workflow and i'm going to show three examples here these are the three commons ones out there this is typically what you have in a very very small webshop or just a developer by himself and you know we throw this term out there developers this is for themas this is for anyone who makes any kind of text based change okay it's not just for for developers who are hardcore people um so in this case the person has a development track which is the main branch that they're working on and and rolling out new new new features or scope or whatever they get asked to do and then the person might have a crazy idea and say hey i heard about this new awesome css compiler called libsats and i'm going to change my grid system to something else and so they'll go and try it out they don't know if that idea is going to work out they sort of like an a prototype being discovery phase and go is this going to work so a good way to do that is to create a separate branch and try that out because there's actually an arrow missing there as soon as the person wants to create another branch they'll create it from an existing branch so when you're working you always have one checked out branch which is what you're working on that could be your master branch which is production or it could be your development if the person is developing it's most likely the development branch which means at the point that they create a new branch they create a branch with all the history from the branch that they're creating it on so if i go get branch create and i've got development checked out i get all of developments copy and to my feature branch or if i was in the production branch i'd get all the code that's in the production branch and to my feature copy no it's required yep if there's a way to create a blank one i've not seen it because the whole idea is for this to work when you try and merge this changes up let's say this this feature worked out in this case it did because that change then gets merged back into the development track so whatever the developer did here work there was a great idea sometimes there was a crap idea you just deleted and so that never happened so in this case you get merged into the development branch and at some point it gets merged back up to up into production and so all those branches know about these changes you can see the feature branch got deleted because it got merged into the main development cycle there's no longer any need to have that branch there you have to do this manually you have to go and delete branch you could leave it there but eventually you end up having a lot of branches and then as people we're usually quite crap at naming things and you call it feature one something like that and so six months down the track you go what did this mean again so you typically delete it just just to keep yourself a little bit sane so if you work in a bigger organization that's probably the kind of flow that you'll have this is officially known as the get flow process i don't personally use it myself i don't find it all that flexible but it is very very well documented and is used by a lot of shops so the idea is that you have your main development track at which bug fixes and whatever happens happens right this is do this do that and then you'll get another person on board and they'll work in a feature that it could be considered unstable or it's just a new feature and so that person or that developer will work in that feature branch until such stage that they feel it's reached the stage where they can contribute that to the development branch at that point they merge it up into the development branch and since they're happy with it they can either choose to delete the branch which they probably will do in this workflow or they can choose to keep it and then right at that same point a testing branch gets created now they're quite often referred to this as a release branch as well and so from the testing branch they'll they'll get an independent tester or they have a test team or maybe it's just a project manager that does a bit of use the testing or whatever let's say they kind of find some kind of issue so the fix will then be applied on the testing branch because if you look at how the commit dots has worked that the feature branch no longer exists because it was considered stable and it moved into a development into the development cycle so they fixed the change on the testing branch and that's why there's a second dot so there was another commit maybe it would have gone straight up to the to the master branch it didn't doesn't need to be a second commit there it's just in this example there is so the idea with git flow is the moment it's moved to the testing branch all the changes happen on the testing branch and nowhere else because you're now in a state of well the code is semi-stable but we found a small issue and we need to deal with that so always happens on that once that has reached a sign-off point by whoever the the official is that makes that kind of decision it gets moved up into the production branch and it now lives in the production branch at the same time it gets merged down to the development branch again if you look at how that's worked clearly if it didn't move down to the development branch there would be a commit in the system that development branch doesn't know about so it has to move down once that happens the testing branch gets deleted if another bug is found depending on how critical the bug is there will either be another branch created to resolve that issue or some other kind of workflow will happen but of course you know as as as developers or or as the the the principle of that all software is broken is sometimes we screw up and we have mistakes so sometimes with this kind of process which is typically and mid to enterprise level level businesses that use it is that the process of getting anything deployed into production is usually too long because you have development cycle and then you know some peer review system usually and then a testing cycle and so if there's some critical bug and it needs to be fixed right now we need to account for that or need we need to account for that and so a great example would that be what was the Drupal get-and-hack so i don't know if anyone was familiar with that but that was pretty decent one right so you don't have the time luxury to deal with a whole development cycle to fix that so you need to allow a way to deal with that so what would happen is this would typically happen directly on the server because these are business critical issues that you would have to deal with so you create something called the hot fix branch you'll do this directly on the server you'll take you'll clone that directly from the production branch because that's your stable code base that you know and trust and you do your fix so in the example of Drupal get-and-hack you replace the database dot inc file which is where the vulnerability was moment you've done that you merge it back straight into production again so now your Drupal core or your your production version of that site is stable again and you merge that same information down to your development track so that the development development track has that change too you have to do it manually so if you have got continuous integration set up you can do that obviously not the bug fix thing because it wouldn't know about it and so but if you've got full continuous integration set up you can you can solve even that bit with continuous integration but doing continuous integration is really really hard and takes a long time to do very well so you'll find that most places just do this mean and go get-poorish login to the server get-poor or get-merge or whatever the commands are that need to fire what do you mean by that okay so so checkout doesn't mean um check out means return my code to a stable state so if you had a file that you changed and you go get checkout index.php what it will do it will revert whatever changes you made to the index.php to whatever version control knows that it should be does that make sense okay so so checkout is not it's not about I guess it is in the sense that you're saying is return my code to a stable state so the commands that's fired to revert changes or checkout changes is literally get checkout get revert and get reset those are the three you need to do and I'll talk a bit about them a little bit later so this is the process we actually use and this is not that dissimilar from from the get flow previous example but I guess it abstracts out the idea of independent deployability a little bit better so you know you scope out a job or you have an existing job and the client come back they never come back and say we want this one little change right it's always like 10 things and so you're going as well gosh these 10 things is 100 hours worth of work as you go well how do I independently deploy each feature on its own so because one of the task might be five hours worth of work and one of mine might be 30 hours worth of work you're obviously not going to finish them at the same time so the idea is that you clone directly down from from the green dots from the master branch the only reason I didn't include the arrows in theirs because it would have made the graph insane so you clone down from not clone down this wrong term you create a new branch from the development track from the sorry the production branch master branch and then you make the changes to the branch that you're working on so in this case we're working on a feature called related content and so you make all the changes just relevant to related content on the related content branch and only that branch if you mark up there are some things you can do to resolve it but it's really painful it just my suggestion would be it's just people disciplined enough not to do that because it's difficult to fix you might also have another developer working on the geo fencing thing which is a much bigger job to do so that developer is working on that branch and that branch only like you know your your front end people might be working on the infamous ie bug or you know someone might be working on some other bug and so the idea is that any point once it once one of these features reach a stable state you can merge that into stage so stage copy is typically the copy you show your client to get sign off on or for us it is anyway so the client usually gets accidentally go hey we've deployed this awesome geo fencing functionality go give it a test and the client comes back that's amazing and that means we can deploy just that change to production without having completed related content the ie bug or the um the other one the notice the notice error so it gives us independent deploy which is very very helpful i mean we've all had that and go well we can't really push this up because too much code change we have to do it on one big chunk and it just makes the project lag on so it's really cool to independently deploy these things if you can so gets is unfortunately a command line tool um at some point the reality is is you're going to have to suck it up and learn it um guis can take you a long way and in fact my my workflow is about 50 50 split about using a gui i am not a die hard person that sees no command line i can do all the commands and uh command line and if you don't have something like continuous integration set up the reality is at some point you're going to have to shell command into your server and run one of these commands in order to get it and at some point something is not going to work and you're going to have to fix something so you're going to have to learn it at some point that's it from a from a gui perspective there are some great applications out there uh there's not enough time and there's talk to go through them but some of the big ones out there is uh github desktop version there's one you can download directly from github there's uh one from atlasian called source tree that's pretty good tower is amazing i don't know who makes that however if you get tower i urge you to get version one version two sucks and it's just really cool right it takes this idea of creating another branch really easy it's drag and drop you take the branch you drag it up and it says hey would you like to create a new branch you go boy yes i do and it's done and you make your changes you commit it and you go hey i want to merge this and you just drag and drop the branches on top of each other and it goes hey would you like to merge it and you go boy yes i do and if it's if there's a conflict it'll put a nice big red dot there and say there's an issue in this file you can open that file and fix it and so i find those things really useful where from the command line perspective those things are a little bit harder to deal with but still very possible tower tower it's a mac only app so if you're on windows no luck yep uh there's some other ones these git box uh that's quite popular there's smart git or is this market i think it's called smart kit i don't like that one because they've decided that they'll change the terminology of git so it's difficult to relate that information into um into command plane when you have to do it and you go what the hell this is me so i'm not a big fan of that the the best one i've used so far is definitely tower but i hate tower two which is the one that currently selling so i don't know if you can still purchase version one uh sorcery is not bad either i've not really significantly used the github one yeah absolutely absolutely um if there's time come see me because i we're running pretty tight in time so um i can show that if everyone wants to stay a little bit there's no no no actually so the process of of doing that this is actually a real live example of the process that you do so i've got some kind of project it's just some pseudocode that i wrote and so the first thing you'd have to do is you first have to initialise an empty repository and so that's literally the command um it's the git anith command so i'll just go back one slide because i didn't explain this if you look at the top the git syntax is always the git keyword followed by a sub command it's the same for every single command those are the main ones you're going to use a net add commit log status so on and so forth those are the main the main ones and then quite often you can pass additional flags that's like additional little operators to the command for example if you do get log you might not want to see the entire log you might only want to show a short little log message then what you can do is you can strip out a lot of that content by passing additional flags to the command the first thing you'll do is you'll do a git anith which initialises an empty repository that just says hey i want to track the stuff in this folder and all its children and it's it's at this point that it creates that hidden folder that i talked about the dot git folder then the next but i'll show you here is the git status command and so that just says hey show me what's happening in my working tree has any files changed and so in this case gets quite good at giving you a little hints about what needs to do it sees on there if you see the little bit purple which is not all that readable it's going to say hey right below that here are some untracked files and you're probably going to use the git add command next because you've already edited the file you're at the point where you say is hey i want to contribute something back to my repository so next you're probably going to fire the git add command it also shows you the files if you've got git colors turned on a command line it will show you the the files and read which is untracked at the moment so the next bit is to add it to the staging area like i mentioned before you're going to get to this little pre-commit area so you're going to fire the git add command which just says hey i'm going to add it to the staging area so there are a few little different ways you can do it you can do git add dot so the dot and command line just means my current location so in that case it says git add everything where i'm at right now so if there's one file or 500th or 5000th file this is going to add the lot to your git repository you can also pass some additional parameters in this is most likely what you'll do you'll probably go git add the file name that you want or the folder that you want to add if you don't want to add everything you can go a bit crazy and you can throw some wild card characters on these here you can go git add star dot css which will only add the css files to the git repository so um here i fired the git add dot because this is the very first time i'm adding content into the repository because it's just still an empty repository until i commit it so it would make sense to add absolutely everything the first time this is very common so you do git add and if you then do a git status what you're going to see is that your file status are now to be committed so changes to be committed down the bottom and it will typically show it in a different colour for you and list all the files it will only list like the folder level it won't literally go into the includes file and show all those for you but they're there from the working tree so everything that's in the same level of where git gets installed it will try and do track all those files the whole lot unless you tell it not to which you will do in Drupal for example on Drupal you would exclude the files folder like i say that that's content managed areas you don't want to track all the pictures that people upload it doesn't wouldn't make sense to do that so that gets excluded quite often you would exclude your like your settings.php file in Drupal that's not something you really want to stick out on version control and say hey here's my username and password especially if you're sticking that on a public hosted service like github and you don't have a private repository probably not something you want to advertise out on the world so usually Drupal 7 is pretty good with including some reasonable defaults for ignoring files it will automatically ignore the settings.php file for you and the files folder but it's quite reasonable that you might want to add a little bit more in our own workflow we're at a local.settings file which is something we change dynamically based on the environment that it runs on so in our local development environment for example in our settings file we'll turn on all error reporting where in our production environment we'll make sure that that flag is set to false so that we don't manually have to go into Drupal for every production site and go turn error reporting off you can just simply turn that on and configuration files in Drupal so the next bit is to record the change to version control so we've now created a file we've added those files we stage them the whole bit so the next bit is to record those changes into the history so we'll do that with the get commit command I'm passing a flag there hyphen m just to make to make the the process a little bit shorter if you don't it's going to open up another little window where you can be a lot more descriptive about your message I always use the sort hand because I feel personally that commit messages should directly relate to what you did and so usually the short messages enough to explain what you did I'm not a huge fan of having big massive commits but your first commit will always be huge because you're adding all your files to the get index so very often you'll see the first commit is called first commit or initial commit or initialised get or something like that because you're not really interested in what change you're just really establishing that you're adding stuff to version control and it's only after that point that you care about change it's going to do a whole bunch of stuff there it's going to tell you how many files you're adding to a version control obviously in the case of Drupal it would be fairly a few more than two how many insertions there was and a whole bunch of stuff the only thing really worth mentioning it will all tell tell you what branch you've made the commit on in this case master and it'll give you this hash number that's the short hash and that is a unique identifier for that commit and you'll get one of those for each commit you don't really need to know it unless you want to look in what happened at a commit at which point you need to hash but you just do like git log and it will show you all the hashes and you then go and show the hash or show the show the changes against that hash so after we've committed it if you do the git log command it will show you exactly what it is you see the full commit hash which is I forget how many characters many and that's the 250th it's a it's a show a one hash for anyone who cares and it's checksummed and so it will show who the committer is and what date it happened and this is a great way I don't want to say to assign blame but if something happened in a project at some point there's another command you can fire git blame it was literally called git blame and you can see who edited what line of code when and so sometimes when you know you're working with someone to go I didn't change it for you oh we'll just check about that right so now you're going to this whole process of editing your files right you want to you know you write more css you add tpl files you do whatever you need to do in the project so I've edited my files if I now fire the git status command you'll see that no longer does it say new files to be added and now says hey these are files that change these are modified files and so it will again give you a little hinty you probably want to use git add to add this to the staging area once you're happy so what I'm going to do in this case is I'm just going to add the first one because I only really want to commit the index file changes here so I'll go git add index.php and if you then fire a git status you'll now see that you've got two states of files you have one that's to be staged or one sorry one that is staged and one that's still just known as modified but it's not staged when you get a little bit more advanced you can have the index file in both states so you can you can say I only want to commit this section of what was changed but that's that's that gets a little bit further on but it is possible so I'll then commit that change and if you do a git status then you'll see that the working tree from what I've just committed has returned back to blank except for what for my unstaged file because I get doesn't know what to do with that until I tell it to do that finally if you do a git log you now see you've got two log messages both describing those things and obviously they're both made by me so it can be quite useful when you want to see well what did I actually change in this file right you I mean you add you add spaces and maybe you indent stuff more so if you fire the git to git diff command which is what I did over here this happens on one line I just made a two columns for readability sake because I couldn't fit it it'll show you what changed and anyone has ever downloaded a patch of group of the org that's exactly what it looks like in fact that is exactly the command your file you'll just read it into a text file that is a patch file right there and then it says hey when you want to run this that's exactly what's going to change the bits and blue there the at at sign refers to the line numbers that changed like I said git only tracks what's changed it doesn't care about the rest of the file and only gets added once and then it just tracks the changes so we know that from those lines and exactly how they're related to the line numbers can be a little bit confusing but that's what it means those are line numbers that changed and then any of the little minus bits and read is what got removed from the file and the bits and green is what got added to the file then you can use the git show command to show what's changed at any given commit so since um you know you you might have a commit that's that's three weeks old and you want to go damn what did I change again I can't remember you can use the git show command and you can pass the hash to it you don't have to pass the entire full hash which is a lot of characters like usually five or six is enough and it will return that resolve here and that's exactly it again it's the same syntax as get diff in terms of what it's showing what got removed what got added so a few more commands is get reset so if you've done some crazy thing and you just want to revert the entire change that you've made um you can do get reset head and that head keyword is written just like that in uppercase and version control and that just refers to the current active branch that you're on so if I'm working in a feature branch and I go get reset head it means get reset the feature branch I'm on if I'm on master branch it will refer to the master branch and so it's just a an easy way to to call the branch that you are and otherwise you you explicitly have to say this is the branch I want to run this command on and if you've got 10 or 15 of these things that come become a little bit painful get push push is any changes upstream to a hosted server somewhere get hub get bucket one of those things get fetch we already talked about that literally just download the object references that changed from the repository it doesn't do anything with that information get merge takes those history that changes that's come in and merges it into your current working tree get pull just do those two things together for you so that's probably the one you're going to use and then finally there's some really good resources there obviously it's a bit of a boring read really as gets direct documentation I find but buckets documentation amazing that's a great place to go to wiki pedia has some got some good information on it as well I really like learning by video content so there's one um from nettoots it is a paid service but it's not all that expensive that will show a lot of demos of these commands and how they work and how to resolve conflicts and those kind of things and then there's there's an absolute great series by Chris Chattick from Brawl the module which is a Drupal specialist and he specifically talked about vision controlling Drupal changes and he all goes through a lot of stuff like features and what can you do to try and do some changes in the database and try and version control that and some good practices and how to go about vision controlling Drupal specifically are there any questions I create I create a branch for every task that I have so if I have a task that sees um build a new view and Drupal I'll create a branch for that because I'll most likely take that view and export it into features I'll commit that features to version control and then I'll merge it into a staging branch I'll get sign off from the client from that staging branch so if we go never ever not on my workflow this this is my own preferred workflow this is not an established standard I will never ever ever ever ever merge stage upstream ever it will never ever happen that's why you don't see an arrow going from stage to production because developers can be lazy and they'll contribute something to in stage that's not been tested and hasn't got sign off so for me an hour workflow you have to push it from the staging you have to push it from your feature branch my staging branches my client sign off branch they happy with the feature we've tested our deployment we know that it works we'll move just that change up into production yep what it does is it adds some code to your document so it'll go you're always on a particular branch when you're going to do a merge so let's say you want to move changes into stage so what you're going to do is you're going to switch to your stage branch and you're going to fire a command let's say we're committing that first change related content into it so the command is going to be get merge feature forward slash related content and so gets going to come back either it worked or it's going to say whoa there's been an issue and it's going to say the issue was let's say it's on index.php when you open that file up there'll be a whole bunch of arrows and stuff that shows this is what it was this is what it's going to be and you can just manually resolve that it's that simple it's it's it's quite clear it looks scary as hell but when you actually look at the lines of code it's not a big deal if you use something like tower you might know intrinsically that hey my new version that I've just committed is right I don't care what's in the other version it's really convenient you can right click and say resolve using my copy as opposed to the known copy and so from that perspective it's really good but it's not always the case I think these guys are going to kick me out you guys will have to talk to me after yeah I have no idea I've never seen anything of Drush and Get work together oh right okay okay that's because you can do updates to Drupal in two ways you can do it by just replacing the module which is typically what Drush does or you can use version control to do it it's a lot harder so you can say hey no no I'd run these updates by pulling the references from version control but that really requires you to install Drupal in a very specific manner rather than downloading the zip files or using Drush DL to download those files you would specifically have to download the the get clone versions of those modules for that to work