shane thomas - the 5 secrets to becoming a drupal 7 ninja - 2014

The 5 Secrets to Becoming a Drupal 7 Ninja 1

The 5 Secrets to Becoming a Drupal 7 Ninja by Shane Thomas - Codekarate.com


Contents Lets get this party started .......................................................................................................... 5

Why write an Ebook and What to Expect? .............................................................................. 5

Who is this for? ....................................................................................................................... 5

What is a Drupal Ninja? .......................................................................................................... 6

Secret 1: Code Editing What you see is not what you get ....................................................... 7

Komodo Edit Features I could not live without ........................................................................ 7

Syntax Highlighting for any language I would ever need ..................................................... 7

Nice indenting that match the Drupal development best practices ...................................... 9

Code Completion for Drupal ...............................................................................................10

Code Snippets ...................................................................................................................12

Remote File Editing ............................................................................................................13

Other nice features ............................................................................................................16

What are some other Code Editors to look into? ....................................................................16

Minimalist ...........................................................................................................................16

Code Editors ......................................................................................................................17

IDEs ..................................................................................................................................17

Any others? ........................................................................................................................18

Why You Shouldnt Dismiss this Secret .................................................................................18

Secret 2: Drush Command line Kung Fu ...............................................................................19

Getting Started By Installing Drush ........................................................................................19

Downloading Drupal with Drush.............................................................................................19

Downloading and installing New Drupal Modules ..................................................................23

Disabling a Drupal Module/Theme .........................................................................................33

Listing Drupal Modules and Themes using Drush ..................................................................34

Uninstalling a Drupal Module .................................................................................................37

Running Cron on your Drupal website ...................................................................................39

Clearing your Drupal cache ...................................................................................................41

Backing up your Drupal website ............................................................................................42

Restoring your Drupal website from a backup .......................................................................42

Updating Drupal Core and Contributed Modules/Themes ......................................................44

Countless Other Awesome Features .....................................................................................46



Secret 3: Version Control (with Git)... Never lose your code or your mind again ........................49

Choosing the Right Service to Host Your Git Repository .......................................................49

Getting Started with Git .........................................................................................................50

Git Configuration ...................................................................................................................50

Creating Your First Git Repository .........................................................................................51

Viewing Your Project Status ..................................................................................................52

Adding Files to your Repository .............................................................................................55

Committing Your Changes .....................................................................................................55

Viewing Your Commit History ................................................................................................56

Viewing What Has Changed ..................................................................................................57

Undoing Changes ..................................................................................................................62

An Introduction to Git Branches .............................................................................................67

Creating a Git Branch ............................................................................................................69

Checking out your Git Branch ................................................................................................70

Making changes on your new branch ....................................................................................71

Merging a Git Branch .............................................................................................................72

Fixing a Conflict .....................................................................................................................73

Pushing your Repository to Github ........................................................................................78

Learning about Git remotes ...................................................................................................83

Pushing your Repository to Bitbucket ....................................................................................85

Cloning an Existing Git Repository ........................................................................................88

The .gitignore file ...................................................................................................................90

Bringing It All Together With Drupal ...................................................................................91


Secret 4: Development Process and Hosting Dont you dare touch production ......................93

Why you should define your development process ................................................................93

What does a typical development process look like ...............................................................93

Define your release process ..................................................................................................95

Choosing how to host your Drupal website ............................................................................96

Pantheon ...........................................................................................................................96

Acquia Cloud ................................................................................................................... 112


Custom VPS Solutions ..................................................................................................... 144

Aegir ................................................................................................................................ 146

Shared hosting ................................................................................................................. 169

Which one is right for me? ............................................................................................... 171

Why You Shouldnt Dismiss this Secret ............................................................................... 171

Secret 5: Features Module Get your site configuration in order ........................................... 173

What is a Drupal Features Module ...................................................................................... 173

How Features fits into your development process ............................................................... 173

Getting Started with Features .............................................................................................. 176

Creating Your First Drupal Features Module........................................................................ 177

Making Changes to your Drupal Feature Module ................................................................. 188

Using Features to Migrate Changes between Drupal Websites ........................................... 194

What the Features Module is actually doing and how it works ............................................. 202

Why You Shouldnt Dismiss this Secret ............................................................................... 204

Wrap Up.................................................................................................................................. 206

The 5 Secrets to Becoming a Drupal 7 Ninja ....................................................................... 206

In Closing ............................................................................................................................ 206


Lets get this party started Hey there, I am Shane Thomas. You have probably read some of my blog posts or watched some of my Daily Dose of Drupal videos over on codekarate.com. Despite if you have or have not heard of me, I will tell you a little about myself. I was first introduced to Drupal in 2009. I immediately felt the pain of the Drupal Learning Curve. Although I could see the power in a Drupal website, I also noticed how difficult it was to get started. Over the years I have worked on hundreds of Drupal websites of all sizes, and I eventually realized that there needed to be a place where I could document the things I learned through trial and error so that others (like yourself) would not have to struggle as much as I did. I launched Code Karate in March of 2011 to try to do my part to help other Drupal developers, site builders, and designers who were getting started with Drupal and feeling the pain of the Drupal learning curve.

Why write an Ebook and What to Expect? The reason for writing an Ebook is simple. I want to get this information out, but I dont think a blog post will do it justice. I also dont think it will be taken as seriously if it just sits in a single blog post on the Code Karate website. You can expect a good dose of reading along with a lot of hands on examples. If you are already familiar with a specific secret, I still recommend browsing through it (you dont have to necessarily follow along with the examples). This way you might be able to pick up on a few tricks you were not aware of. You will also find I try to keep the writing style light and personal. I might throw in some humorous analogies or references. My goal was not to write a textbook or a strict reference guide. Dont take it too seriously and try to have fun with it I know I had fun while writing it.

Who is this for? This Ebook is for beginning to intermediate Drupal developers, site builders, and themers who want to learn more about the best practices for building Drupal websites and learn tips to become more efficient with Drupal. These 5 secrets are not revolutionary by any means, but they are evolutionary if you are not using them. By evolutionary I mean that if you are not using these secrets then start, it will take your Drupal website development process to the next level. Any one of these secrets in itself is helpful, but using all 5 will not only improve your development process, it will change how you think about a Drupal website. If any of these statements sound familiar, then reading this Ebook will be able to help you.

If I need to make a change to one of my Drupal websites, I just change the live site. I am just really careful not to make any mistakes or I just try to make the change quickly so the website visitors dont notice any problems.

When I make a change to my Drupal website it is pretty much permanent. If I messed something up and find it a few days later, I dont really have a way to roll the site back.

I download all my Drupal modules manually or through the admin interface on the Drupal website.

http://codekarate.com/http://codekarate.com/


I upgrade all my Drupal modules one by one. I update Drupal core manually as well. I dont use a development site or a staging/testing site for my Drupal websites. I do use some type of development site, but if I make a change to a content type, view,

or anything like that, I then manually go to the live site and make that same change. I am just careful to make sure that I make exactly the same changes on both sites so they stay consistent.

Dont worry if some of these statements ring true. I am here to help. The only reason I knew to write those statements above is because at one point or another, they were all true for me. I will tell you this, since I learned these 5 secrets I have:

Less errors on my Drupal website that ever make it to the live production site. A better knowledge of what has changed on my Drupal websites over time. A more streamlined process to developing new functionality and features. A much simpler process for rolling back changes that did not go as planned. Much more peace of mind knowing that everything follows a set process on all my

Drupal websites.

What is a Drupal Ninja? In this Ebook I will occasionally come back to the terminology of a Drupal Ninja. So what exactly is a Drupal Ninja? A Drupal Ninja is a Drupal developer that goes out of their way in the beginning of a project to craft their development processes and their Drupal skills in order to complete their project with speed, efficiency, and minimal errors. This often means spending extra time upfront in order to save time, or improve quality during the project. One more quick tip, you can only ever become a Drupal Ninja, if you dont yet think you are a Drupal Ninja. It is the through the process of continuous learning that you will continue to improve. Others may call you an expert, a guru or even sometimes a genius, however with Drupal (like any software) change is always happening, and you must continually learn and adapt. I am just getting started in my journey are you ready to join me? Enough of the introduction, lets learn the 5 secrets to get you started in your quest.


Secret 1: Code Editing What you see is not what you get The first secret is not specific to Drupal and is probably the simplest of all of the secrets. Step 1 to becoming a better Drupal website developer is to find a code editor or IDE (integrated development environment) that you are comfortable with. If you are already using a code editor you like and are thinking of just jumping to the next secret dont touch that mouse wheel or scroll bar! Also, I mention a lot about code development in this section. If you are not a module developer and are instead more of a site builder or theme designer, dont worry about the development specific vocabulary used. There is still a lot you can gain from finding the right code editor. There is almost always more to any code editor than what meets the eye. These tools are built with features to try to make your life easier. Are you using these features? I am not saying you need to use all of the features under the sun, but you should at least be aware of them to know if they can help you build your Drupal websites faster. I know some of you purposely try to stay away from code editors and do as much as you can inside the Drupal administration section. As you progress with your Drupal websites, you will begin to realize that it is often much faster and more efficient to jump into some code. Whether you are building a new module, making some small tweaks to your website through a custom module, building a new theme, or just modifying the style of an existing theme, you will need a good code editor. My code editor of choice for the last 5 years has been Komodo Edit. It is a great tool that is simple, but has just enough features to keep a developer satisfied. In the following sections I will go through some of the key features that help make my life as a Drupal developer much easier. Depending on your personal development style, you may decide you want something much simpler, or perhaps even more feature rich like a full blown IDE. The important point here is that you are deliberate enough to make a decision based on what you want in an editor, not just because someone recommended it at one point. At the end of this section, I will list out a handful of other editors so you can have a baseline of what you are looking for. The only way to really make this decision though is to try a few of them out and decide for yourself.

Komodo Edit Features I could not live without For the most part Komodo Edit is a fairly lean and mean editor. But there are a number of nice to have more complex features that make my life as a Drupal developer much easier.

Syntax Highlighting for any language I would ever need Komodo Edit has syntax highlighting for PHP, HTML, JavaScript, CSS, and anything else a Drupal developer would ever need. This makes it easy to read your code and to see if you have any syntax errors. Here are some examples of Komodo Edit syntax highlighting using code from the Views module, starting with a PHP example.


Komodo is also a great editor for CSS.

I also use Komodo Edit for Javascript and Jquery development.


Nice indenting that match the Drupal development best practices Drupal development best practices say that you should use two spaces for your indenting. Komodo Edit lets me easily set that up for all different languages so I can still use the tab key to quickly indent or two spaces and it all works out the same. This is useful if you have a number of developers working on a project and are trying to follow the same indenting procedure.


Code Completion for Drupal Sometimes I know a function exists but I dont remember exactly what the function parameters are or what the function does. With Komodo Edit, I can drop in a copy of Drupal 7, and it will be available to popup in my code completion tool (often called autocomplete). In the examples below I am typing in the Drupal functions called drupal_goto and watchdog. You can see that it gives me enough information to write my code without having to visit the api.drupal.org site nearly as often. This saves a lot of time for me if it has been a little while since I have used a specific Drupal function.

https://api.drupal.org/


Code Snippets If you are developing Drupal modules or themes, you will likely need to rewrite the same code many times. I especially have to rewrite the same code when building out module hooks. A Drupal module hook is a piece of code you can write that will tie into your Drupal website during a specific time or event that happens. For instance, you can use a module hook to change a form on your website using hook_form_alter(). Discussing module hooks is beyond the scope of this Ebook, but they are powerful functions that allow you to easily change how your Drupal website looks or functions. The important point here is that Komodo Edit has Code Snippets that easily allows me to save an example module hook snippet of code, so I can quickly add it into my module when I am developing it. In the example below you can see a list of all my code snippets on the right, to add it into my code I simply double click on the code snippet. I can also set hot keys to specific snippets of code that I use all of the time which allows me to save even more time during development.

https://api.drupal.org/api/drupal/modules!system!system.api.php/function/hook_form_alter/7


Remote File Editing There are a number of circumstances in which you may have to edit a file on a remote server. Typically you would use some type of FTP tool to push and pull file changes to your Drupal website. There is a tool within Komodo Edit that allows you to make changes to remote files. In


the example below you can see the process of connecting to a remote server. It is simple and easy to set up and can be useful in a number of situations.


Other nice features Here are a few other nice features that I use in Komodo Edit

Color Schemes - If I am going to spend a lot of time editing code, I want it to look good while I do it. Komodo Edit gives me the ability to change and completely customize the color scheme.

Add ons - Komodo Edit has a bunch of add ons that can be used to enhance the editor. Go to definition - This handy little feature allows you to quickly jump to the function

definition. To put it in easier to understand terms, you can right click on the name of a function, and click Go to definition. Komodo Edit will then take you to that function. This works well if you need to dive into a specific core Drupal function, or other functions in your module or theme.

What are some other Code Editors to look into? Here is a list of various code editors that I have found that you may want to look into for your day to day code editing.

Minimalist Vim - This one is for those of you that do not like to use your mouse! It is a command line text editor that is chalked full of features. This tool is not for everyone though. I use it anytime I am doing any type of server work, but I wouldnt think of using it for my day to day code editing. If

http://www.vim.org/


you do give this one a try, dont give up at the first sign of struggle. Without learning the shortcut keys and the extra features, you might dismiss it before you realize its true power. I do know a lot of developers that like using Vim for everything, but as I mentioned before, it is not for everyone.

Code Editors Komodo Edit - As I mentioned before this is my code editor of choice. I would highly recommend it to anyone. NotePad++ - I have used this in the past and I actually kind of liked it. It was extremely simple to use but did not have all of the features I needed. TextMate - I have never used this but have heard a lot about it from Mac users. If you are running on a Mac it might be worth checking out.

IDEs Komodo IDE - If I ever decide to jump to a full featured IDE, this is probably the one I would choose. It is similar to Komodo Edit, but has even more features like Git Integration, MySQL explorer, and much more. This one is not a free solution though. Eclipse - This one is completely free and is incredibly flexible. The only problem is you will need to do some research to see what add ons you would like to have and will need. I have used this in the past with some success but ultimately decided to move away from it. Note: The last time I

http://komodoide.com/komodo-edit/http://notepad-plus-plus.org/http://macromates.com/http://komodoide.com/https://www.eclipse.org/


used Eclipse for any type of PHP, CSS, or HTML, was probably 2008 a lot has probably changed since then. Netbeans - I have used this for Java programming in the past, but I cant speak to how it would work for Drupal.

Any others? There are a ton of other code editing tools that might be worth looking into if you havent found the one yet. Here is a good link to a Drupal.org page that goes over a number of tools I havent covered here - https://drupal.org/node/147789

Why You Shouldnt Dismiss this Secret You will probably spend more time with your Code Editor than any other tool. You may try to dismiss the importance of this by thinking that all code editors are the same or that the code editor does not really matter. Thinking this way is incredibly shortsighted. If you find the right editor, you can save yourself hours of time and have a lot more fun along the way. Becoming a Drupal Ninja is about efficiency always spend the time sharpening the weapons that you use the most.

Becoming a Drupal 7 Ninja: Secret #1 Find the right Code Editor for you

https://netbeans.org/https://drupal.org/node/147789


Secret 2: Drush Command line Kung Fu Dynamite comes in small packages, but that doesnt mean you should underestimate its power. The same can be said of Drush. Drush stands for DRUpal SHell and according the the Drush github page:

Drush is a command-line shell and scripting interface for Drupal, a veritable Swiss Army knife designed to make life easier for those who spend their working hours hacking away at the command prompt.

While I think that is a fine definition, it doesnt tell the entire story. Even if you dont spend your working hours at a command prompt, I am telling you that Drush will help you if you give it a chance. If you are nervous or reluctant to spend time on the command line, I can promise you that you are missing out. If you do even a modest amount of Drupal development, spending just one hour learning how to use the command line and Drush commands will save you countless hours of time. In the next few sections I am going to show you how Drush can be used to automate and simplify a lot of common Drupal administrative tasks. In the sections that follow, I am going to go through the steps to set up a basic Drupal site with the help of Drush commands. I will leave out all the extra details about the installation such as setting up the MySQL database. If you are looking for more information on installing Drupal, keep an eye out for future Code Karate videos on the subject.

Getting Started By Installing Drush The first step is to get Drush installed. Installing Drush is not an overly complicated process, but because it varies depending on the operating system your website runs on, and if you are running the site locally or on a remote server, I wont go through all of the installation possibilities here. There is a page on Drupal.org that provides information depending on the type of platform you are installing Drush on. Typically you need to install Drush on the server that is hosting your Drupal website (you can get around this with something called Drush aliases, however we wont be covering that topic). For the installation instructions, go to https://drupal.org/node/1791676.

Downloading Drupal with Drush In order to get started with a fresh Drupal 7 website, we will use a Drush command to download the latest Drupal 7 release.

https://github.com/drush-ops/drushhttps://drupal.org/node/1791676


Drush Command What does it do?

drush dl drupal Download a fresh copy of the latest stable Drupal 7 release.

The next steps are to set up the MySQL Database. As I mentioned before I will not go over those steps, here. Assuming you have your database ready, you have a couple options for installing Drupal. The first is to do it the standard way of going to your Drupal website in the browser. This will bring you to the Drupal installation page that will look something like this:


You could go through all the steps and get your Drupal website set up easily enough, but you can also use Drush to automate this step. Note: Before you run the following command, make sure you are in the new drupal folder that was created when you ran your last drush command.


drush site-install standard --db-url=mysql://[MySQLUser]:[MySQLPassword]@localhost/[MySQLDatabase]

Installs Drupal 7 website. Note: this defaults your username to admin and gives you a random password.

Note: You can also use the Drush command drush si instead of drush site-install and get the same results.

ninja less


Now if I go back to my new Drupal website, it will look like this:

As you can see, the Drupal website has been installed. I can now log in as the admin account using the password that was displayed after I ran the drush site-install command. After logging in, my Drupal website looks like this:


Downloading and installing New Drupal Modules We are now ready to begin installing some Drupal modules and themes on our new Drupal website. I am going to start with one simple example. Downloading and installing the module_filter module.


drush dl [project-name] Downloads a Drupal module or theme. The name can be grabbed from the drupal.org project name. For example in https://drupal.org/project/module_filter the project name is module_filter

drush en [module-name] Installs a Drupal module. Keep in mind when you download a Drupal module, it may contain multiple modules. You can get the correct module name from the output of the drush dl command.

The first step is to download the module_filter module using the drush dl command:

https://drupal.org/project/module_filter


This command will tell you where the module was downloaded (in this case sites/all/modules/module_filter) and if there are multiple modules that can be enabled/installed. Now we install/enable the module using the drush en command.

In case you are curious what the Module filter module does, here is the Drupal modules page before installing the module:

Here is the Drupal modules page after installing the module:


We will now download and install a bunch of extra modules. The following examples show that you can download and install multiple modules at a time. The examples also show you that some projects may contain multiple modules that need to be enabled. We run the drush dl command to download the views, pathauto, and features modules. Notice how it is able to download multiple projects at once. Also notice that the views project contains 2 modules; views and views_ui.

We can install multiple modules at once as well using the drush en command. Notice how the views and pathauto modules require additional modules to be downloaded in order to be installed. Drush is smart enough to automatically download those modules for you.


If you look at the modules page now, you will notice that the new modules are there and have been installed.

Downloading and installing New Drupal Themes We will now download and install a new Drupal 7 theme. We will go ahead and download and install the Zen theme. Although it doesnt look very pretty out of the box, Zen is a very good

https://drupal.org/project/zen


base theme that can be used when building your own Drupal 7 theme design. Notice that when we run the drush dl zen command, Drush correctly downloads and places the theme in the sites/all/themes directory.

Installing a theme is very similar to installing a module, just use the drush en zen command to install the Zen theme.

You might expect this to change the design of your site immediately, however that isnt the case. A Drupal theme can be enabled, but not set as the default theme. Here is the Drupal Appearance page showing that the Zen theme is in fact enabled, but Bartik is still the default theme.


You can also use the drush status command to view status about your Drupal website. Specifically you can use drush status theme to view theme information about your Drupal website.


drush status Displays information about your Drupal website.

drush status theme Displays only the theme information about your Drupal website.

First we run the drush status command. You will notice there is information about the theme listed in the command output.

If you want to only see information about the theme, you can run drush status theme command.


We already know that bartik is the default theme from looking at the Drupal Appearance page on our site. However, we can use drush to change the default theme. Drupal stores a lot of your websites configuration in a database table called variables. This variables table contains information such as your Site name, Site slogan, Site email address, default theme, and much more. Drush allows us to view and change these variables.


drush vget View all Drupal variables.

drush vget [variable-name] View a specific Drupal variable.

drush vset [variable-name] [new-value]

Set a Drupal variable to a new value.

drush vdel [variable-name] Deletes a Drupal variable. Note: we wont be going over this, but use caution when deleting Drupal variables.

Here is the output of the drush vget command. You will notice there is quite a bit of variables already in our Drupal site. This list will continue to grow as we add more modules to our website. Here is the top of the output, notice there is an admin_theme variable.


Here is the bottom output of the drush vget command. You will see a variable named theme_default, this is the one we need to change in order to change our default theme.


If we run the drush vget theme_default command, you will notice we only see the output for the specified variable, in this case theme_default.

We can now run the drush vset command to set the theme_default variable and switch our theme to show the Zen theme. Notice that we can run the drush vget theme_default command again and confirm that the zen theme is now the default.


If you go back to the Appearance page on your Drupal website, you will of course see the Zen theme listed as the default theme.

If you go back to the homepage of your Drupal website, you will notice the design of the website has changed and is now displaying the zen theme design.


Disabling a Drupal Module/Theme There may come a time where you need to uninstall a Drupal module. If this is the case, you can do so with the drush dis command.


drush dis [module-name] Disables a Drupal module.

If you were launching your website and you no longer needed the views_ui module, you can disable the module using drush dis views_ui.

A Drupal module can be disabled, but that does not necessarily mean it is uninstalled. A Drupal module may create additional database tables in your Drupal database or add additional variables to your Drupal variables database table. If you disable the module, those database tables and variables will not be deleted. This means you are able to enable the module later without losing any of your module settings.


Here you can see the Modules Uninstall page. You can get to this page on your Drupal website by clicking on Modules in your admin toolbar, then finding the sub menu tab Uninstall.

The Views UI module has been disabled on our site, but has not been completely uninstalled.

Listing Drupal Modules and Themes using Drush Sometimes it is useful to view the modules and themes that have been downloaded or installed on your Drupal website. Drush provides a drush pm-list command that will allow you to easily see a list of all the themes and modules on your Drupal website.


drush pm-list Lists all modules and themes available to the Drupal website.

drush pm-list --type=module

Lists only the modules that are available to the Drupal website.

drush pm-list --type=theme List only the themes that are available to the Drupal website.

drush pm-list --status=enabled

List the enabled modules and themes on the Drupal website.


drush pm-list --type=module --status=disabled

Lists only the disabled modules on the Drupal website.

Here is the output of the drush pm-list command. The top of the command looks like this:

While the bottom of the command output looks like the screenshot below. Notice the views_ui module is listed with the status of disabled.


In the commands list above you can see that there are two options being shown. The type option and the status option. These can be used to filter the list. Many drush commands have options, you can view a list of options available to the drush pm-list command by using running drush pm-list --help.


Also keep in mind you can use multiple options together, making it possible to view only the list of disabled modules using the drush pm-list --type=module --status=disabled command.

Uninstalling a Drupal Module You can uninstall a Drupal module using the Module Uninstall page that was listed above, or you can use the drush pm-uninstall command. This command will completely uninstall your module removing any database tables and variables that the module has stored.



drush pm-uninstall [module-name] Uninstalls a Drupal module.

drush pm-list --type=module --status=not installed

Views all the Drupal modules that are not installed on your website.

Here we run the drush pm-uninstall views_ui command to uninstall the Views UI module that we previously disabled.

We can view the list of uninstalled modules using the drush pm-list --type=module --status=not installed command.


We can also confirm that the Views UI module is no longer listed in the Uninstall Modules page on our Drupal website.

Running Cron on your Drupal website Drupal uses a maintenance task called cron to run actions periodically. Drupal cron should be set up to run periodically on your Drupal website. The frequency of the Drupal cron task depends on the specific needs of the website and will vary depending on the number and type of modules you have installed. Drupal comes with a way to configure cron from the administration interface. You can get to the Cron administration page by going to Configuration in the admin toolbar and clicking on the Cron link.


Here you can configure cron to run periodically, but there is a catch. The only way cron will run is if there is someone on your website. If for instance you have cron set to run every three hours, but there is a 5 hour gap between visitors on your site, your Drupal cron will not run until that next visitor shows up. This also can make the page load much more slowly for that visitor as they have to wait for the Drupal cron process to finish. Because of this, it is beneficial to configure your Drupal website (or more specifically the server the site is on) to run cron using Drush. Ninja Lesson: Configure your server to run cron instead of using Drupals built

in Cron.


drush cron Runs Drupal cron process.

You can manually run the Drupal cron process using Drush by running the drush cron command.


Note: Configuring Drupal cron to run on your server is beyond the scope of this Ebook and the setup process will vary based on the type of server and hosting you have for your Drupal website.

Clearing your Drupal cache If you ever make changes to your site and do not know why something isnt showing up correctly, it may be getting cached by Drupal. Drupal caches a variety of things in the database to help speed up the performance of your Drupal site. While you are developing or after making changes on your site, you may need to occasionally clear the Drupal cache.


drush cc Clear the Drupal cache.

drush cc all Clear all of the available Drupal caches.

You can clear the Drupal cache using the drush cc command. After running this command, Drush will provide you an option to select which cache you want to clear. In this example we select 1 to clear all of the available Drupal caches.

You can also specify which Drupal cache to clear directly in the drush cc command. In this example we run drush cc all to clear all of the Drupal caches without the extra prompt to choose the Drupal cache to clear.


Backing up your Drupal website Backing up your Drupal website can sometimes be a hassle depending on the setup of your website and where your website is hosted. Drush provides an easy alternative to backing up your entire Drupal website.


drush archive-backup Backs up the code, files, and database of a Drupal website.

You can simply run the drush archive-backup command to quickly and easily backup your entire Drupal website.

Restoring your Drupal website from a backup A backup is not very helpful if you cant easily restore the backup. First we are going to test the process, by creating a new article on our Drupal website. After creating the article, the front page of our Drupal website is no longer empty.


Now we can use Drush to restore our website to our previous backup (before the article was created).


drush archive-restore [backup-path]

Restores a Drupal website to a previously backed up state.

The drush archive-restore command provides the easy solution for restoring our Drupal website to a previous point in time.

Now if we refresh the homepage of our Drupal 7 website, the article we just created no longer exists.


Ninja Lesson: Determine a backup and restore plan for your Drupal website.

Updating Drupal Core and Contributed Modules/Themes As with any other software, Drupal and the Drupal modules you install on your site will have updates. Drush provides an easy way for you to update the modules and themes on your Drupal website. Drush can also update the core Drupal code to a new version.


drush up Updates the modules, themes, and core Drupal code on your Drupal website. This command will also perform any necessary database updates.

The drush up command is a useful command to make sure your Drupal website stays up to date. If the output of the command contains No code updates available, then you have no available updates.


If you have an update to a contributed module, the output of the drush up command will contain information about the updates that are available.

After running drush up, if there are updates to Drupal core, the command will warn you about not running this on production sites prior to testing, and that all changes to Drupal core files will overwritten by the changes.


Ninja Lesson: Because Drupal updates using drush up will overwrite changes to

Drupal core files, it brings us to one of the most important lessons. DO NOT hack the core Drupal code. Instead build modules to extend Drupals

functionality.

Countless Other Awesome Features Drush has many more features than could possibly be covered in a short Ebook. You can list all of the Drush commands by just typing drush in the command line and hitting enter. You will see a list of commands:


This can help you if you forget a command or looking to see if a specific command exists. Drupal modules can define their own Drush commands meaning that as you install more Drupal modules, the number of Drush commands available to you may increase.

Why You Shouldnt Dismiss this Secret You may be thinking that everything you saw above can easily be done from the Drupal user interface. You are exactly right, but then again you are wrong. Becoming a Drupal Ninja is about efficiency and getting things done as painlessly as possible. Just like learning any other skill, it will take a little time to master, but it will pay dividends in the end. I will end this section with a simple analogy. You can definitely get where you need to go by walking, but isnt it much faster to drive there? Using the Drupal admin section of a Drupal website is like walking, it can get the job done, but there are much faster alternatives (in this case Drush).


Becoming a Drupal 7 Ninja: Secret #2 Use Drush in all of your Drupal projects


Secret 3: Version Control (with Git)... Never lose your code or your mind again You have probably heard of Version Control or Git before. If you are not already using a Version Control system now is the time to start. According to the Git website:

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

So what exactly is a Version Control System? To keep things simple, it is basically a way to track changes that you have made to files over a period of time. It gives you the ability to not only track those changes, but roll back to a previous point in time if something goes bad. A version control system also makes it much easier for multiple developers to work on a single project without stepping on each others toes. Git is a Distributed Version Control System, which means that every developer working on a project has a full copy of the repository. A repository is just another name for how the project and its files are stored in the version control system. Generally when working with Git you will have some type of server that you push your changes too. Often this will be a third party service like GitHub, Bitbucket, or one of the many other alternatives.

Choosing the Right Service to Host Your Git Repository There are a lot of options to consider when choosing where (and if) you want to use a third party service to host the Git repository for your project. These services provide a lot of useful tools that make working with your Git repository easier. Some standard tools to keep an eye out for include:

Ability to view the code of your Git repository Issue or Bug tracking Create and manage Git branches of code Built in Code Review Tools Collaboration tools to make building a software project with a team easier

There are typically many more features, but that is a basic list that almost all Git hosting services offer. It is best to do your own research here as opinions tend to vary on which is the best. The most popular one is probably Github. It provides a great interface and great collaboration tools. Github is especially popular in the open source software market. Github is free to use as long as you make your Git repository public. Github charges for you to have a private repository. Github bases its fees on the number of private repositories you require.

http://git-scm.com/http://git-scm.com/about/free-and-open-sourcehttp://git-scm.com/book/en/Getting-Started-About-Version-Controlhttps://github.com/https://bitbucket.org/


Bitbucket is another popular choice. Bitbucket has free Git project hosting for teams of 5 or less. Bitbucket allow for an unlimited number of public or private Git repositories. All of the fees for Bitbucket are based on the number of people on the team (not the number of repositories). This distinct difference between Bitbucket and Github often helps you decide based on the type of project you are building and the team size (assuming you are basing your decision only on price). There are many other options out there, but these are the most widely used that I am aware of. So which Git project hosting service do I use? Well both actually. I prefer using Github for any type of open source project. Githubs interface and collaboration tools are slightly better than Bitbuckets in my opinion. I do however use Bitbucket much more than I use Github. Because I often tend to work on projects in small teams, and I need private repositories for much of my work, Bitbucket is the logical choice. I also dont want to discount the tools in Bitbucket as they too are really good (Github is just slightly more user friendly). Ninja Lesson: All Git Hosting services will following the same constructs. Learn

Git and you can easily adapt to the hosting service of your choosing.

Getting Started with Git So how do you go about getting start with Git if you have never worked with a Version Control System before? The first steps are to start by downloading Git for your operating system. Once you have Git downloaded and installed, you may be tempted to download a Git GUI client. You can browse for one of your choosing and try one out (I have used GitEye with some success in the past as it provides a Linux version). I wont be covering Git GUI clients because frankly I dont like using them and I think they shroud what is actually happening (sometimes making it seem more confusing than it has to be). Even if you do want to use a Git GUI client, I highly suggest learning the basics from the command line first. This will give you a much deeper understanding of what various commands are doing and how the entire Git process works. In the subsequent examples, you will be able to follow along to create your first Git repository, learn the basics of Git commands, create a larger Git repository for your Drupal website, and learn how to pull down external Git repositories (like those on Github or Bitbucket).

Git Configuration The first step is to open up your command line. You may want to create an empty test folder somewhere on your computer so you can test a few basic Git commands. I will start with a folder on my desktop called git_test. You will want to make sure your are inside that folder on your command line.

http://git-scm.com/downloadshttp://git-scm.com/downloads/guis


If this is your first time using Git, you will likely need to configure your basic Git settings.

Git Command What does it do?

git config --global user.name [name]

Configure the username for Git to use for the current logged in user.

git config --global user.email [email_address]

Configure the user email address for Git to use for the current logged in user.

You will first want to configure your name.

Then you will want to configure your email address.

You should now have your basic Git configuration set up. You are now ready to create your first Git repository.

Creating Your First Git Repository


git init Creates a Git repository in the current directory.

git init [folder] Creates a new directory and Git repository.

Creating your first Git repository is incredibly simple. Just run the git init command on the command line from within your project folder.


If you have not created the git_test folder yet, you can create the empty directory and the Git repository in one step.

Either of the above commands will create a new empty Git repository for you to start working with. It does not get much simpler than that. One simple command to Git you started.

Viewing Your Project Status


git status View status information about your current Git repository.

The git status command is a command you will run early and often. It tells you the basics of what has changed with your Git repository. If you run the command now, you will see that there is nothing to commit yet. The command does tell you the branch that you are on (which we will cover later), as well as text telling you this is the Initial commit.

Note: Notice how the last line of the git status command tells you to create/copy files and use git add to track. Git is full of these helpful hints that tell you what you need to do. This can especially be helpful when you dont know what to do or it has been awhile. I have spent way too much time searching the internet for answers, when the answer was often in the command output of the the Git command I previously ran.

Ninja Lesson: Read the output of Git commands. It will save you time and headaches.


Open up a text or code editor and create a test file. Name your test file test.txt and keep the text really simple for now.

You will see what my current git_test directory looks like with the new test.txt file created.


Now re-run the git status command to see what has changed.

Notice how the test.txt shows up under the Untracked files section. Also notice the line above the test.txt line that tells you how to add this file to include it in what will be committed. Note: You may have noticed the .git hidden folder inside the git_test folder. This hidden folder is created when we created the Git repository with the git init command. It is used to track everything about our Git repository. If you delete this folder, you are deleting your local Git repository.


Ninja Lesson: Do not delete the .git folder or you will delete your entire local Git repository.

Adding Files to your Repository The next step in the process is to add the files to the Git staging area. The Git staging area is a middle ground between what has changed, and what has been committed to your Git repository. You can add files to this area and when you are ready, commit these files into one Git commit.


git add [file] Add a specific file to the Git staging area of your repository.

git add . Add all new/modified files inside the current directory to the staging area of your repository.

We are going to run the git add test.txt command to add the test.txt file to our Git staging area. We will then run the git status command to see that our file is now ready to be committed.

If we had multiple files to commit, or we did not want to type in the file name, we can use the git add . command. The . (period) indicates to Git to add all new/modified files in the current directory or any subdirectories in the current directory (it does this recursively so even files in multiple levels of subdirectories would get added). We will use this command in future sections to provide a better idea of how it works.

Committing Your Changes A Git commit is a way to finalize and log the changes that we have added to our Git staging area. This essentially creates a new revision of your project at this particular point in time.



git commit Commits all changes from the Git staging area, and launches a text editor to create a commit message. Save and close the text editor to complete the commit.

git commit -m My commit message goes here

Commits all changes from the Git staging area with the corresponding commit message.

You can use the git commit command to commit all of your staged changes. You will then need to fill out a commit message after the text editor is opened. After you save and close the file, the commit will be finalized. You can also use the git commit -m command along with an inline commit message to simplify the process into one command. I prefer using this method as it is simpler than having to use a separate text editor tool. I also show the git status command after the commit which lets us know that we have nothing new to commit (our working directory is clean).

Note: The commit message is much more important than it originally seems. The commit message provides a way for you to describe what has changed in the project. This makes it easy for you or others to quickly look at a history of commits to see how the project has changed over time.

Ninja Lesson: Commit early and commit often.

Viewing Your Commit History What good is creating new revisions using Git commits if you cannot easily see what has changed.


git log View a history of commits to the Git repository containing the author, date, and description of the commit.


Use the git log command to see the revision log of your Git repository. This will tell you the author of the change, the date, and what has changed (using the Git commit message).

Viewing What Has Changed Now that we have our first Git commit under our belt, we will make a few more changes. Lets add an additional line to our test.txt file.


We will also create a new subfolder inside our git_test folder. Lets call this directory test_folder.


Inside this new test_folder directory, we will create a new file called test2.txt.


We can now view the status of our git repository with the git status command.


Notice the command output of the git status command lets us know that the test.txt file has been modified. It also lets us know about an untracked directory called test_folder.


git diff Shows the changes between the last commit and the current working tree. This will only show changes in files that have been added to the repository.

Use the git diff command to see the specific changes of any files that have been modified.

Ninja Lesson: The git diff command only shows changes to files that are already being tracked by your Git repository.

We can use the previously mentioned git add test.txt command and a git add test_folder/test2.txt command to add the two files to the staging area, or we can use the git add . command to add both files for us automatically.


Ninja Lesson: The git add . command can be a real time saver, just be careful

not to commit files you were not intending to commit.

Undoing Changes There will inevitably be a time where you will need to undo a change. Git makes this process relatively easy. The first undo situation we will cover is when you add a file to the Git staging area that you did not want to add. Luckily for us, Git tells us exactly how to remove this file when we run a git status command.


git reset [file] Removes a single file from the Git staging area but keeps any changes to that file.

git reset Removes all files from the Git staging area but keeps all changes to the files.

Note: The git status command says to use the git reset HEAD command. However, in this case HEAD is assumed so it is not needed to accomplish the same result. If we want to remove the test.txt file from the staging area, we simply run the git reset test.txt command.


As you see in the screenshot above, the output of the git status command now shows the new test2.txt file is still in the Git staging area, however the test.txt file is not. Notice that our changes to the test.txt file were not lost, we simply removed this file from the Git staging area. You can confirm your changes are still there by running the git diff command. If we decide we want to remove all files from the staging area, we can run the git reset command.


Now you will notice that we no longer have any changes staged for a commit. The git status command still shows us we modified our test.txt file and it now shows us that we have files in our test_folder directory that are not being tracked by Git. Ninja Lesson: The git reset command will cause you to lose any uncommitted

changes. Use with caution or you may lose all your work. What happens if we made a change to the test.txt file by mistake? What if we wanted to get rid of any of the changes we made to the test.txt file and instead go back to our last commit. This is also easy to do with Git.


git checkout [file] Gets rid of your local changes to a file and instead checks out (or uses) the contents of the file from the last commit.

The git checkout command serves many purposes. It can be used to checkout a specific Git branch (discussed in the next section), checkout a specific Git commit, or in the case above, checkout a file (which reverts it back to the last commit). You can run the git checkout test.txt file to get rid of your local changes to the test.txt file. It helps me to think of it this way I want to checkout the last committed copy of the test.txt file and replace (or drop) my local changes to the test.txt file in the process.

In the above command output, you can see that the test.txt file is no longer showing up as modified. You will also see that the git diff command does not have any output (meaning nothing has changed). The last undo situation we are going to cover is how to undo a Git commit. First we need to start by making a commit that we are going to later undo. We will commit up our new test2.txt file.


Now lets look at the git log command to get an idea of what our commit history has been. You will see both of our commits are listed.

Now we are going to look at what steps we need to follow to safely remove that last commit. Notice the commit id highlighted with a red box around it. We will need this commit id in order to safely revert the commit.


git revert [commit] Provides a way to safely remove a previous commit. Git will automatically remove the changes, and then create a new commit. This way you still have a history of the change being removed.


We grab the Git commit id from the log message of our last commit and run the git revert f54a3f4e00e0ffcbe72c5f3f8be90047a145cb65 command. After running the command a text editor will open allowing you to add a commit message. You can add additional information or accept the default commit message. When you are ready save and close the commit message in the text editor. Below you can see my Nano editor that Git has opened for me.

After saving and closing, the commit has been successfully reverted by Git and the entire history is now tracked (as seen in the following git log command).


An Introduction to Git Branches To me, Git branches are the most powerful feature Git has to offer. Initially they seem very complicated, but they are actually simple once you understand their uses and their benefits. One thing to keep in mind is that Git branches are incredibly flexible. Entire books and blogs have been written on how Git branches can be used in a specific way to build the ideal development process for various types of software. With that in mind, we will only be scratching the surface of what Git branches offer. Lets start with a practical, and possibly old fashioned example. Assume you are writing some type of paper. Assume you are using an old word process that is not online, but is instead a program on your computer. You write the paper and decide that it needs a lot of work. Instead of editing the document directly, you make a copy and work on that document. This way if you really mess something up, you can just delete the copy and start over. When you are done with this copy and you like the changes, you may manually copy in the changes you like, or if you like all the changes, just get rid of your old version and use this new version as your paper. This example is similar to how a Git branch works. You are essentially making a complete copy of your repository so you can either work on new features, fix bugs, or keep different versions of your code. There are two common ways that I have used Git branches in the past.


The first and simplest way is to have a development and a master branch. All your new features are developed on the development branch, and when you have everything working and ready on the development branch, you merge the development branch into the master branch. This way you keep your master branch as the true production level code, while keeping a development branch to build new features and fix bugs on. This is a useful way to get started, however it starts to break down when you have a number of developers working on the same branch at the same time. In the diagram above, a copy of the master branch is made by creating a development branch. Development is then completed (each circle representing a Git commit). When the development is finished, the development branch is merged in with the master branch. In this model, the Development branch is always kept open.

The second way (and my preferred method) is to use Git branches to develop new features, or fix bugs. This is actually really simple if you take a second to think about it. Any change that you want going into the master branch (production/live code) must first originate as its own unique Git branch. If you need to fix a bug, you create a new branch to fix that bug, and when its ready, merge it into the master branch. If there is a new feature to be built, you create a new Git


branch, develop the new feature, and when its ready merge it into the master branch. If you are working on just one thing at a time, this may seem like a little overkill. However, imaging you are working on two or three features at one time. Keeping separate Git branches for each feature means you can release one of the features without having to have all of the features completed. In the diagram above, you can see that there are examples of both a Bug fix branch and a New Feature branch. Development is performed on each branch and as soon as the individual branch is ready, it is merged into the Master branch. The final circle in the Master branch contains both the Bug Fix and the New Feature. Using the Git feature branch process, the branch is closed after it has been merged in with the Master branch. It is important to keep in mind that in this example you may have a good number of branches open at one time (depending on team size and what you are developing).

Ninja Lesson: If you use some type of project management or task management system (and you should), you can name your branches containing

the id number of the task. For example if I have a task to add a newsletter signup form to a website with a task id of 123, I would create my branch and call it 123_newsletter_signup_form to make it easy to track down exactly

what it is and why it was created. There is a third and more complex way. If you are building more complex software with longer release cycles a method known as Gitflow (or various versions of it) can be used. The reason I dont mention it in more detail is because it is slightly more complex and can lead to longer release cycles for your software. I enjoy having the ability for myself or the developers I work with to be able to make a change and have it released on the live website in the same day (sometimes in a matter of a few hours). This keeps the process lightweight and simple. In most cases with websites you do not want long release cycles and instead want the process of getting something launched on the live site to be managed but not difficult. Lets look at the paper example again. You could email your paper to a friend for editing. Your friend would make some changes and suggestions and send it back to you. You would then decide which changes you want to keep and those that you are not going to use. In this example, think of your paper as the master Git branch. Your friend gets a copy (a new Git branch), makes some changes (some Git commits), and requests that the changes be merged in (a Git merge request). Now that you understand the basic concepts, we are ready to try out a few real examples.

Creating a Git Branch The first step to learning how to actually implement Git branches is to create your first Git branch. In the following examples, we will go through the process of implementing a new branch


to build a new feature. We will just use simple text files, but you should be able to easily see how it can be used with your code.


git branch [branch_name] Create a new branch (copy of the code) to use to develop a new feature or fix a bug.

git branch Lists all of the available branches

To create your first branch called my_new_feature, we just run the git branch my_new_feature command.

In order to see all of the available Git branches in your repository, you can run the git branch command.

Notice in the example we have two branches, one called master and one called my_new_branch. The * character indicates the branch we currently have checked out. Any new commits we make will be on the currently checked out branch.

Checking out your Git Branch Now that we have the branch created, we need to checkout the branch in order to start committing our code changes to it.


git checkout [branch_name] Checks out an existing Git branch. This simply switches your code to a different Git branch.

git checkout -b [branch_name] Creates a new Git branch and checks it out. This is a shortcut so you do not have to create the branch and check it out using two steps.


To checkout your my_new_feature branch run the git checkout my_new_feature command. If you run the git branch command afterwards, you can see that you now have your new branch selected.

There is also a shortcut command to create a branch and check it out at the same time. You can run the git checkout -b another_new_feature command to create a branch called another_new_feature and immediately check it out.

Switching back to the my_new_feature branch is as simple as re-running the git checkout my_new_feature command.

Making changes on your new branch Making changes on your new branch is exactly the same as before. Simply make the changes, add your changes to the staging area, and commit your changes to your Git branch. In this example we make a small change to a text file, add the change, and make the Git commit.


Merging a Git Branch After you make your changes and you have those changes tested and ready to go, the time will come to merge in your changes from your feature branch into your master branch. Again, the master branch is typically the Git branch used for your production level code.


git merge [branch_name] Merge [branch_name] into your currently checked out Git branch.

The first step is to checkout your master branch using git checkout master, after that you can merge in your my_new_feature branch into your master branch by running git merge my_new_feature.


Fixing a Conflict It is inevitable, eventually something will happen that will cause some type of conflict in your commit. Dont worry though, it is not as scary as it sounds. A conflict happens when two different commits change the same file, or more specifically the same section or even line of a file. Git will attempt to automatically merge the changes and generally does a pretty good job, however if it cant auto merge the changes, it will ask you to resolve the differences manually. The first step is to create the scenario of a conflict so we can see how to handle it. The first step is going to be to make a change on our master branch (this could be from your or someone else working on another feature branch and merging their changes in with master). In our example however, we will just make a change directly to master.


Next, we will check out our old my_new_feature branch and make a change to that same file (the same line of the file to be exact).

We will now follow the same process as before to try to merge the changes. This time however, you will notice that Git tells us there is a problem.


There are two ways this conflict can be resolved, the first is manually using a text or code editor. If we open up the test.txt file in our editor, you will notice a few strange things.

To merge the changes, all you need to do is select the line you want to keep, and remove all of the other lines. In this case if we wanted to keep the line of text Making another change for my_new_feature branch., we would remove the > my_new_feature line. It would look like this when we were finished.

We would then need to add and commit this change like normal using the git add and git commit commands.


There is a second option for merging a conflict in Git. This option is to use some type of Diff Viewer tool to help resolve the differences. There are many various tools to choose from, however in this example I will use Meld. Note: To follow along with this example you will need some type of diff viewer.


git mergetool Opens up an external Diff viewer or merge tool for merging conflicts.

The first step in this approach is to run the git mergetool command. This command then asked me if to hit the return key to open up my Meld Diff Viewer application. Once I hit return, the application opened showing me the differences in the file.

Inside the Meld Diff Viewer, it shows me three copies of the file. The first column is the Master branch or what I am trying to merge my change into. The Last column is the change I am trying to merge in. The middle column (and this could differ based on the settings you use, or the diff viewer you are using) is the last common ancestor. This is essentially the last time the two


branches were the same. In our case this is before each of our last commits to the master branch and the my_new_feature branch. To select the change you want, simple click the arrows to move the code over to the center. The only code that really matters is what ends up in the center. So by click the left pointing arrow in the right column, you can move the code from the right column to the center column.

Once the code is in the center column, click the Save button and close out of the tool. Here is what the command looked like from the command line.


You will notice that the original git status command showed the test.txt file in the Unmerged paths section. You will also notice that after running the git mergetool command there is a new test.txt.orig file sitting around. This file contains the original test.txt before the mergetool command was run. There are a few ways to deal with this file. The first is to simply delete it, another is to configure your Git to not create these backup files in the future by running the git config --global mergetool.keepBackup false command, or you can just ignore this file by adding it to something called a .gitignore file (which we will discuss briefly later).

In this case, we simply delete the file and are ready to run our git add and git commit commands as normal.

Pushing your Repository to Github In the next few sections we will look at both Github and Bitbucket and how to push your Git repository up to these Git hosting services. This section will only prove to be a really quick getting started. There is ample documentation on both of these services online if you choose to pursue using one or the other. First we will look at Github. You will first need to create an account at github.com. Once you are logged into your account, you will want to set up your SSH keys. Your SSH Key is how Github knows who you are. This way when you push up your changes, Github will be able to determine if you have access to the Git repository you are trying to push or pull from. The first step is to make sure you have an SSH key setup on your local system. Since the setup varies depending on your operating system, you will want to search for something like Generate SSH Key [operating-system].

https://github.com/


This should give you some results. If you are using a Linux based operating system or a Mac, you can probably just run the ssh-keygen command (however you should probably do a little research so you can understand the various options). After you have an SSH key setup on your local system, you will have a .pub file available to you in your ~/.ssh/ directory (this might be slightly different on a Windows computer). Open up the .pub file (in my case it is id_rsa.pub) and copy the contents of the file. In your Github account, click on the Account Settings link, and go to the SSH Keys section. Click the Add SSH Key button, give your key a title (probably something related to your current computer), and paste in the contents from your .pub file into the Key section. Click the Add Key button to save your key. You computer should now be hooked into your Github account allowing you to push and pull your Git repositories. Now that you are setup and ready to go, on your account homepage you should see a section listing your repositories and a button to create a new one.

You will want to fill in information about your new Git repository and click the Create Repository button.


After creating your repository, Github will take you to a page with information on what to do next. First click on the SSH button so we can see commands that will use the SSH key we just linked up. In our case, we already have a repository created, so we will focus on the last section called Push an existing repository from the command line.


We will grab that first line of code and paste it on our command line (inside our Git repository).


git remote add [remote-name] [remote-url]

Adds a remote repository called [remote-name] located at [remote-url]. We can now push and pull from this repository (assuming we have permission).

git push -u origin master Push our master Git branch to the remote called origin.

Paste the git remote add command from Github into your command line and run it. Then do the same with the git push -u origin master command. Your output should look something like this.


If you refresh your page on Github, you should now see your repository listed.

You can now look through and begin using the Github tools on your Git repository. Anytime you make a Git commit to your master branch you can simple run the git push origin master to get the changes to be pushed up to Github. If someone else pushes changes to your Github repository, you can run a git pull origin master to pull in the changes to your local Git master branch. You may have noticed that only the master branch is listed on Github, you can push your other branches up as well. Simply run the git push origin [branch-name] command to push up a branch to your Github repository.


Learning about Git remotes You already ran your first git remote command. But what exactly is a Git remote anyway? A Git remote is a remote Git repository that you can synchronize with. Because Git does not have a centralized repository, you can have multiple Git remotes setup for one project. There are a couple commands that are useful when working with Git remotes.


git remote Lists the available remotes for your current Git project.

git remote -v Provides more information about your Git remotes, such as the location and what operations can be performed.


git remote rm [remote-name] Remove a Git remote from your current Git project.

The git remote and git remote -v commands are useful for listing information about your current Git remotes.

We could remote the origin remote by running the git remote rm origin command. Keep in mind, deleting the remote, does not delete the remote Github repository. It simply deletes the link between our repository and the Github repository. In this case, we will remove the remote called origin and recreate the same remote but call it github. We also make one small change to the test.txt file, add it to the staging area, commit the change, and push our change up to github using our new remote we just created.

Ninja Lesson: Although it is a good practice to use origin as the remote name

if you only have one remote, the name of the remote can be anything that


helps you remember where you are pushing your changes to or pulling your changes from.

Pushing your Repository to Bitbucket Now that you have seen how Github works, we will also push our repository to Bitbucket. We could push to either Github or Bitbucket, but Git allows us to seamlessly push to both through the use of Git remotes. Make sure you have a Bitbucket account created if you want to follow along. You will need to link your SSH key in the same way you did with Github. You DO NOT need a separate SSH key for each service. The process for adding an SSH Key is almost identical to that of Github. Simply go to the Manage Account section, click the SSH Keys tab, and add a new SSH Key. Paste in the contents of your public key (the .pub file). Now that you are setup, you are ready to create your repository on Bitbucket. Back on the Dashboard page there are two places to easily create a new repository. The first is the Create link at the top of the page.

The other is a Create a repository link in the Repositories section.

Fill in your Git repository information and click the Create Repository button.


Once you create the repository, you will see a page that displays information on how to add your code.

If you click the Im starting from scratch link, you will see information on how to create a new Git repository and add Bitbucket as a Git remote.


In this case, we already have a Git repository created, so you can click the I have an existing project to push up.

The only difference from the code listed on Bitbucket is that we dont want to create a remote called origin. We will want to add a new remote and call it bitbucket.


Now we need to push up the repository to bitbucket using the git push command. We dont need to use the -u parameter. The u parameter allows you to push and pull without having to specify the remote. Since we have two remotes, we will always want to specify this anyway. If we refresh the page on Bitbucket, you will see your repository and all of its history has been pushed up.

Now when you commit changes you can choose to push to any of your Git remotes by using the git push github or the git push bitbucket command. The git pull command works the same way allowing you to pull changes from either remote.

Cloning an Existing Git Repository It is not only useful to know how to push up your Git repository to a third party service, it is also useful knowing how to pull this repository down so you can make changes to it.


git clone [git-url] [folder-name]

Clone a Git repository at [git-url] and place it in a new directory called [folder-name]


Using the git clone command we can easily pull down a remote Git repository. First we need to find the Git url from Bitbucket (we could also have chosen to clone from Github instead). The Git url can be copied from the Bi

shane thomas - the 5 secrets to becoming a drupal 7 ninja - 2014

Documents

drupal ninja

drupal moduletheme

listing drupal modules

new drupal modules

code editing

code editors

code completion

code snippets