 Good afternoon everyone. Thanks so much for coming it today to get makes me angry inside I hope that you will find this presentation delightful and entertaining much like I find to get This is it's a fun presentation. It's not a strict hour of me talking there will be activities You will be we will be doing things in your chair to help you to learn get It's a different a different approach than what we would normally take to teaching software, and I think it's I Think it's a fun way to do it So you can let me know at the end in the session evaluations if you agree with that or not I'm Emma Jane formerly Hogman now Westby which can be confusing because my books have my old name on it And I go by my new name and I'm a beekeeper Up in Canada, which is probably the least relevant piece of information about me that you'll need to know I work for Drupalize me doing mostly project management now, although I've been teaching version control for almost as long as I've been doing Drupal, which is over a decade so it's um, I've been doing it a while and If you're an IRC obviously not at this very moment. You can ping me. I'm Emma Jane and on Twitter Emma Jane HW and I am I do actually keep bees and that is actually me And I I do I've got this tiny little favor my my mom is back in Canada, and it's her birthday today So if you'd like to play along if you can send her a quick email and just wish her a happy birthday I'd be most appreciative It's Marianne at gingerpress.com just you know if you wanted to play along and wish her a happy birthday so We'll get on to the actual work part of this presentation now and I Want to start out with a bit of a detour before we get to the get part on adult education Most of us in this room We often have a few kids who wouldn't fall into the adult education category So we would be looking at pedagogy instead of andragogy but ultimately we're a bunch of adult learners for the most part in the Drupal community and the way we teach things as a community of teachers and a community of learners when we set out to figure out all this stuff is not exactly in Adult education best practices so when you say to yourself I've tried to learn this stuff, and I just can't do it It's not making sense to me typically. It's not your fault as the learner typically It's the educators fault for not having presented it in a way that is using best practices as far as adult education goes And I especially find this around software where you've got specific commands The the tendency is to teach the commands and not the concepts or the reasons why behind that software and how it applies to your specific work and Quick quick show of hands to start here. How many people will raise their hand when asked? Okay, so that just calibrates the room for me great and How many people here are Linux kernel developers? And I'm seeing about two hands so for the most part we are not Linux kernel developers However get as a version control system was written by a kernel developer for kernel development It doesn't mean that we can't use the tool It means that there's a lot of things that are built into it a lot of assumptions That may or may not be relevant to web development and Drupal development So when you're approaching it remember this is a and it's not to say that Beyond you or out of reach or too smart or too stupid for what you are able to do It simply is a tool designed by someone who is not working in your space for the most part I did see one or two hands, so Don't don't be intimidated by the software, but start thinking of of yourself as an adult Who needs to learn and start perhaps? demanding Some of the adult education best practices that we do see outside of the software industry in terms of how How adults actually get to learn? and One of the things that I quite enjoy being able to say is that adults learn best when they get to be selfish So the work the lessons rather need to apply directly to you and to your experience You need to be able to see how on the job. This is going to benefit you to really be able to internalize that information and Perhaps obviously Perhaps not obviously depending on who your clients are We are never paid to memorize get commands and yet there seems to be this culture of Having to memorize everything and hold everything in your brain What we're going to do today is actually put some of that Information out onto paper or in into your notebook Wherever you want to actually store that information But get it out of your head and into a place that you can refer to more easily You're not being paid to memorize this stuff. You're being paid to do Drupal development So let's get back to Drupal development as being the core goal We need to start with Solving or looking at the whole all of what's happening before we can solve your real problems And when I talk about the whole I don't mean what all of the whole or what all of the get commands are What I mean is More to do with how we actually approach learning so typically what we do is we start When we're learning version control with simply trying to memorize those commands and remembering something is it's only one Way to advance your learning This is a blooms taxonomy that I'm showing you right now which in part I'm showing you the diagram because Drupalers love the word taxonomy But it is it's all of those different phases that we go through as a learner When we get up into the sort of higher level domains of learning then we start to look at Applying that information so it's not just a strict memorization You know, what's the command to to do whatever the task is But how do I apply it and how do I structure my workflow so that the command that I've previously memorized Can be applied correctly and what I would suggest is that for many of us We're already working at a much higher level when we are thinking about our teammates But what we don't know is how to connect to those get commands So as you're going through the exercises that I've got for you today think about Where where am I on this scale and give yourself permission to be? Sometimes at a higher level you want to think about how to apply this information You want to think about how to create new workflows and and those are more difficult concepts, but more In some ways more important they're going to dictate the things that you need to memorize and if you're relying on someone else for that information You're not always going to get a great connection between which commands Do you need to memorize in order to solve what problems? So we're going to start at the very top of that pyramid today or the top of the triangle today and talk about what are the problems that you're actually trying to solve and therefore what are the get commands that you need to memorize and learn and Create a cheat sheet with so again. It's a little bit backwards What we won't be doing today is we won't be opening up a terminal window We won't be opening up any specific get software because you can Google that stuff once you understand the problems that you're trying to solve In terms of those workflow dynamics you can look up the command that you need to run and I have to say This one and some of my teammates are in the room today So when I need to figure out which branch I'm going to review in terms of the peer review I need to ask the server what all of the available branches are there's four words I do this on a daily basis get remote show and origin. Do you think I can put them in the right order? I get get first usually But there's still this even though I do it on a daily basis I still use my reference sheets and it means that I don't have to memorize things because I trust my reference sheets to Hold the information for me and I use get as a tool instead of get treating me like a tool So as I said, we're not going to be looking at specific applications today. There's too many variations out there There's too many different little configuration tricks that make that software so unique to us as individual developers That it becomes very difficult to teach them in a generic way So I'm going to teach you how to think about it and not what commands to apply If you're hoping for the specific commands to apply and this is a going to be a disappointment to you I will not in any way be offended if you get up and leave I would rather that you are at a session that is useful to you again adults selfish liners You're allowed to be selfish and if this isn't meeting your needs. I won't be offended if you need to leave so with that in mind I Would say that in the workplace 90% of the problems that you are dealing with are social you are dealing with typically a piece of software that was written by a person who was trying to solve Someone else's needs and it may or may not have anything to do with the problems that you're actually trying to solve So when you start thinking about how do I modify the code? How do I work with my co-workers? How do I do all of these things? There's often many best ways to do something and how you resolve that ends up being it ends up being a social problem because we need to decide as individual team members when I work with my teammate how how are we going to do that and It often doesn't really matter But you need to be consistent and you need to be following the same steps over and over again So the first thing that we need to do when figuring out our workflow so that we can use get is we need to figure out Who are the people on our team? What are their roles within that team? And what are the tasks that they complete on on a regular regular basis? The more that you can document what those tasks are the more you may realize that you actually have a series of tasks Which can be automated so instead of memorizing 15 commands It's quite possible that you can have a script which will run those 15 commands and you issue one Script instead of doing 15 individual things But you need to know what those tasks are you need to have them Documented and as you follow the documentation you may start to realize you know This is the same thing over and over and over again. Is there a better way for us to work together or Automate our workflow and these are this is a mishmash of diagrams. This is not meant to make sense But is there a way that we can work together that is even more efficient It's impossible to know if you don't have that documentation and you don't have that conversation on how you should be working So we'll start out with the first activity and yes, I am actually going to Be quiet for bits and pieces of this so the recording will go will go quiet for a while Well, I give you a chance to work on this So the first thing I want you to do is actually yes get out a notebook And I'm just going to stand here and stare at you for a minute so we can just stare at each other or you can Do it But I want you to write down who is on your code team may include Developers designers project managers QA But when you think about your coding team, which probably is different from your marketing team is probably different from your HR team Who is on that team? You can write down Names of specific people or if you're in a very big company You may want to simply write down roles instead and I'm going to give you One minute starting now to do this. It shouldn't be that difficult You should be able to write down the names of the folks that you work with Okay, so the next piece that we need to add to this is Essentially, what are the tasks that each of those people do on a daily basis or where do you fit in as as team members? What I'd like you to do at this point is beside each of those people write down what those folks are actually responsible for So are they responsible for writing code? Do they review code? Maybe you have a peer review system, so you're both responsible for writing and reviewing code Do you have one person who is your? Essentially your technical gatekeeper that only they are responsible for pushing code to the server basically what are those tasks that That when you think about them in a git or a version control context, what are the tasks that you're trying to complete? When you're working with git, I'm only going to give you 30 seconds for this one In part because it's going to be a very long list and I just want to get you started So another 15 seconds. What are the tasks that you work on when you're working with git? So the next piece what are the tools that you're working with and what are the? Constraints or restraints that you've got on your particular project. So in this case, we're starting to piece together the actual workflow Diagram and this is where you know You'll end up doing a bunch of different versions of this picture if you're actually drawing it out because you'll need to shuffle things around So my tools and restraints for example will have version control software. I assume it will be git Perhaps it's not actually git that you are using right now. Maybe you're actually using subversion or One of the other systems that we could all choose to ignore So we'll assume that it's git that you're using what's your code hosting system, which could be Bitbucket or github or unfoddle or what are their systems do people use to actually store their code in? Not necessarily your ticketing system, but where do you put your code? Just shout it out Assembler is that what I heard? Where else? Anywhere else Drupal.org yep, okay And then what's your server ecosystem? So do you have a development environment a staging environment and a live or production machine? Draw out those boxes You may also want to write down what the code editors are In part because it may affect how you review the changes between different branches and then I'm this is not very common in web development software for Client projects, but it is in product software. So when you're working on Drupal the product You are much more likely to have a testing system of some kind with test bots or test gates So in your system if there is a period at which code doesn't get accepted Before going through some kind of automated test you'll want to know that as well as you add things to your page You're going to see You're going to get to see the complexities instead of having to store it in your head And the goal again is to get this stuff out of your head and onto something that you can actually review With all of those pieces we now need to figure out how to shuffle them in a way that we can put them in order So I said, you know, you'll do several variations of this sheet as you go through it You've got all of your your characters or your actors now We need to figure out where they fit onto the stage So the next thing that we need to do is figure out what the workflow is or the the flow the the transition of Where code goes at each of the different stages? I've got two different variations In the sort of old way of doing Drupal We would have one central server if we were lucky We had something a little bit better than just ftp'ing the files up to the server heaven forbid We were actually editing them live on the server, but you know web development has changed a lot in the last decade or two So in a centralized workflow, we've got everyone working on one single machine This is what we want to get away from but unfortunately Still as of Drupal 7 it's what Drupal almost encourages us to do by storing so much of the configuration information In the database directly We did a workshop on Monday which talked more about using features and drush and strong arm and What were the other things we talked about many other things and on how to to get away from this centralized? idea of having things live in a single instance What what we want to move towards is a more distributed system that has each developer able to do their own work at their own local workstation as soon as you make that first separation it becomes Cheap or easy to add as many extra steps in there as you like So as soon as you take yourself down from that one central server and give yourself a local workstation It now becomes really easy to give yourself a development server and now becomes really easy to give yourself a Qa server how many people at this point? Already have some kind of environment set up where they have a local instance a production instance and a development server Hands way up. Is there anyone who's not in this position? Okay, cool So the next step for a lot of people is going to be taking that human gatekeeper and now making it an automated gatekeeper How many folks are working with some kind of? Continuous continuous integration server or some kind of automated something a rather I'm guessing it'll be about a third. So yeah cool So at this point what I want you to do is take a look at the people and the computers Don't worry about the get commands that I happen to have up on here But think about on a daily basis What are what are the directions that those arrows go in general? You should be pulling your Code down from your code repository. You should be pulling your data down from your production machine We always want to get the the closest to real data in terms of user-generated content as possible And then we want to push only the code parts back up to our code repository Which may then trigger for some of you who've got the automated stuff once that code is up in the code repository it may automatically go out to the Development or production server depending on what's being used But just sketch out for me now And I'll give you a minute or two and now is a good time to start throwing out questions If you're not quite sure what your diagram should be doing But go ahead and start drawing those arrows between the people and the machines within your team Ultimately, this is what you're working on right now I'll leave up the diagram version of it instead though Just because it's easier to look at a picture sometimes than to look at words I'll give you three more minutes to do this How many people think I actually gave you four minutes too long? Hands up. You know, you probably had four machines. You probably had like Three maybe up as many as ten people on your team. You probably drew about Let's say ten arrows. How many people had something more complex than that? No one How many people are checking email? Nice So let's recalibrate the room. How many people will raise their hand when asked? Okay, good. All right So now we get to the actual hard part and the the nice thing about doing the the sketches this way is that you go from My god, why is she wasting my time? to Something really complex and what we're going to actually build up now is taking a look at How those pieces fit together in a Branching strategy. This is probably one of the most Common workflows that you'll find if you're doing a quick search on the internet. How many people Recognize this diagram for how many people does this diagram look familiar and Then we'll do the opposite. How many people have not seen this diagram before again Just recalibrating and for how many people typically my project managers will go like this Yeah, that makes sense. It's fine How many people for whom or raise your hand rather if this diagram is Is a comfortable and relaxing place for you to be and are you a project manager? Yes, no Developer, okay. Yep. Um, how many project managers do I have in the room? A few and and if you turn your head sideways, do you see the timeline? Do you see the Gantt chart? It's kind of like seeing the Rorschach. Do you see it? So what we have is time moving forward and we have a series of different kinds of branches that are interacting with one another for most Saying human beings. This is not a fun diagram to Understand even if it gets built up slowly over time The article does do a really good job of explaining why each of those different lines has come to be however in in most cases this works for a Software product and is not necessarily appropriate for a website workflow So what we Can do is use it as a reference point But also drop off a number of pieces which are simply not important to us And I would say start at the most start at the beginning start with nothing Don't start with everything and try and implement it But start at the beginning and then make the decision of how you're going to actually work together and build up So the first thing that we're going to do is we're going to add in our team members with our Code repository the team members are going to pull that code down They're going to probably and hopefully do some kind of peer review and then Push the code back up into the code repository. Yeah, not mandatory, but highly recommended The next thing we're going to do is add in a public web server and that public web server is Where it's It's where the the world comes to see what you've built now as soon as you've got Developers working separately and a public web server. It's dead cheap and easy to add in that development server Here we go development server. So now we've got two servers and times as many local developers as you've got Now now we start to get into branches Where do we actually or how do we actually divide up our code? So that we've got things happening where we want them to happen so the first thing that we're going to add in here and This is for those of you who love get and love your workflows. Please choose your names According to whatever suits you best This happens to be the way that some people do it So they take their branch called master and they say master is always going to be stable And that's what's going to go on our live website Some of you are bobbing and some of you just gave me the look of death and dirtiness So this this is where things get a little bit controversial and a little bit Like just change the words keep the colors So now we've got our master branch that's working and look at where the master branch lives How many how many places do you see the master branch in put up a show of hands or a show of fingers rather? You haven't got that many hands. You'll need to use your fingers Fascinating there's threes and fours. I Would say that there's four blue widgets on the screen So for those of you who are seeing threes, are you counting shapes or are you counting colors? Shapes count colors Okay, so so if if the code is going to live in In each of those different developer environments in a code repository, that's another place That's the circle instead of the strict line and also on the public server That branch is going to be now those branches live everywhere But where do they actually get used only in some places? So now we've got master How do we look at the code that's actually being worked on we're going to need another branch and that branch In this case is going to be called dev again call it whatever you want call it Frank if you want I really don't care, but if you have a naming convention, which matches what other developers are doing It's easier to have a conversation, which is why we have those conventions But you could call it magical pony if you wanted you could call it Frank. It doesn't really matter get doesn't care so now Kind of a trick question kind of going back to what we just did in how many places does the dev branch currently live? Okay, I'm seeing only fours this time good work All right, so again pretty straightforward stuff now How do we actually work on individual tickets now? We need more branches again and the the branches at this point start to get a Little bit more isolated so when I work on my individual tickets I'm going to start on my Local machine and when I'm ready and this is where the diagram you can only get to so many layers before it Starts to get more complicated, so I haven't pushed any of my feature branches back up But I've got according to the the envy diagram that I showed you before I've got two different kinds of branches I've got features which are things that I want to be working on And I've got hot fixes and a hot fix is who'll crop something broke on the internet and we need to fix it now Where you branch off of is going to change based on the type of work that you're doing So now that you've seen that diagram Mashed onto the super simple workflow we can introduce and unfortunately I don't know that the screen is big enough to see those colors, but the colors correspond to what the diagram had before So now you can start to think about that diagram, which may or may not have made sense We took a super trivial people and squares representing computers drew some arrows And we've added to it that branching information I'll come back to the slide that I just showed you But what I want you to do right now is think about for the different places where the website that you're working on Exists and exists in a different state So your production state is going to be different than the new module that you're currently developing If they're there, of course, they're different. You're doing different things on those machines So what kinds of branches will you need in each of those different places in order to represent the different states? And I would say oh, I have to go through this Hate slide builds shouldn't have done this to myself one more okay there and from from this list of Scenarios or branches How do you typically Work do you have tickets that you work on? Do you have a live website? Are you working on a product? Like if you're working on a public Drupal dot org module You don't really have the concept of a hot fix really You're constantly moving forward, but there's not there's not a live website that you need to patch up and fix up You're probably have some kind of stable Master branch that you may want to put a security fix into But probably you're just going to tuck the extra features you've been working on as well we are also in terms of time we're about the halfway point and It's going to be opened up to huge amounts of Q&A for people to say okay cool I know how this all fits together, but now how do I go about fixing the particular problem that I've got in terms of What What's the get command I need to issue at these specific points and when I'm in this scenario So that that's what we're going to do for the the remainder or the bulk of that presentation But I I do want you to sketch out again. What are the the branches that you want to work with? based on The situations that you've got The feature branches and the hot fixes are basically throwaways. You don't keep those over time, but the The dev and the master are branches that are consistent. They stay with us over time These slides are also already uploaded as a by the way. They're in the comments of the session description Have you added on or do you have questions? Does anyone have questions who is playing along? About how to add on those branch branch names for your specific diagram Great so like I said the the bulk of the presentation I would be delighted to Answer specific questions and we can we can talk about the commands But I think that in a lot of ways we get more value talking about the the strategy of how we work together and how we We move that code around. I we can talk about specific get commands as well but often there are workflow questions that The command itself doesn't matter. So if you've got questions, there's microphones on either side there But I'm I'm effectively done sort of presenting at you So if you if you want to go and catch the end of another session, this is the time to do it I think I've given you enough to start thinking about how you're structuring your workflow There's a couple of resources in there in terms of branch management strategies And again those get commands once you know the action that you want to accomplish It becomes much easier to do a search for whatever it is that you're trying to do Questions. Yep. Go ahead Thanks for the presentation. I must say that early in the piece. I already got a bit confused probably because Conditioned by terms used in maybe all the tools sure. Yep So for my benefit of maybe for some people in the audience as well Can you explain the difference between a branch a fork and a checkout? Yeah, for sure Yeah, because For sure. So in terms of the specific terms when when we're working with Can you see those? Can you see the? Is this dark enough that you can actually see what we're looking at? Only just only just okay, so the the reason why this diagram got Killed off from the presentation is because it's it's not dark enough to actually read it at the back of the room So when you're working in get you've got a series of different actions that you're going to perform You've got the adopter download actions. You've got review actions compare actions Reset save and distribute the checkout Branch and what was the third one that fork was that okay? So the the concepts that you're working with at that point are all take concepts or adopt or download concepts, right and the The fork is the the first step if you're using a Forking workflow where you create your own instance of that project typically we use a forking Workflow if we want to maintain strict permissions where only one or a very few number of people can actually commit back into the repository So we need to separate our copy of what's happening from the original project and Drupal is a perfect example of that Dress and the core Co-committers are the only ones who can commit back in so if we want to play around with the code base We need to create our own copy of it That's the concept of a fork now we tend to work in patches not in forks But that's the same separation the same idea on github. It's a fork as opposed to a patch There's pull requests instead of patches. So this is where we start getting into more words But that's your first concept fork is taking a copy all of that information now becomes yours to control The next piece that we're going to mention is branches within that Main repository we have a number of different states that the code can exist within Each of those are referred to as branches now even within the branches We've got our concept of our working space and the concept of how the code is stored our working space Isn't we typically work within a branch, but you can be working in a detached head so the branch is that cluster of Files in their specific states and we can check out any of those individual branches and switch Switch at the files the states that the files are in now. I have to It's sort of a weird thing to get it entertained by but I I really had the magical moment of version control when I had a That's the word that I'm looking for like a visual display of a list of files So not at a command line, but a visual listing of files up like the thumbnails right for the individual files and I did Get checkouts on different branches and watched as the files appeared and disappeared Over in the other side because that's effectively what a branch is it's I'm in the same directory Nothing has changed and yet when I switch the branch some of the fields some of the files rather appear or disappear depending on what that branches State is shall we say does that help with those individual terms? Okay, other questions Can you can you speak it I just can't hear what you're saying, so can you tell me the difference between feature branch and What's the difference? So in a feature branch, you're actually working with a specific cluster of code When we're referring to a diff is that we said di ff We're simply looking at a comparison between two of those different branches So if I want to again in I'm sorry that this isn't dark enough to see But if I want to be able to compare two branches and see what's changed because I'm reviewing it I might be looking at a patch file or I may simply be issuing the diff command So in in drip Drupal, we've got that version control option just in terms of the text stuff A diff in git is exactly the same concept It's simply showing me what the difference is between those two branches or two states of code Okay, so in terms of the feature branch the feature branch is the the newest amount of code And your workflow is going to change based on what they agreed upon Steps are for your particular team. I very much prefer merges. My teammate Joe very much prefers rebasing We can definitely talk more about merge versus rebase, but I think that to choose My general question is like if I'm working on a feature branch, yeah, absolutely So I finished with the feature now Mm-hmm what I'm going to do now is it going to be do you have a peer review process in place? Yeah, okay Like I've done all that. Okay. What's the process of going production now? So you've got your feature branch and you want to get it over to production Yep, so then from your master branch you're going to check out your master branch Yeah, and then you'll say merge and whatever the branch name is that you want to pull in Okay, I still don't clear. It's not clear that what's the difference between Dev So what do you do in Dev then? Development is what happens when you're still trying to decide whether or not the code is safe So if you've already decided that the code is safe you can pull directly from your feature into master Chances are though, you're going to go from feature to dev You'll do your testing in dev Yeah, once you've decided that dev is good and safe and you're ready for a release you'll go from dev to master So dev is basically for testing. Yeah Other questions I kind of have a follow-up question. Yeah, for sure So it's dev always an exact copy of master or how does that often? So it depends on how quickly your release cycle happens Often teams will have a weekly release cycle, so you'll be working or But again, it completely depends right? So we've got two-week sprints that we work on so in theory master will be two weeks out of date from dev I'm not sure this is a this whole world is kind of new to me but yeah, it's a lot of talk about code and Doing development on that side and that's kind of where I sit Working with designers and files and changing changing on that side sort of how does that? How do we get designers into that workflow when it's just changing an image when the image stays the same size? Is it still wise to go through this sort of same work workflow on that people first? so you always have to look at who's on your team and At what point are you causing extra overhead for that particular team member to participate now on? The Drupalize me team our main designer that we had been working with was comfortable enough with version control that he put most of his mocks in terms of HTML and CSS so they mocks wireframes I'm sort of I'm pausing because we weren't working directly from psds. We went straight into into wireframes He was comfortable enough that he had his own repository, but he wasn't committing directly to our repository He did however have tickets that he'd open and then updated his own github repo with the design changes that we needed to implement We would then pull his changes into our repository and move forward from there now our new designer Doesn't have as much version control experience so I expect that the workflow will change to a certain degree and that's where with your designers you can You can decide that it is important to Take them through the learning curve of working with your particular workflow system Or you can simply assign someone to be doing those check-ins for for the designer Yeah, other questions in your in your diagram that had the circle and the rectangles where people were three or four So is and the circles were the repository now that in your diagram that doesn't live any anywhere and then that's sort of like a Anywhere anywhere is such a great question The other things were in physical places Yeah, they all lived somewhere that the difference with the circle is that the circle wasn't visible as a Drupal website, let's say it that way So that the code repository's job is to store the code but not to display the website so anytime I actually want to be able to and Again, I'm going to assume that we're all referring to Drupal woman referring to code so if I want to be able to View my view is such a loaded word if I want to be able to look at my website I need to also have an Apache server. I need to have a MySQL server I need to have PHP running, but if I just want to store my code like if I go to Drupal org I can't see a live instance of any of the particular projects. They're simply hosted on Drupal org So you need to download the code from somewhere and spin it up inside some kind of web server So the straight lines were web server boxes and the circle was simply a code repository Its job was to store things but not to display or allow Developers or clients or the public to interact with the content or the website So everything else would be sort of interacting with the with the repository So if I wanted to load something from dev to To my my site that's serving I'd load something up to The repository and then again from the repository to Live site each of those if I sorry And I have to go through the build again on this That built up now I'll come back and explain it for the microphone, but just let me if I point at things that'll make it easier for everyone I think yes, thanks There are no stupid questions only my favorite questions That's okay Data Yes So the workshop that we taught on Monday talked about some of the challenges of putting Drupal into version control and in in Drupal 8 we'll have the configuration Management initiative the CMI stuff going in but in Drupal 7 We don't have anything very elegant and the slides are Posted somewhere for that workshop. I think but I'm not entirely sure I'll give you my card in we can figure that out, but the the ones that I mentioned were features strong arm Drush Sea tools What am I missing For those of you who are Get lovers and know what the other stuff is that I'm missing. How else do we get I'm just I'm blanking on it How else do we get? Configuration out of the database and into code. What are the other Drupal modules that we use for that? Is that most of them? Okay. Hey, thanks Chris So you can go bug Chris as well now that he's like answered half of a question rave it raise your arms. Come on. There we go Go pick on Chris at the end. Yeah, you're welcome Yeah What's the best practice on what's actually in the master and Hoppies Great question. Yeah, what do you actually put into get is basically so there are for every developer out there There's about three opinions on how to do this The way that we do it now has changed over time and This is as soon as I say something I'm really I'm like, oh you guys aren't gonna like what we do But this is what we do because it works for us. We put everything in including Drupal core and our design files, so from the From the root repository. We also have doc root. We also have wireframes. We also have documentation. We also have our patches testing private files Everything exists within that get repository because it makes it a lot easier for us to spin up an instance of a machine and Make sure that everything is in there now User-generated files are not version controlled So if someone uploads a picture of themselves a new avatar that isn't stored in git, but everything else is Within that structure git allows you to do nested git repositories. We don't use git sub modules We found that it For a variety of reasons we don't use git sub modules But git and this is part of why the Drupal project chose git allows you to have one git repository up here And then if you want to you can have another git repository down here depending on who is doing the Code the contrib code updates. They may check out a new version with git or they may simply do a drush download it just depends on on how They're working with that piece if they need to patch for example a contrib module. They're more likely to Check out a version with git and if it's just a straight upgrade. They don't have any patches that they're dealing with They're more likely to do a drush download So yeah, I have a question related more to commands adding files to git is very easy when you delete the file somewhere In a controlled environment you do git status. It says you have to remove the file you try to remove but it's gone already Great question this happens all the time to me So just to make sure that I'm understanding the problem correctly you've you've intentionally or perhaps unintentionally removed a file But you got it wrong. What you needed to do was do a git remove on that file What you can do is reset that file and it will grab a new copy of it It will bring back the old version and then once it's brought back because git remembers everything You can then go ahead and do a remove on it Get RM to remove the file Yeah, but you can bring if you delete a file and gets like hey, I used to know about this file It's missing now. I don't really know how to deal with it Do a reset on that individual file to bring it back so that you can then use git RM to actually remove the file I've done it more than once You just have to manually type in the path that it used to exist at and get it to toss it out So if you use the f flag f for force I assume is what that one is then you can go ahead and just use the path that it's telling you in the git status line Yeah, it can be like miles long so you can copy and paste I I have to admit I pull it back and then delete it properly So again for every developer out there There's going to be three different opinions on how you can do something which makes it very difficult to learn because it's too flexible question I'm sorry. I just want to add to that part. Oh, oh, see If you have a lot of such files, it may be just very time-consuming Git RM issue of this you can just Go on and run git add dash you and it will just remove all of them from the index Brilliant. Thank you This Yes, so Chris just clarified so you're using git add to remove and the answer was yes There's been some talk about I'm far too sober It's a We have about five minutes left I would be delighted for other people to answer that question And I think they're sitting in the back corner based on the It's it's a bigger question than what I have expertise in so I will refrain from having a recorded opinion Any other questions we can leave it on that Okay, I don't see any other questions as I mentioned the slides are already uploaded Which is my tricky way of getting you to the evaluation page and please go ahead and fill out the evaluation Thanks very much for coming today everyone