 Good afternoon everyone. Thank you so much for coming today. The last slot of the first day is always a tricky one to maintain attention for. So if you decide sort of halfway through that you've gotten a bit overwhelmed by today and need to slip out, the slides are already uploaded and of course the session is being recorded. No personal offense will be taken should this not be meeting your needs in some way. This talk is hopefully going to be a little bit of fun. I have injected more animated gifts than I would normally use and we'll we'll sort of get into the reasons why in a second. But the again slides are uploaded already gitforteens.com and also on the session slide. The first version of this talk had a lot more about git in it and I really wanted to make sure that it was useful for site builders and I realized that perhaps this style of diagram at 5 p.m. after a full day of conference presentations would be maybe not a lot of fun and maybe a little bit mind-twisting. So with apologies for those of you who haven't seen the Princess Bride and don't already have the whole thing memorized. Hello, my name is Emma and we'll be going through the use of features and git. I'll be talking a little bit about Drush as well and some of the commands that you'll need to know how to run in order to work more efficiently as a site builder with each of these different Drupal tools. Now unfortunately with only an hour in this presentation what I will not be giving you is a first-timers guide to using the command line. I won't be explaining how features works in any great detail and I won't be explaining git in any great detail. So before you all run away I would encourage you to even if you aren't experienced in any of those tools stick around I do try and give a fairly high-level overview of how the pieces fit together and the sort of section at the end where we get to essentially the wall of text the wall of commands may be something that you might gloss over a little bit to start this time around and then when you come back and look at the slides later on you may find it a bit more useful. So I'll start out with sort of a 20,000 foot view of how things work and then I'll kind of slowly descend into the pit of despair of using all of these tools at the command line. So we'll start out with some easy diagrams we'll end with some fun animated gifs and hopefully it all makes sense along the way. So first piece that I wanted to give sort of a quick overview was of the features module and just as a quick show of hands how many folks are familiar with features already and how many people just refused to raise their hand when asked. Fantastic this gives me a quick room calibration thanks for the two in the back who played along with that one. So the gist of it though is that we're going to go from a point-and-click tool and we're going to convert it into code and the advantage of doing this is it allows us to move that point-and-click configuration from one environment to another one. And if we're giving a very sort of high level overview if we think of this as being in a peer review situation so before we get to the deployment process because of course everyone does peer reviews. Yeah not even the two guys at the back who refused to raise their hands on this one. So in terms of sharing those those features around you may be doing it during a peer review process you may be doing it when you move from essentially your local environment into your development or your production environment but there's essentially people and there's code hosting systems at this stage and what we do is we start looking at how stuff moves around. You can see if we read this diagram from left to right the first thing that we do in a code review processor when we're sharing a feature is we go ahead and we pull or clone the the code base down to our system. We go ahead and create a new branch we work on that feature we push it back up to the code hosting system and then the reviewer over on the right hand side pulls that code down they take a look at the code they either accept and publish the changes back up to the code hosting system or they reject the changes and ask for some refinements or enhancements to be made. That's you know at a very high level how we generally work with Git. Now deploying with Git gets slightly more complicated and the way that we normally look at deploying code is we have this kind of graph. We start with our local environment as a developer or as a site builder and then we push the changes up to the development environment and then we push the changes up to the staging environment and finally we push the changes up to the production environment. But of course it doesn't really work that way. I am telling you a bit of a lie when I show you the simplified diagram and as perhaps you have already experienced it's much much more complex than this. In fact that simplified diagram probably looks a lot more like this diagram here. So what we've got in our deploying code diagram is that same initial triangle essentially where we went from one person up to the code hosting system and then back down again except we're doing that round trip times each environment that we're working in and that can make it a little bit frustrating and confusing to work in. But the nice thing about it is that it tends to map quite well onto how you may want to take advantage of branches in Git. So there's sort of some light color coding on this. I don't know if it reads well all the way to the back but if we skip ahead to this one here we can see that essentially each of those different environments can map onto what a branch would be in Git. And this is more or less giving us the Git flow model. How many folks have heard that term before? Right on. So it's about three quarters of the room. How many people confidently use Git flow and understand how each of those branches works? I'm going to guess it's a lot less. And it tends to be something that we talk about and yet we can't always take advantage of the full piece of it. So one of the things that I always like people to do when they start using a new system is they take a look at diagrams and if I had to draw out what I was going to do on a daily basis and I was going to color code all of that information, how would that map onto my experience and then what are the pieces in Git flow which explain all of those different parts. I'm just going to come back up here to these two here. So branches allow you to separate instances of ongoing work or in the case of that four-stop initial diagram, my local environment, my development environment, my staging or my QA environment and finally production. So each of those can be its own separate branch. And those naming conventions or the strategies rather that we use are simply conventions and almost everyone put up their hand as being familiar with Git flow. And Git flow is it's not the only way to do things but it's certainly a very popular way to do things for many website developments that have that staged approach to deployment. How many folks are in any kind of automated deployment system at this point? I'm going to guess. There's a few people who are like, we want to be and sort of half raising their hand. So you may not follow exactly a Git flow model because you may not have a staging environment, you may not have those same environments. So your branching structure may end up looking quite different from what we're not different simplified from what Git flow describes. So now we can take a look. We've sort of glossed over the Git flow piece. Many of you were familiar with it, so I didn't spend a lot of time on it. And now we start looking at, okay, so how do we go ahead and take advantage of this to be able to share features with Git? And at the back, just show of hands. Can you actually read any of those words? Some of you are lying. Yeah, okay. So if you do go ahead and download the slides, then you may be able to follow along with some of these diagrams. They're quite small, I know. So what I've done here is I've taken my original diagram, and this is why I really like diagrams because as soon as you start drawing arrows in there, you immediately can start mapping on the relevant Git commands at any point. And I, for the most part, will use diagrams. Other people have used comic strips, though, or just anything that makes it into a visual piece. And the more that you need to think about how you're building up the information, the more that you're going to learn about how your own process works. So same diagram as I had before. We've now, however, renamed our arrow from step one. It's now called clone or pull. And then the arrow back up again is called push. And down at the bottom I've got my checklist of things that I need to do as a developer. So I'm going to check out a new branch. I'm going to add the files to it. And then I'm going to commit and finally push it back up again. On the review side, it's a little bit more complicated in that I've got the checkout of the existing branch now. I'm going to do the review. I'm going to check out dev. We'll get into more of this at the very end. And then finally merge that new feature in. But with a simple diagram, you can start to map those commands on. Features and their related export modules are not always the most consistent experience. And I had a very, maybe the word is interesting, conversation with Mike Potter a few weeks ago about this. And we were talking about what are the pieces about features that make it really frustrating for people. Because people, people, I'm using my air quotes to mean me always. And actually I don't need air quotes on that. I always complain, definitely don't need air quotes on that one about features. And we had a really interesting conversation about what is really the problem? Because he was rightly so insisting that features is a lot better than it used to be and yet that hadn't necessarily been my experience. And it hadn't been the experience of the developers who were using features and the experience of the site builders who were using features. So we went back and forth a little bit. And that's why this sort of extra bracket in there exists in there. And it's related to export functions. So in a lot of cases features itself is simply doing what the export module told it to do. It's just doing it in a way that wasn't necessarily what we expected it to be as a site builder, as a developer or as a person working with Git. So what we need to do is we need to improve the consistency of what gets exported from our database so that when we actually put things into Git and they move over into a different environment, they get imported in a more reliable way. How many folks are already using Drash by show of hands? Amazing. Why are you guys here? All right. So that was pretty much 100% of the room. Even the two at the back who refused to raise their hand when asked. And so normally I would have to go into my why should we bother working from the command line lecture? I don't think I need to do that with you folks. But I would say that it can provide us a more, it can provide us a faster route to a more consistent experience. I tend to not trust graphical interfaces. Not that I should trust the command line anymore. But at the command line I find that I can copy and paste what the error messages are a little bit more reliably. And I can find copy and pasteable documentation as opposed to locate this button on this screen. Locate that button on the next screen. That's very difficult to document in a reliable manner. So I tend to, if I'm feeling uncomfortable with something, revert back to the command line where I find that the instructions for me are a bit more reliable. So Drash, again, for the recording's sake, because folks all know what it is, a command line shell and scripting interface to Drupal allows you to execute Cron, run update.php, work with features, clear cache and much, much more. It still doesn't make my coffee in the morning and I haven't figured a way to get it to clean my house. But it can clean features' house. So it can be quite useful for us. Features focuses exclusively on code where Drupal would have normally focused on the database. And this can sometimes be a point of confusion with the language that Drash uses at the command line to deal with features. But if we think about features, is thinking about the code point of view, Drupal is focusing on the database point of view. This next diagram can be a little bit more useful. I pulled this from Drupal.org node 582680. So some of you may have already seen this if you've read the features documentation. And it basically goes through the different states that a feature can be in, whether it's matching up with the database state or not. The arrows down toward the bottom, we've got the concept of a revert or a recreate included in there. But the most important part, I think, is to get that sense of there's a disconnect between the two. So if we're going to be working with features in Drash from the command line, this is our sort of quick survival guide. We want to export a feature. We're going to do a Drash feature update. We're going to revert a feature, bring it back in from code, FR. Really revert your features. The force, yes. And then clearing all caches. And these ones end up being the core of how we're going to get those features in and out of the Drupal database. Now, all of that I'm betting based on the number of hands that we've had up so far has been really trivial and perhaps underwhelming compared to what you were hoping for. And the speed of this I'm actually quite delighted at how much everyone already knows because I'm going to make you do group work at the end of it. It's going to be horrible, but you're going to learn a lot. So the next piece is on avoiding conflict. And conflict is, it's especially interesting in the Drupal or sorry, in the get sense of the word because when it comes to features and conflict, we don't necessarily actually want to merge features together. So anytime that you are actually in a conflict situation, you need to stop and very carefully think about why this feature has changed itself in the same place from two different instances. Wherever you can, avoid overlap in your features. And I've got a bit of a checklist later on on how to think about structuring your features. But we want to avoid trying to merge them together. So we never really want to be dealing with get conflicts when we're working with features. Just as a quick reminder, when we are working with these different branches, we're essentially going to be simulating different environments. And on the far left hand side, each of the features that we create will initially create in its own branch, push it up to the code hosting system before having the review and then having someone else merge it in. This is where it's going to get really, really wall of texty. So please do brace yourself. The wall of text is coming and I know that that's not the right metaphor. So here we go. The first, and these screens are all batched in terms of groups of functions that you will probably do all together. And there's, I think, seven of them. So the first thing that we want to do when we're going to be taking things from a feature, putting them into the code base, is we want to get, get ready to actually receive that export from the database. So the first thing we're going to do is we want to start in the right environment. So let's say, for example, that this is going to be a new feature. It's not a hot fix. It's not a fix off of staging or the production environment. We're going to start out in the development environment. And sorry to do this again, folks at the back, can you, can you, can everyone read these slides? Okay, these ones are right. Thanks. So if you start out in the right environment, that's sort of the starting out in development, starting out in staging or starting out in production. Check out that branch. From that branch, you then want to create a new feature branch. Pardon the overlap here of get flow terms. And the way that I structure things is to say whatever the ticket number is, plus some kind of descriptive terminology, and I go back and forth on whether or not I use underscores or dashes, you are welcome to judge me harshly as I flip back and forth between the two in my slides and change the branch name by mistake. So we're going to check out the new branch. So at this point, nothing should be different in the code versus in the database. We've not made our feature yet. The next thing we're going to do is go ahead and create that feature. But the first thing we want to do is make sure that we actually have a clean instance of the database that we're going to be working from. So this is the conversation, part of the conversation that I had with Mike was why, why is it not making everyone happy? What is it that people are running into? And I've always been pretty careful about downloading database snapshots as opposed to letting my own development database get out of control. I tend to download whatever the latest database is. It's not very efficient of me. This is far, far more efficient, but can feel incredibly time consuming. So the first thing we're going to do is set everything back to their factory reset, essentially reset the system. What's in code should match what's in the database. So we really, really revert all of our features. Now we go ahead and build the new feature in terms of the pointy clicky. I've given you sort of the site builder version here. I haven't done the Josh Fee. And I've said just go ahead and export your features settings with the pointy clicky. Go ahead and download that tarball, put it into and your directory structure may vary slightly. I've said sites all modules features. You may not have a sub directory called features that you're putting them into. Then go ahead and unpack that tarball. So now you've got the feature created and it's in a fresh branch. Remember we did that on the previous screen. Slight variation, if you were updating a feature as opposed to creating the feature for the first time, you still want to really, really reset everything. You still want to go ahead and build the feature with the pointy clicky tool and then go ahead and update the feature with features update all or f you all. Oh, I missed one. My apologies. Some of these transitions aren't quite right. So you briefly missed a Princess Bride gift there. I did try to reward you for reading walls of text. The next one's pretty good though. Let's hope that it actually works. So now we've got in our new branch ingit, which is related to the production or the environment that we want to put it into. All of that stuff is set up. Now what we want to do is we want to verify that our feature has actually been correctly exported. So what we want to do is say compare me to what was previously in stored ingit. Now, if it's a new feature, there's going to be nothing. So when we run the command get diff, every line will have a plus beside it. Every line will be new. If it's an updated feature, then what you're going to look for is a pairing of a minus and plus when you run get diff. And basically run through this little checklist. Just note to self. Is there anything within this list where the values are all the same, but they're showing up in a different order? Panelizer had a nasty reputation several versions ago for having the same elements in an array of settings, but they be slightly in a different order, and it wouldn't necessarily result in clean imports in different environments. Our strings not quoted. So if you have zero versus zero with and without the quotes, get will interpret those as being completely different lines. Are there any extra pieces? Did you accidentally export more than you meant to? Are there any pieces missing? Do you have all of the elements that you meant to export? So reading through with a get diff, and there's no extra parameters required, it will compare to what was previously stored in get. Assuming that everything is looking well, you are now ready to actually proceed to saving your feature into get. So we're going to do a quick check, get status. We're going to make sure that the only files that get wants to commit at this point are actually related to the feature. So we just did a fresh check out. There's no extra editing. You've not been tinkering. It's all save. Run get status to make sure that only the new things that we'd be going in are related to your feature. Go ahead and run add get add, and then the name of the feature directory or simply a period, much shorter. And then go ahead and save the new feature to your repository with get commit. At this point, I've not given you the shorthand for how to add a one line commit message because I want you writing a really fantastic message on what this feature is about. And I want you to explain in words all of the elements which should be included in here, so that when someone else is reviewing it, they can make sure that they easily can refer back to is there a new content type? What are the new elements that they should be able to see when this feature is installed? So fantastic get commit message. And you're now basically locked and loaded and ready to share that feature. It's not actually a trap. You won't, you know, there's no negative things that are going to happen at this point. We don't have a, what was he doing at this point? Something about Gilder, I think? I can't remember. In any case. So now, now you're ready to go ahead and share that feature. So at this point, as far as get is concerned, the user need to do is go ahead and push that branch up to the server by running get push origin and the name of the branch. And now your feature should be available in the code hosting system for other people to download and review. Oh, we missed the bow. I got these transitions wrong. My apologies. So now that we've got that information available, the next thing that we want to do is actually test that feature before going ahead and putting it into the main line. Because we're in a separate feature branch at this point. So before we merge it into dev, we're going to go ahead and as the reviewer, update our local list of branches with get fetch. That will tell us that the new branch one, two, three, four new feature is now available. We're going to clean up our database before we actually check out the branch. So again, make sure you're going through this constant process of resetting everything. Yes, it takes time, but it takes more time if you've got extra settings in your database that are going to be conflicting accidentally. So reset, really, really reset. And then go ahead and check out the new branch with the tracking origins that you can push it back up if you want to make changes to it. Going to then go ahead and import. The new feature should be that easy. And then you check it out. You've taken a double look at things. Everything looks fine. And you can go ahead now and pull it into the main development branch. This is done by first doing your get checkout. So go into the branch where you actually want to receive the new feature. Ensure your copy of the branch is up to date. We can have the pull versus, or sorry, the rebase versus merge debate later on. But this will give you a one liner that if your team is using rebase, this will work. And then we're going to go ahead and include the new feature into the current branch by using get merge with a no fast forward flag, which will force a merge commit, which we can easily undo. This becomes relevant. And then, of course, the name of the branch that we're going to be pulling in. However, you may have conflicts that you need to deal with when you do that merge. So I'm going to take a step back just for half a second and remind people what a conflict is in get. Because it can seem really, really stressful when you're doing bits of these pieces. And maybe you're doing a rebase. You run into a conflict and all of a sudden you're in a detached head state. And detached heads sound really for king scary. So just to quickly remind folks, conflict is when there is overlap at exactly the same line. It's the Venn diagram. And broken, you know, is sort of the middle of that Venn diagram. So if you're going to do a successful merge, you can have anything coming from ours and anything coming from theirs or anything coming from my current branch and anything coming from the branch which is being merged in as long as there's no problem. As long as they are on separate lines, get can figure out how to merge those two pieces together. Killing with conflict is a little bit painful. I can appreciate this. And anyone who says differently is selling you something. I, however, am not selling you anything today. But we are going to investigate conflict. So we need to figure out where the point of conflict is. If when we do this, we do this together. We need to figure out where the point of conflict is. If when we do this merge, if there is conflict, we need to figure out where it's coming from. The first thing you can do is go ahead and run the get merge tool. If you have nothing additional set up, maybe you've got a GUI that you're using, maybe you've got some more interesting software to sort of examine things. You'll have a tool which comes up which will give you a side-by-side comparison of the two different branches and shows you the piece that's broken in the middle and allows you, again, depending on the software that you're using to click and accept which side you want to keep. I like kaleidoscope. But again, remember how I said we don't necessarily want, when we're working with features, to merge them in. We want it to more than likely be a clean import. So if you do end up with a merge conflict, definitely go and investigate it first in terms of that merge tool. But more than likely, what you probably want to do is back up and not have that merge in place right away. You probably want to have a conversation with your coworkers, your teammates, figure out what it is about that particular feature which is causing the conflict to begin with. So we can undo the merge so long as we haven't published it yet by running Git, Reset, Merge, and then Original Head and OrigHead. OrigHead is a special pointer that in GitSpeak basically means something really important happened at this particular commit that I think is dangerous. So it will allow you to go back to that last dangerous action and Git perceives merge to be a dangerous action. So once we've sort of unset that and kind of cleaned up a little bit, we can now go back and take more of a look at what the difference is between those two. So when we first exported the feature, we ran GitDiff simply on its own. This time we're going to use it to explicitly compare two different branches. And I've used here GitDiff, my current feature branch that I want to examine, three periods, and then master or dev or whatever the branch is that you want to compare it against. Excuse me, the three periods will then show you only what's different in one or the other if you want to show the history of both, knock that down to two periods. And figure out what's happened. Now if you decide that you don't really want to deal with the conflict per se and you know that your version is right and you've decided that it's okay to save your version, what you can do is when you do that merge use the minus s flag, which is a strategy, and you can explicitly say, I know that mine is right or I know that theirs is right. And what it does is it separates that Venn diagram off, pulls off the other side and keeps only one or the other. So in this case, you can see down at the bottom here, Git merge dash s for strategy, I can choose either ours or theirs. That's going to do it across the entire merge branch though. So if you want to be a little bit more granular and sort of pick and choose which things you want to keep, you'll want to use the merge tool as part of the merge process instead. That's most of what I had. I know that we do have an hour together. So I'm very, very happy to take questions. I'm also happy to help facilitate conversations with folks who got more in depth. This is one of those really tricky topics here. I have taught it as a one day workshop, and now you've had sort of my very high level overview version of it. It's really tricky to give an in between that has a little bit more, but not too much more. So a couple of different resources there, and then even more resources, a couple of full disclosure, I don't work for them anymore, but Drupalize Me does have a couple of really great video series if you prefer video learning on using more Dresch with features. So those are some great resources. And then there's a mic there if we want to record the questions, but I'm also just as happy to turn off the mic and sort of divide people up into the kinds of problems that they're having at this point. So thank you. Yeah. Oh gosh, my favorite scene in The Princess Bride. I can't say all the scenes. I really, I kind of like the peanut one. There's no more rhyming, and I mean it. Anybody want a peanut? Yeah. Yeah. I mean, it's just a fantastic movie start to finish. So yeah, tricky question. Any other, you know, like deep meaningful questions that, yeah. Oh, if you just go to the session description, they're already uploaded on the session. You may need to refresh it, but I did upload before I started. They should already be their questions. Everyone's being a real trooper. You absolutely do not need to stay, but I am happy to stay for as long as people have questions because I know that this is a tricky, tricky piece and can be super, super frustrating if you struggled with it. I know that I certainly have struggled with it myself, but this is sort of like once you see it all written down. It's really, really easy, but it doesn't feel really, really easy when you're in the middle of it. Mm-hmm. Yep. So in terms of the two people working on the same feature at the same time, the disadvantage there is that you are more likely to end up with merge conflicts. It becomes more likely that you'll have slightly different settings and just generally you are more likely to run into problems if you don't have cleaned, like you have to just be really, really careful about cleaning everything up. If it's not going to work for you, if you need to work on the same feature at the same time, unfortunately just brace yourself and be ready for more, for more difficulties. But if you can, you know, maybe there's ways to sort of separate out that feature and sort of abstract it down and say, you know, is there, should this be related to the content part of it? Should this be related to the view part of it? You know, is there a way that you can separate it out based on the different roles that people are performing? Question. Fantastic question. The strategy that I have found most effective is empathy, followed by really great documentation. In a lot of cases I've found that people use the quote-unquote wrong strategy because it, for whatever reason, feels more natural to them. It doesn't feel as scary. They're less intimidated by whatever it is. Or in a lot of cases, like these, when you see these commands written out, they're not that bad. But when you try and remember them all, when you're not, when they're not documented, if you're only doing that export, if you're only doing this stuff every so often, it becomes really difficult to remember. And if you're not comfortable and get, and you don't really know what you're doing, and all of a sudden you're in a detached head state because someone told you to rebase, that's really, really freaking scary. So working with people, maybe it's pair programming, maybe it's writing documentation, maybe it's just, you know, if you happen to work remotely, can you sit on a hangout with them and go through the process with them? Again, documentation, that's why I love the command line in terms of those copy-paste commands, you know. This cluster has to do with updating a feature. This cluster has to do with whatever it happens to be. Can you draw the diagrams? And if you can overcome, if it is a fear problem, if you can overcome the fear problem, then you're golden. If it's folks who are just opinionated, then ask them why they hold that opinion. So the tech lead who I worked with a couple of years ago, we had this, I personally actually don't care if you rebase or if you merge to pull things together. It does not matter to me one little bit and there's no rebasing police out there who are going to show up at your door exactly that noise and like complain. But your teammates may complain. So why are they complaining? And that was something that Joe and I had this really fantastic conversation about, saying like, it doesn't matter. Like why do you like rebasing so much? What's the big deal about this? And so we went through the different reasons and for him it made bisect easier to use and it made it easier for him to read the history when something went wrong. So as the lead dev, as the senior dev on the team, I could inflict a little bit of pain on myself and deal with the slight overhead of rebasing so that it meant in times of crisis he was able to better unpick the history. But we had to have that conversation and when it was just, I mean we had sort of passive aggressive documentation editing where whoever had most recently touched the wiki, that was the documentation that got followed and so we had this sort of, it was getting good humor mostly back and forth over which method to choose until we finally had that conversation. So good luck. I hear whiskey helps. Yes. Great question. So as a one person developer, what are the benefits to using Git? I don't know about you, but I personally have a really hard time remembering what I did for lunch let alone what I did two weeks ago. So my saving grace in Git is it allows me to track my thought process in ways that aren't necessarily recorded in tickets or in other documentation and it's tied directly to the code. So if you find that the types of tasks that you're working on are documented really really thoroughly outside of Git you may find that also documenting it within Git is not helping you and that you're not really getting a lot of advantages and it's steep learning curve and it's frustrating and you're not really winning a lot to begin with. That said, sometimes I make mistakes. It's nice to be able to go back and look at what changed here and what changed there and certainly the more that I was able to diagram out the process and the more that I was able to push myself to learn this tool that really frustrated me in Prague, I gave a talk called Git Makes Me Angry Inside and it still makes me angry inside but I found that the more that I've been able to control how the tool helps me the more that I've been able to enjoy the development process using Git but yeah, it can be really hard to be motivated to use it when you're a team of one. I agree, yep. Oh, can you run to the microphone for that because I won't be able to repeat all of them by that. Awesome, yep. Other questions? I do hope that everyone feels that they've gotten value from this session even though it was relatively short but there's been some fantastic questions. As I said, I'm very happy to continue answering them but I'm starting to get the blank stare of I'm just too brain fried to get up and leave. So I encourage you at this point I'm going to stop talking. Definitely let me know if you've got more questions and like I said those slides are online and congratulations for making it to the end of day one at DrupalCon.