So, friends, we left off with a freshly installed Drupal project on our local drive, along with an updated time zone setting in the .ini file that was provided with the customized PHP install.
I think the next thing to do is continue documenting the steps from Andrew Cornell’s tutorial. Today, I think this will involve the establishment of a Git repository, which will be on GitHub for now. I may move it to GitLab at some point.
So to recap (see part 2 for more details):
1. Go to Bash terminal.
1.1 [3:30] check which version of Composer you are running, and where you are running it. You can install it locally just into the directory you want to run this Drupal installation or you can install it globally, as we have; your choice. Again from my part 2 post, install Composer prior to following the steps in Andrew’s tutorial.
1.2 [5:06] Make sure you have Git installed in your system, as well. We’ll be using Git to clone a Drupal repository from GitHub into our local system directory.
2. [7:05] Navigate to the directory (via your bash terminal) in which you wish to install your Drupal project.
3. [7:17] Install your Drupal site into this directory with Composer:
composer create-project drupal-composer/drupal-project:8.x-dev some-dir –stability dev –no-interaction
Command found here: https://github.com/drupal-composer/drupal-project
=== This is where we left off from part 1 and resolved in part 2 ===
4. [8:50] Navigate into new local site directory via terminal/command line.
5. [9:50] Create git repository in local site directory ‘git init’
6. [10:18] Add untracked files to new repository in order to track them. ‘git add .’
7. [10:30] Commit the newly added files, along with a message ‘git commit -m “your message here” ’
8. [11:00] create new development branch in order to avoid working directly in the the master branch. I’m gonna call my new branch the develop branch ‘git branch develop’. Andrew called his ‘test’, which I think is potentially a more confusing branch name. If you’re new to Git (and I’ll admit I’m fairly new myself), here is a great guide on Git naming conventions and workflow: https://nvie.com/posts/a-successful-git-branching-model/.
9. To see your branches in the terminal/command line, type ‘git branch -l’. You will see that you are currently working on the master branch, as indicated by the asterisk (*).
10. [11:16] You’ll want to move to the new develop branch before you begin working. How to do this? In your terminal, type ’git checkout develop’
11. [11:43] Prepare to create a remote repository. You’ll need a host for your git repository. It is entirely possible to create one on your own server somewhere, but there are a few free options, as well, GitHub, GitLab, and BitBucket being among the most popular. The advantage (or disadvantage) of these is that you can make your work public and show off what you’ve been up to, share useful code, and be part of a community as a means of tech, and possibly moral, support! You’ll need to sign up for one (or more) of these free accounts if you wish to use them. You can see my comments in part 1 of these Journey posts about this. Andrew is going with GitLab, but I’m going with GitHub this time. I think it is possible to move from one to the other if I change my mind at a later date.
[11:58] Log into your Git repository account of choice, create a new project and name it (I recommend naming by your website’s name or plugin name or app name, etc. Here’s a good guide on choosing a name for your project: http://gravitydept.com/blog/devising-a-git-repository-naming-convention)
11.1 Before clicking the ‘Create Repository’ button, consider what license you wish to operate the project under. GitHub offers a nice guide for this (https://blog.github.com/2013-07-15-choosing-an-open-source-license/). I’m sure the other accounts do, too.
12. [12:38] Copy the ssh path of your new remote repo. If you used GitLab, like Andrew, you can see how he found it in his video. For GitHub, once you’ve created the new repo, you will see a button labelled ‘Clone or download’ on the repo page. Click that and then you can copy the ssh path there (or you can choose to ‘Use HTTPS’, if you prefer).
13. [12:44] Use that ssh path to create your remote from your terminal/command line. ‘git remote add [remote-name] [paste-ssh-path-here]’
14. [13:14] Enable ssh agent for pushing and pulling to the remote repository. ‘eval $(ssh-agent -s)’
15. [14:04] Add ssh key in order to automate the push/pull processes to the remote repo.
15.1 You may need to add an ssh key from your ssh-agent and then add it to your remote repository before Andrew’s instructions in step 15. (I did, which is why I bring this up). https://help.github.com/articles/connecting-to-github-with-ssh/. You’ll need to add your private key locally via the terminal (for my mac, it was id_rsa) and then copy via terminal command your public key (id_rsa.pub) and add that to the remote repository. GitHub details the required steps in the above-provided link.
And voila! You now have an SSH link to your remote repository. Once you have done this, you can…
16. [14:20] Push your local Git repository into your remote repository and (if it is public) show it off to the world! ‘git push [remote-repository-name] [branch-name]’. And here is mine, pushed to my GitHub account. https://github.com/janusoo/exploring-japan.com/tree/develop
I think I’ll end it here for today folks. There’s still plenty more to do, of course; pushing new code to the hosted web URL, adding Drupal themes, making updates and pushing them to the remote repository, cloning the repo to another local drive (not necessarily in this order). We’ll continue following Andrew’s tutorial toward completion in part 4, and then explore other necessary development actions after that.