This command creates a new branch named fooproject and checks it out. (On your local development environment) $ git checkout -b fooproject Now, you need a branch where you can track not only Drupal core, but also all of the contributed and custom modules and themes for your site. (example: see a list of your remote repositories, run the command: $ git remoteįor a more detailed listing that includes the remote repositories' URLs, add a -v flag (for verbose) to the end of the command: $ git remote -v $ git remote add origin path/to/your/central/git/repo (On your local development environment) $ git remote rename origin drupal You should rename the original origin remote (the Drupal project repository) to ‘drupal’ and create a new origin pointed at the bare repository you’ve created on your server.
#Puush webpage capture update
You’ll need to update your remotes to reflect that you won’t be pushing to with your project’s code. Then, to switch to the version you want, you would type the following command, where is the name of the release you want to use: $ git checkout For example, the equivalent command for Drupal 9.2.0 would be git checkout 9.2.0 To choose another release before install, you can run the following command to view a list of all releases: $ git tag When using Drupal 8 or higher, note the addition of a decimal place in the version.
#Puush webpage capture code
The final command, git checkout 7.0, ensures your code is on the Drupal 7.0 release. The fooproject directory will become your working tree. The first command clones the Drupal core Git repository from and saves it in a directory named fooproject. (On your local development environment) $ git clone fooproject Let's clone Drupal (version 7) to create a local development environment. This example begins the development process on the developer’s local development environment, but you could follow these steps on the server as well. Rather, it is simply the central location for the git objects and history, and is essentially empty at this point. This directory is not the working tree, where you edit and commit code. This command creates a new directory called fooproject.git that contains all of the git objects. For convenience, create the central repository inside fooproject’s home directory.
For purposes of illustration, assume that your FooProject is running on a server configured with a user named ‘fooproject’ and all three environments will be running from separate directories under that user’s public_html directory. This could live on one of the servers provisioned for the project, a Gitosis server, a Gitolite server, a GitLab server, Github or any other repository hosting solution. When working on a project with multiple environments, a good first step after server provisioning is to create a central repository from which all other environments will pull. Additionally, the Backup and Migrate module can save database exports as files within your Drupal file tree these are managed with Git like any other file.įortunately, since a Drupal site's module and theme files already live in code, you can manage those in Git without any extra tools. You may want to take advantage of these tools to export as much of your site’s configuration as possible into your repository for deployment and collaboration purposes. You can move some of these configuration settings into code using certain Drupal modules, such as Ctools exportables, the Features module or the Configuration Management module. One challenge of using any kind of change management with Drupal is that many configuration changes normally reside only in the project’s database.
We will be illustrating the process by building out a Drupal site called ‘FooProject’, and will use fooproject as a placeholder anywhere a project or site name would be used. It can easily be adapted to fewer tiers, as necessary. This documentation assumes that the project will be following a basic 4-tier development environment model: developers work on most code locally, then push that code up through Development, Staging and Production environments. Further documentation will be written to show how best to integrate other tools such as Drush into this process. When applied properly and with some forethought, Git is a very powerful tool for helping to manage collaboration, configuration and code changes during the life cycle of a Drupal-based project. While there are many possible approaches to fitting Git into this process, this particular set of procedures should work in most circumstances and contains many best practices for using Git in this manner. This document is intended to outline a basic process of using Git in the context of a basic site building, testing and deployment process.
0 kommentar(er)
