 Hi. My name is Matt Crooks. This is the talk you're about to see. I hope it's the one you thought you were going to see. And I'll anticipate my most common question. Yes, the slides are online. There's a link right here from the session description. Alright? So, I've got lots of materials, so I'll go a bit fast. I'm expecting that you'll be able to come back and look at the slides yourself later. If there's anything that I skipped over too fast. So, we're going to be talking about the intersection of Drupal and Git and Agile. Three popular buzzwords. Let's see how to put them together. So then you can fork, merge and commit with confidence. This is me. My name is Matt Crooks. I work with Evolving Web. I've been using, as I usually say, I've been using Drupal since Pluto was a planet. My username is MBC on Drupal.org, Slack, etc. My Twitter handle is just MBC and then that number again. It's like Roman numerals and whatever. It's there and it's like, if you forget it. Yeah, I work with Evolving Web. Really quickly, some background. There are a couple of our clients. One thing missing from the slide, we just finished a large project for Princeton University Press that took most of my summer. Yeah, we're a small Drupal agency based in Montreal, full service Drupal shop. Git, who here knows what, who here has used Git in fields to least familiar, comfortable with Git basics? I think that's basically everyone. Jigar, I know you have. My colleague here, I get to make fun of him. This is not Git 101 talk. You all put up your hands, so I guess you don't need that. If you or someone you know does want to Git tutorial, there's a great one linked right here. Who here used, for at least the first year, they used Git, kept a text file or a sticky note or something with a list of five demands and just kept referring to it? Yeah? Who here still has that list? Yeah, exactly. Everyone does that, which is as the XKCD cartoon pointed out. I still have a list, so what I'm going to show you now is some highlights from my own personal list. Git is confusing. I'm also not going to talk about the details of the Git data structure under the hood. I know just a little bit about that, and it's not wrong. Agile, who here knows what Agile is, feels like they have the basic idea, the basic concepts? Okay, that's almost everyone. Great. So I'm not going to spend a lot of time talking about this either. But yeah, it's a way to, for a couple hands it didn't go up, so for those people, it's a way to take a clearly defined list of user stories, which is like, as the content editor, I want to be able to log in in order to be able to update the front page. So it's a way of listing the specifications for your site in a readable fashion, a way to break them down and make sense. Take a site of these user stories and turn those into tickets and an issue tracker. You have a sprint, usually two weeks long, in which you work on a bunch of those. At the end of that, you do a demonstration to the product owner who will show it to the client who will say, yeah, that looks great, or no, you still need to do some more work on this other one. There's a scrum master, which is a fancy way of saying project manager, who will pick which tickets to work on in the next two weeks sprint. They will have been put in order and waited by how hard they are in the collaboration, but in discussion with the client and the team respectively. And so you have this endless list of tasks that you want to work on. That's your backlog, and you'll get as far as you can through that before you launch the site. I'm not going to talk more than that about Agile. There's a lot of resources online about that too. What we are going to talk about is how to use them together. So in your issue tracker, I've used, so issue trackers I've used, usually been Redmine or JIRA, anyone else use something different? No, everyone's using one of those two systems. So your tickets always have a number. Allow me to strongly suggest you create a separate Git branch, which has that number in it, so that you know what Git branch actually is associated with what user story in your issue tracker. You have to create a separate Git branch for each of those. Those changes should be self-contained and should update the database as needed when they're deployed. You need to document how to deploy them in your issue tracking system. You should include whatever code is necessary to update the database or the configuration. So to step back a bit, your Drupal sites always consist of three things. You've got your code base, you've got your database, and you've got user uploaded files. So when you're adding functionality to the site, that will usually affect the code base and sometimes the database. So one way to do this is to remember, oh yeah, after I deploy this, I've got to go click these five things on my website. And then somebody's going to forget something eventually, so that doesn't work. So the next way to do it is to write down those five things you've got to go click after deployment. That also leads to things getting dropped. So you should use, yeah, another question. Who here is working in Drupal 7? And who here is working in Drupal 8? Okay. Yeah, so in Drupal 7, this is a little more complex. I would strongly suggest that you use update hooks, so hook, update, end. These are what, in a custom module somewhere. These are what modules use to update the database schema or other things in the database layer. When you run update.php or drush.optb, those are the functions that get run. So if you need to add a new block or do some other database level changes, put that into code. Then you have a deployment process which is committed to get and which can be tested. Which can be tested using continuous integration and an automated test if that's your process. But you've got something better than a sticky note saying, oh yeah, when I deploy ticket 15, I've got to go click these five things. That'll never work. In Drupal 8, this is much simpler thanks to the configuration management system. Anyone here using Drupal 8 already knows this, so this is for the rest of you. But configuration in Drupal 8 is saved to a series of YAML files. Simple, very human readable text files. There's a simple command to export and import those because the live state is in the database and then there's a version in code that you can commit to get. So all you need to do is export that from your dev instance. And then import that in your production server when you're ready to deploy that. And those steps for testing your ticket and for deploying your ticket. Including URLs, sometimes screenshots, a description of the expected result. Like before the live site is doing this, after this thing is deployed on your test instance, you should see that it's doing this. All of that needs to be clearly documented in your ticket tracker. Like add extra fields. You can do that in Jira or in Redline. So when is all of this useful? I'm assuming that you're using something resembling an agile workflow that you have series of sprints and regular deployments. I'm assuming that this isn't just one person working on a website. You've got a team, a bunch of people who need to work together. With some sort of project manager who will go and review the work of your colleagues and decide whether they're approved and make sure things don't clash with each other. I'm assuming that you will do regular releases. So not just one big product launch, but at some point you're going to roll out changes to a site that's already live. So that means continuous integration and user acceptance testing. Does anyone here ever work with a change approval board? Sort of a large institution thing? Yeah. I'm not going to ask you if you'd like it because I already know the answer. They're very painful, but it's something a large enterprise does to ensure that people from a variety of departments have reviewed the changes that are coming up in a new deployment and make sure it doesn't that's not even a word. It doesn't affect anything in their department, like the person who manages the single sign-on thing or whatever. I'm assuming that you will occasionally need to do a hot fix for an urgent problem directly on the live site without waiting for your two-week sprint cycle because hot fixes, urgent crises, they happen. And also a tricky one you get, I'm assuming that once in a while you'll have a sprint in which you close, say, 10 tickets and when doing user acceptance testing you'll discover that one of them isn't quite ready to be deployed and so you'll need to remove that from the set of tickets that are about to be deployed and then keep working on it outside another branch. Specific techniques for doing these I'm going to get to in later slides. So now let's talk about TruePull best practices. So I already mentioned you've got codebase, the database and user-contributed files. If I'm going to test the changes that my colleague has worked on on the copy of the site, getting the codebase is easy. I just type getPull, like whatever branch they're working on. I'm going to need to copy the database. I'm assuming everyone here is working on a site that has like a nightly backup of some sort and that you have a way to sync those backups down to your development environment. If you're working with massive databases then this is tricky but let's just assume it's some reasonable size that you can put on your laptop. So that leaves the user-contributed files. So everything in site's default files. What should you do with those? Allow me to strongly recommend the Stagefile proxy module. This is in very good shape for TruePull 7 and TruePull 8. So all you do is you configure it. There's one important piece of configuration, which is the URL of your production site. So you give it that URL and then any time you go to load an image on your dev site, in your dev site you have zero files when you start, when you spin up a new dev site. When you go to load a page, if there's five images, whenever, it basically catches these attempts to load an image that is 404s and then goes and fetches transparently the image from the production site copies it down into your development site because the image is on a public website already, by definition, and just loads the ones you need. So if you've got, I guess, this site I'm working on from Princeton University Press, there's like 17 gigs of images but to test this specific function I probably only need four of those images. So rather than syncing all those files down, this will just go load those four that I need. The module is intelligent enough to understand image styles. So it will figure out what the original image is, fetch that and apply the image style rules locally because those might be different than production. You might need to load the page twice to get them if there's an image style bit. It'll show up and this is just that, so that's good enough. The stage file proxy module, you can leave it enabled on prod because it's smart enough to know. If you set the URL of the production site and it's smart enough to see that that's the same as the URL of the instance of the site that you're currently using when you're on prod and it just does nothing. It just exits out instead of trying to handle any images. You can also set that to null. And so it does a no-up on prod and so you just leave it in place and run it on the dev-in stage. The database, I've seen different processes for handling these, fetching these from your nightly backups but Drush gives you an SQL sync command in which you can use site aliases to go and fetch the database. It is a handy flag called dash dash sanitize. Sanitize will wipe user passwords and user email addresses from the user table. This is very useful to help make sure that you're not, for example, spamming your users with test messages from your dev instance. If you've ever done that and somebody yelled at you about that you probably learned your lesson. If you haven't yet learned that the hard way I'll just tell you right now that's not a good thing to do. There are other ways to do that, to capture outgoing mail from your dev instance. For example, there's a really nice little utility called mail log. It just shows you a little web app where you get to see if it catches all the mail coming out of your dev site and just shows it to you in a little web app so you can go and scroll through it and no mail leads to the actual users. One way or another you have to make sure you're not emailing your users. And then as I've been mentioning earlier if deploying a change requires any touching database in any way then you need to write update hooks in Drupal 7 or in Drupal 8 or export those changes to configuration management in Drupal 8. Then you can systematically test this deployment process and you don't need to list manual deployment steps in a ticket. In Drupal 7 specific practices you should export any configuration you can into a feature. I would suggest grouping these into having one feature module that contains all the configuration, content types, views, variables, for example, for the blog on your site into one module. Then the command drush features update all will export from database to code. Revert all will take everything from code into the database so that's what you'll run on production when you deploy it. You need to use the features web UI to create new features. Here is the handy little shell alias I have which will just list all of the features. Run this and you'll see a list of all the features on your site which are different between the database and code. It will list the names and then it will create features called feature name which has the differences for each of those so you can go and inspect them. This should, on your production server this should always return nothing. If you spin up a local copy of the production server without any changes it should also return nothing. You could add this to something like this to an automated test somewhere if you wanted to be careful to put it. Drupal 8, I already mentioned, the equivalent to those feature import export commands are drushconfigexport drushconfig import. I don't personally use GUIs to deal with Git but when you do you sometimes see diagrams like this. Does this look familiar to anyone? Yeah, I see a few nods. Now, those are just the best practices so prerequisites for getting into these Git branching strategies that I'm going to talk about. I'm going to present three in order from simplest to most complex so that they'll build on the previous steps. The one you choose depends on the size of your project and your team, how many steps there are in your Q8 process. My main source for this is a Gainer tutorial from Atlassian. The URL is right here if you want to read more with us later. So first, centralized workflow. This is the first workflow that you'd start using if you've never seen Git before. There are no branches, there's no merging, there's no conflicts. There's just one developer working on the site or on each component of the site. So every time you do a change, you just get add and get commit and all work is done on one master branch. It's a very simple method, but it doesn't scale. Feature branches. Feature branches are what you often see on GitHub. So here you have multiple people working on the code base. One person responsible for testing and improving those changes, also called pull requests, or at least one person responsible for each section. For example, Drupal itself has a maintainer's file which lists who's responsible for the different components of Drupal Core, and that's the person who will decide if a patch is accepted. The Linux kernel works the same way. I can't remember the name of the shell script, but there's a file that has a list of... There's actually regular expressions that says this path in the core is the responsibility of this person. So you want to work on one file and you run this script and look at those regexes and say send your patch to this person. It's a very long file. Drupal is a little simpler that way. So this is a perfectly workable method. So every new feature is a new branch. So you create a new branch which is merged off of the master branch. When you think it's ready, you send a pull request. While you're working on a dev branch, there are other things that have been fixed. So you need to keep merging master back into your dev branch so that you keep up to date with all those changes. So you can do a fast forward-only merge as it's called in Git. And then the maintainer will look at those changes and they will merge that feature into master. Then every once in a while that maintainer, that centralized position will tag and commit and say, okay, now this is version 8 or now this is version 9 or whatever. And GitHub and GitLab have nice UIs where you actually see a button saying this is ready to be committed because it's up to date with the latest version of master or it's not. It's a nice UI. Here's a little squiggly diagram to explain feature branches. So in the top one you see there's a master branch and two feature branches have come off of it. In the bottom one you see another master branch. So somebody has made a development branch and a pull request happened and it got merged back into the master branch. So in the bottom one, the furthest to the right contains all the commits on the dev branch which is the one underneath as well as the one on the main line, that white one. So in this case there were no, there are no merge conflicts. They didn't need to merge master back in. Does that make sense so far? Yeah. Who here is using something that resembles this to manage Git branches? Okay, about half of you. Okay. Great. Here's the main problem with that. Let's say five different people are adding features. Each of them work individually but nobody ever tested them all together. And then you get, then you find out why integration tests are useful. Each of these drawers opens but you can't, but once you put them both there they become pretty useless. There's one more description example of why an integration test is useful. So here we have a paper towel dispenser and a garbage can. Oops, no. Alright. Want to make this? Yeah. There you go. So two features which work by themselves but don't work together. So here's the way you can solve that. This is the Gitflow workflow. So this is, this builds on a feature branching model. It's essentially a naming convention. So there's no, there is actually like a Git extension. You can download that like tries to simplify this, but it's just a naming convention for different branches. So you have branches with specific names and a specific process for when you merge what into what. It's just basic Git commands. This works, and I found this works very well for a team with multiple developers using an agile process as I described very rapidly earlier in the talk. And this allows you to have an integration test and a review of all the features in a branch before you do a release. It allows you to remove a feature from that release if it's not ready. And there's still a way to do the hotfix directly on prod. If some crisis comes up and your boss is really unhappy about it. Okay. Next bigly diagram. I'm going to spend a bit more time on this one. So these are color coded. For the sake of other color blind people like myself I'll describe them. The top one here is your master branch and you see these things here are your tags telling you what version we're looking at. So here, this dot right here is a hotfix. So that hotfix, that's a branch that was created directly off of the master branch. Some minor little fixes made and then it was merged back here into version 0.2 and that's the hotfix being deployed. So right there that looks like the feature branch model that we discussed earlier. The git flow model however has more branches. So down here, this long one here is the develop branch. I would often just call that dev. So this was initially forked off the master branch and this doesn't go away. This branch, like the hotfix branch once it's merged into master you can delete that branch. Git has a command, when you list, the command to list git branches has a flag dash dash merged where you can see just the branches that are already merged into the current branch. That tells you the branches that you can delete because they're no longer necessary because all of their commits are included on the branch you're currently on. So as soon as you've merged one of these branches in then I would immediately delete it so you've got less clutter. But the develop branch or the dev branch you leave, that stays there. So what you do is, so for example here at the very bottom a dev branch has been created from the... a feature branch has been created from the dev branch so here in this case somebody has been working on it and they've made four commits. Here is another feature branch, this one down here. So it was forked off of the develop branch and then it's been merged back in here to the develop branch. The hotfix branch here, in addition to being merged into master had to get merged into the develop branch. So that change, that urgent fix is in both places. So once you've merged from hotfix into dev then if you merge dev back into your feature branch you're going to have that hotfix commit on your branch as well. And your feature branch should always be up-to-date with the latest version of the dev branch which in turn will always be up-to-date will include all the commits from the latest version of the master branch. The interesting thing, the integration test part that I promised is here, so this is a release branch so you could call this like release slash 10 if it's your 10th sprint for example. So that was forked off of the dev branch and will be merged into the master branch. But here is where you take a bunch of tickets everything you close from your sprint and you spin up an instance of the site that contains all of these tickets and that's where you do user acceptance testing. Your product donor, your client, I'm guessing don't want to go look at 10 different sites and test 10 different features. And besides if they did that that doesn't count as an integration test. So every two weeks you give them one site and you make sure that all of the 10 things you fixed work on that release branch and when that's been accepted then you merge that into master and that's when you get version 1.0 here. And then here you see there's two commits on this release branch so some little fix had to happen just on that right before deployment. So it was merged back into the develop branch so that way you make sure the develop branch always has all the commits from the master branch so it's further ahead. I'm going to show you the specific git commands so you could run to do each of those steps in a minute so I'm getting there. But this is on a general conceptual level I just showed you a whole lot of little dots on a big squiggly diagram does that generally make sense, the concept? Because if not I'll take more time now. Yeah? Question? I'm just wondering, you said earlier normally you delete the branch for the hotfix, right? So how about the one for the release? Are you only keeping two branches basically the master and the develop one? Yeah, so the question was I said to delete the hotfix branch so would I also delete the release branch here? And the answer is yes. Also all of the feature branches as soon as they're merged in I would delete them. So as I mentioned you can type git branch dash dash merged so if you check out the dev branch and then run git branch dash dash merge you'll get a list of all the branches that had been merged in all of the commits are included so you can get rid of them you can delete those branches locally and on your upstream git server and then you can do the same thing for master it's not useful to keep them around if you need to reopen that ticket just work that branch off again. So now some git best practices I already mentioned I strongly suggest keeping the ticket number in the commit message as well as in the branch name so for example in red mine we use git osus to integrate red mine and git so if you type refs number sign 1 2 3 then when you're looking at ticket 1 2 3 you'll see a list of links to all of the commits that were made against that ticket so it helps you figure out later which like when you're looking at issue tracker you can immediately see a list like a list of all the commits that are related to that ticket and you click on them and you see the diff so that helps a lot and when you're looking at the git log you can search through it to find all of the tickets that were related to a specific the commits that were related to a specific ticket I mentioned that when you are merging the merging a hotfix or a release branch into master or dev you need to if you have a if this is a fast forward only merge git will not normally create a new commit because it's not necessary but I would strongly suggest that you do that using the no fast forward option you can configure that you can do that on command line you can configure that in your .git config file so that way you'll see an extra commit just for the action of taking that dev branch sorry taking that release branch and putting it into the master branch and why you do that the advantage of that I'll get to in a minute so yeah anytime you merge a hotfix a release or a feature branch into master or the develop branch I suggest you create a commit a merge commit just for that I would also strongly suggest you use git prompt.sh that's a shell script which is distributed with the source code of git itself so you can find it very easily on github or anywhere else that's you do little things like at minimum print the name of the branch that you're on right in your bash prompt this is the lifesaver you can also have it print fancier things like whether they're uncommitted changes and other stuff that'll start to slow things down a bit but at minimum you always want to know what git you should always know what git branch you're on so put it right in your prompt naming conventions yeah so I mentioned these briefly already so master that's where production runs so production always is the latest version of this branch dev that's the one that the other one that I said doesn't go away that's the one where you collect all of the feature branches dev 123 or feature 123 is the branch corresponding to ticket number 123 those are branched off of dev and will be merged back into dev release slash number is a snapshot of the dev branch at a specific time with all the tickets that have been completed that is merged off of dev and will be merged into master and deleted once it's done hotfix ticket number is merged off of master and will be merged back into master when it's complete and again all those ones of the numbers and all of them I delete as soon as they one of the two branches that stick around now I'm going to show you my two favourites all time get commands I run these dozens of times every day so the first one this updates all local copies from all your get remotes to showing you a list of all of the branches and all of these different origins so it doesn't do a get pull it just brings in copies of the commits to locally so that you can look at them later and figure out what the differences are so that's it so get fetch will download the changes but not apply them the dash dash all will do it across all remotes and the dash dash prune will delete will delete the local copy of a remote branch which has been deleted from your origin because you don't need them anymore command number two this will list all of the local and the remote branches it will show you the current hash point it will show you for each local branch which remote branch it's tracking because your local branch should always be tracking something upstream it will show you the commit subject line so get branch dash all dash vv and as I mentioned dash dash merged or dash dash no merged will help you figure out which branches have been merged in and which ones still need to be merged in and that should correspond to whether or not the ticket in your issue tracker is closed or not here's a sample output of favorite command number one so here I'm fetching from origin I deleted my local copy of one of the branches because it was removed counting objects compressing objects here it's downloading the files and it's showing me what's changed favorite command number two here you can see so the so I'm running get branch dash dash all dash vv there's one line that's asterisk beside it that's the current branch although I already knew that because it's in my bash prompt it's listing it's listing for other local branches which remote they're tracking and whether they're ahead or behind or both then after that it's listing all of the branches on origin so that I can see what state they're in there or if there's a new branch that I don't have a copy of for example now here's the part this is how we go from the squiggly diagram to something you tap on the command line here's how you would create a new feature this you would do in the feature branching model too so on your local machine you would check out the dev branch and then you would create a new well yeah I guess you do get pull here in between these first two steps and then you'd create a new branch that's forked off of dev called dev slash 123 then as you're working on it once you would periodically do get merge dev to bring in changes from other people or from other tickets into your branch to make sure it stays up to date and then when you're ready you push it to origin for review that's simple enough then if you're the Scrum Master and you're viewing one of these you would fetch the branch from origin you would type get merge dev to make sure that it's up to date and then I do get diff dev to see all of the changes between this feature branch and dev so now it's showing me everything that the developer on my team changed when I think it's ready then I would check out dev again and I would merge that into dev then after that I would delete the local and remote copies of this branch because they're no longer necessary again these slides are online I'll give you the URL another time so pictures are great no no please take pictures that's very flattering but you can look at the slides later and copy paste as well what's the dash key option dash key oh that's that that checks it out and sets that branch to that checks out a local copy which will track origin so it knows in this slide the part where the local branches are tracking something on origin in the brackets that's how it sets that up there's different commands you can use to do that this one will work you can see if you look at the dot get dash config file it'll tell you really clearly which branches are tracking something on origin and normally the local branch and the name on the origin on the remote would be the same that's like you said it could be default so you can check out the branch date if you've got that right yeah it depends I think that's the default if you only have one origin but often I'm working with multiple origins yeah you would just get check out dev.1.2.3 if you don't have a dev.1.2.3 people check out your working file yeah that's right if you do get check out dev.1.2.3 and there's only one branch with that name on an origin it will check it out with a local name and make sure you make it a tracking branch yeah okay so now we've created a feature branch we've merged it back into dev and now we need to let's say we did that for five other branches now we're ready to prepare a release branch and do integration testing so we would make a new branch forked off of dev in the usual way get branch-b it was a branch name we would push that to origin then on our staging environment which is where our user acceptance testing some point in here you'd sync the database from production you would check that out and then you'd run whatever the deployment steps are so feature, revert, all drush, updb, etc whatever you're so now we're referring back to the best practices I referred to earlier you've got some, you had somehow you had put into code a way to run those deployment steps this is where you run them and you're testing the deployment steps which you will later be running on production as well origin space so get push here I'm saying to push to the origin the local branch with this name there's origin slash that you need to refer into a remote branch when the release four is a local branch and it's simply saying origin is the place I wanted to push to yeah because there is in this line here, this line number three there is no branch called origin slash release slash zero four it exists locally and so we're creating it on origin okay so now we're ready so now we've created our release branch and it's set up on a staging server we've run our deployment steps which we're all in code and some user acceptance testing has happened and everyone thinks it's great so now we're going to deploy it on production so on production, sorry on a local machine we'll merge that release branch into master and we'll create a tag and push that with the tags and you'll notice the dash no ff, no fast forward so that created a merge commit for that action of merging the branch then on so now all of the changes from that release branch are on the master branch and all we need to do on production which always stays on the master branch is type get pull and then run the deployment steps and we've already tested these we've not only tested the code but we've tested the deployment process and those scripted deployment steps themselves so we know that they work and so we can do this in full confidence we're still not going to do it Friday afternoon because we're not crazy but we're pretty sure it's going to work okay does this make sense so far yep, okay and then something terrible goes wrong there's a catastrophe so we need to create a hotfix branch this is similar to those previous steps so here's these are the steps we'd run on our local machine so we'd make a new branch as I said earlier, branch directly off of master this is called hotfix slash ticket number we'd fix our code, we'd write our tests and these would include the deployment steps whatever they are then once it's ready we'd check out master, merge the hotfix into it push create a new tag and push that this git push will go right to master because that's the branch we're on and then we just need to deploy on production the same way we deployed the feature branch let's see now I'm going to talk briefly about resolving merge conflicts who here has had to do a really ugly merge conflict everybody, yes you've all had to do it, you're all experts I'll just mention really briefly some tips for this try to create small distinct tickets keep the scope small and then you'll avoid overlapping having two people work on the same thing at once and then you're less likely to get into a conflict merge the parent branch which is probably dev back into your feature branch frequently so that way 5 little merges are much easier to do than one huge one when you're doing a if you do get a conflict git status will list all the files with conflicts so that you can edit each of them when you're editing them you search for a whole bunch of less stens in your editor you can see the beginning of the section with problems so you can fix that manually if you're using an editor that lets you do a 3-way merge personally I use Vim for example you can configure that git merge tool dash dash tool dash help will list the editors that are known to support 3-way merges that are supported on your platform whatever your local environment is so go figure out what those are and figure out how to use one of them something very helpful I found if you ever get stuck halfway through a merge and it's just really not going well git merge dash dash abort will just like completely will back up to before you were doing the merge so for example if I'm scrum master and I'm trying to merge a few things together in one ticket I'm having a lot of problems with and I can't get it and I'm not really sure what the person was doing because it's because I didn't work on the ticket I would abort the merge and then I would say to that developer hey please merge back into your feature branch because I can't figure what you're doing I want you to do that and test it and then tell me when it's ready so that helps a lot so now the tricky part I mentioned being able to move one ticket from a release so you finish 10 features in your sprint user acceptance testing show that one of them had a problem so here's how you do that first step you revert to the merge actually this should be check out release slash x but you revert the merge that brought in the feature branch so when I mentioned earlier that you should do a non fast forward merge and create a separate commit for the merge itself right here this is why because that lets you undo that action later if you don't do that you won't have a way to do it so you would revert the merge itself it should be from your release branch so if you want to do git log and figure out which commit it is then you need to so then you have a release branch that doesn't have the problematic feature branch so now you've got just nine tickets and they've all worked so you've got something ready to deploy but you still need to fix that problematic 10th ticket so now what you do is well yes I missed a couple steps here you'd merge that release branch back into dev then you'd merge dev back into your feature branch so here I'm checking out the feature branch emerging dev back into it and then what you do is revert revert the revert so you would undo the action of undoing the merge so what that takes you to is a point that takes you back to a point where the on your feature branch where you have the code again so you're back to the point right before you merged into dev so now you've got your half baked feature and you're on that branch again and you can fix it do whatever edits are necessary and then hopefully commit it in the next sprint so that's a I think that's the trickiest command I was planning to show you does that make sense at least in principle okay great that was the hardest one for me to get my head around so you're all doing great further reading so this talk started life as well I had my own personal text file listing all the tricky commands I was learning at one point I created a gist and then I started adding a bunch of notes to make that readable and that was version one of something that became the slide to this talk so I have a link to that here I mentioned earlier that Atlassian has some really good tutorials so here's they have in addition to the one which is just an introduction to Git and the one comparing Git workflows which was my main source for learning all this they have one that talks about the difference between merging and rebasing which is out of scope for this talk because we're already at 50 minutes but is another good Git tool to learn and there's a I've also put in a link to how to resolve conflicts I'll just show you this very quickly what it looks like so well I don't expect anyone to actually be able to read this but this is the long version of exactly the material I was presenting now but with more text so if you want to sit down and read this at home or share it with your colleagues you could go there yeah right before I take questions I'll just mention that my company of all the web offers a lot of training including on module development so there's some coming up next week online and a little later in September here locally in Ottawa if that's of interest to anyone so site building, theming, module development these are all Drupal 8 specific by the way and there's many more trainings offered in other cities which are listed on this URL and now I will take questions or stories of terrible Git merges you've had to deal with or anything else you want to share this link down here again these slides and the videos from this talk and all the other talks of this camp are available at this URL here so questions there are new strategies from this sort of workflow for dealing with tickets that depend on other tickets haha yeah so like ticket yeah so I mean you just have to so yeah ticket 1 can't be worked until ticket 2 is finished yeah so I mean you've got to you just have to know so you can't even work on ticket 1 until ticket 2 is done right so ticket 2 has to be done and committed to dev before you can even start working on ticket 1 and if you think it's a big user visible change then you need to do user acceptance testing and actually commit that to master and like get it approved by all the stakeholders that need to approve it and then work on the other ticket in the next sprint yeah if it's too smaller things hopefully you can do them in the same sprint and just like you just have to know in your team oh yeah let's make sure to finish this one like by Tuesday so that Sue can start this other one on Wednesday or whatever yeah I mean that's part of the job of being a Scrum Master I guess yeah oh you needed to sort of develop two things in parallel yeah yes I've done that like let's say yeah I've had to do that if one feature is mostly done but not completely done and then you want to work on some other feature which builds on it and only needs and the parts that are done are finished enough for that then yeah you could branch that off of the one feature branch off of another feature branch and then you'd have then once the first one was merged into dev like all those commits would be there so the second one you'd be able to merge back into dev directly that gets a little trickier but yeah you can do that or sometimes I mean it's I guess it's a little messy but sometimes like you've had like two developers work on one on the same branch because they're working on things that need to go together like say the front end part and the back end part or something so you might have two tickets but it's actually on one branch so there I would just say in the deployment notes to put a really big obvious note saying this is this work is being done on branch whatever if it's not the obvious one like if ticket five is being worked on on dev slash four and just like say that really clearly so that when you go to deploy you know what branch to do it on yeah it's an edge better because the way you have that workflow is when you have two tickets you just make it two branches because it's going to get many good courses like you can't have nothing everything but you can get them to right yeah I mean it's cleaner to have two separate branches when you've got two tickets you're right but the question was what do you do when you're working on the feature I'm working on requires something you're working on in the same spring so then yeah like you can merge the commits from one branch into one feature branch into yours or do something like that so I mean if you're if your team is comfortable enough with get then you're organized enough to do that but I mean that's the exception you shouldn't have to do that too often if you do maybe you should have split something into smaller tickets it's a perfect point to raise branching off the feature branch kind of branch you're working on I did that with a recent project and I got my hands stuck I was going to make some changes so I did something kind of online that branch off to make it work so the reason I was getting what's that you know branches are cheap why you keep going off the one off the other do something like that so I guess it's not a technical case for you that you're doing this or is it a general practice yeah yeah so I've done it occasionally like I'd say it in my experience with something I've done maybe like once every three or four sprints it'll come up but yeah I'd say it's usually a sign that you probably should have made smaller tickets but sometimes that's hard to do yeah or maybe have one ticket with two sub-tickets one ticket with two sub-tickets in your issue tracker like Jira and Redmine both let you say this ticket is blocking this other one or this is a sub-ticket of this other one so then you know to work on the sub-tickets before you work on the main one yeah how you organize that kind of thing in your ticket tracker you'll find something that works for your team other questions and see any more hints thank you very much