Working on an Issue From the Drupal Issue Queue
These are the steps, using git mostly, needed to work on an issue from the drupal issue queue.This will download the most recent commits to drupal-core from the central git repository and apply them to your 8.x branch.To list all of the branches, run:git will show all of your branches, and it will star the current branchNext work in your topic branch, make some changes.Also, if the last good state was a few commits ago, you can reset the current state to a previous commit withwhere 00581a73afab6 is the SHA1 of the commit you want you working directory reset to. to find previous commits and their SHA1’s, run git log:This will give a listing of the entire commit history. You can travel back in time! To see what files have changed since the last commit, run:This will show which files have been modified. To see what the actual changes are, run:Now when you run git status, you will see that the file is now under the header “Changes to be commited.” This intermediary step may seem strange if you are new to git, but it is very handy. It allows you to break up changes into separate logical commits. You can stage and commit one logical set of changes, and then stage and commit another set of changes. Although, it may be better to separate different issues into different topic branches.This will open your default editor, so you can write a descriptive commit message.Next, create a patch with git diff. Drupal has a specific naming convention for patches ([module_name]-[short-description]-[issue-number]-[comment-number].patch). In the case of a patch for drupal core, this can be shortened to [short-description]-[issue-number]-[comment-number].patch The following git diff command will print out all of the difference between the current branch (8.x) and the listed branch (fix-typo):Next go to drupal queue, write up a description, attach the patch, and change the status to “needs review”.
First Time: Clone Drupal Corecd into your development folder and git clone drupal core, (in this case, I’m working on a drupal 8 issue).
cd ~/projects/ git clone --branch 8.x http://git.drupal.org/project/drupal.git drupal-8.x cd drupal-8.x
Later, Refresh Repository with Git PullAfter you’ve already cloned a copy of drupal for testing and development, all you have to do is run “git refresh” to update your copy.
cd ~/projects/drupal-8.x/ git checkout 8.x git pull
Create a topic branch for your issueIts a good idea to do development work in a separate development branch. The following creates a new branch and checks the new branch out, so any subsequent changes will be made to that branch.
git branch fix-typo git checkout fix-typo
8.x * fix-typo profile-docs
Work without fearWith git, you can work without fear! if you foul things up, getting back to a previous state is easy with git reset. The following command will return the state of your code to that of the last commit.
git reset HEAD --hard
git reset 00581a73afab6 --hard
git diff HEAD
Stage and Commit ChangesOnce you have some changes that you’d like to preserve, you first stage them to the index:
git add thefile.ext
Commit changesNow that your changes are staged, it is time to commit them:
Create a PatchNow that your changes have been made and committed, its time to create a patch that you attach to the drupal issue queue. First switch back to the 8.x branch:
git checkout 8.x
git diff fix-typo > fix_typo_in_bartik_css-902839-1.patch
Use git format-patch to include committer informationAlternatively, you can use the git format-patch command to include the committer information in the patch:
git format-patch origin/master fix-typo > fix_typo_in_bartik_css-902839-1.patch