These are the steps, using git mostly, needed to work on an issue from the drupal issue queue.
First Time: Clone Drupal Core
cd into your development folder and git clone drupal core, (in this case, I’m working on a drupal 8 issue).
git clone --branch 8.x http://git.drupal.org/project/drupal.git drupal-8.x
Later, Refresh Repository with Git Pull
After 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.
git checkout 8.x
This will download the most recent commits to drupal-core from the central git repository and apply them to your 8.x branch.
Create a topic branch for your issue
Its 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
To list all of the branches, run:
git will show all of your branches, and it will star the current branch
Next work in your topic branch, make some changes.
Work without fear
With 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.
Also, if the last good state was a few commits ago, you can reset the current state to a previous commit with
git reset 00581a73afab6 --hard
where 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:
Stage and Commit Changes
Once you have some changes that you’d like to preserve, you first stage them to the index:
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.
Now that your changes are staged, it is time to commit them:
This will open your default editor, so you can write a descriptive commit message.
Create a Patch
Now 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:
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):
git diff fix-typo > fix_typo_in_bartik_css-902839-1.patch
Use git format-patch to include committer information
Alternatively, 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
Next go to drupal queue, write up a description, attach the patch, and change the status to “needs review”.