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.

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). 
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 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. 
cd ~/projects/drupal-8.x/
git checkout 8.x
git pull
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 branch
git will show all of your branches, and it will star the current branch 
8.x
  * fix-typo
    profile-docs
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. 
git reset HEAD --hard
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: 
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: 
git status
This will show which files have been modified. To see what the actual changes are, run: 
git diff HEAD

Stage and Commit Changes

Once you have some changes that you’d like to preserve, you first stage them to the index: 
git add thefile.ext
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.

Commit changes

Now that your changes are staged, it is time to commit them: 
git commit
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: 
git checkout 8.x
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”.