Skip to content
This repository

Use this method if your patch only contains a single commit. You can use git rebase --interactive to squash to one commit before publishing the change.

This is a simple exercise for those interested in contributing to erlide. Say that you find a bug in erlide, or decide to fix an existing bug reported in our ticket tracker. I’m assuming that the bug is in the main branch of the project, master. Assuming that you have read Working with Git and are ready to start hacking on your forked repository, let’s get started:

cd erlide
git checkout master
git pull origin
git pull upstream master

What you’ve done here is to check out the master branch and to make sure that you have all the latest changes from both your forked repository on GitHub and from the erlide project’s upstream repository. Now you’re ready to fix the bug. All you have to do is create a new branch and start hacking:

git checkout -b #1449

This command creates a new local branch named “#1449” and checks it out. I’ve named it as such for the bug number. And I say “local branch” because it only exists in the local repository; think of it as a working branch to be used just for the duration of fixing the bug. So now, go ahead and fix it! As you work, commit early and commit often. You can use git add to add one or more files to commit and then commit them:

git add path/to/file.java
git commit -m 'Fixed typo in `file.java`.'

Or, to commit all your current changes at once, just use git commit -a:

git commit -am 'Removed the `id` field.'

Note that you can use GitHub-Flavored Markdown in your commit messages and they’ll be nicely formatted on the site. Also, we strongly recommend that you write Git-preferred commit messages, as they will really help you to review older commits in the future.

Also, there are some great tutorials and howtos out there, so check them out for more on day-to-day use of Git. Overall, you’ll want to commit in lots of small commits rather than one big final commit, so that you can easily go back and change things if you need to.

Oh, and don’t forget to add a note to CHANGES and commit that, too!

git add CHANGES
git commit -m 'Give credit where credit is you.'

When you’re done, the bug is fixed, and all tests pass, make sure everything is committed and then merge your changes back into master:

git checkout master
git merge 1449
git branch -d 1449

Great! You’ve merged all the changes from your branch, and dropped the branch since it’s no longer needed (all of the commits from the branch were played back into master, just as if you’d committed them there). Sure, for a simple bug fix you probably could have stayed in master. But with Git it’s just as easy to create a working branch for a single bug and work on it there, and only merge it back into master when you’re done, so that you keep things well compartmentalized.

So far, all of your changes have been made to your local clone of your repository. Now it’s time to push them upstream to your fork on GitHub. Doing so is easy:

git push origin master

Now your own fork has the changes on GitHub, free to be pulled in by anyone else who has cloned your fork. But your aim, of course, is to get the bug fix into the project repository. Chances are good that a project administrator will see your bug fix merges sooner or later and simply pull them in.

But if you’d like to alert them to the fix so that they pull it in sooner rather than later, hit the home page for your fork of the project and click the button. This will open up a lightbox window in which you can type up a message to the project administrators, perhaps something like:

Fellow Erliders,

I’ve fixed Bug #1449 in my fork. As you know, this is a particularly insidious bug that has effected a lot of our user base. I think it’d be worthwhile to pull it into the project repository in order to get it into the next release of erlide.

Thanks!

Be sure that the checkbox next to “erliders” is checked and then hit the “Send Pull Request” button. There, you’re done.

Thank you for your contribution, we greatly appreciate it. And we hope you enjoy hacking on erlide on GitHub.

This page is adapted from the pages written by David E. Wheeler for bricolage and is covered by a Creative Commons license. Thanks a lot!

Something went wrong with that request. Please try again.