So, you're a new developer and you've decided that you want to be an open source contributor. Cool, this is probably one of the first times you'll work on a code base where the architecture is unfamiliar. It's a beautiful and mysterious world. You fork the repo, clone it down, install the dependencies, and then you're faced with your nemesis, Git. I know of a lot of developers and engineers who detest Git. For these people, when Git is coupled with GitHub; version control is a match made in hell. And yeah, it makes sense, the command line is a dark and scary place where you don't get a lot of a feedback, changes are permanent, and mistakes can be difficult to correct - the fear is real and well-founded. However, when Git and Github are leveraged effectively, these tools are an incredibly important part of web development. Working on an open source codebase can magnify Git risk and fears. Now if you make a mistake as a contributor, someone else might see them. The horror. Suddenly that, 'Must have 1-3 years experience with production code' requirement in that one dev job posting you saw last Tuesday makes a bit more sense, yeah? So, how can we foster good open source contribution and Git workflow practices?
Sure, you see an open source project, it's licensed under MIT, they have open issues, and some of them are even marked as 'small' or 'good first issue'. It's perfect. But, do they really want your help? You probably should check. Leave a comment on the issue you'd like to tackle, be professional and brief - then wait. In the meantime...
Most Git problems related to open source contributions are because a prospective contributor didn't read the documentation for the repository. Maybe the engineering team and maintainer want you to use interactive rebasing to squash your commits before submitting a pull request. It's true, but you'll never know because you didn't read the repo documentation. Is the documentation poorly written or incomplete? Were you unable to install the application when following their instructions? No? Cool, sounds like you just found your first open source contribution.
What's the testing like on the project you want to contribute to? Do they have any failing or skipped tests? They do! Document them, include those notes in your pr. There's nothing worse than finding a failing test when compiling your pr and wondering if the changes you made are responsible.
Similar to step 2, read the lint configuration file and run the linter on the project. Maybe the dev team is using tabs, maybe they're using spaces - if you guess wrong before you start working you're going to end up with hundreds of complaints. Yeah, I know what you're thinking, "that's what '--fix' is for!" Good luck buddy, there's been times where I've seen seasoned developers fail to get that command to work.
Maybe the project you're working on is in alpha or beta testing, but then again, maybe it's not. Either way. That shouldn't impact the quality of code you're writing - you should always be striving to write production level code. When familiarizing yourself with a new code base there's a good chance that you're going to have to chase a thread through multiple files. Suddenly, you look at your staged changes, and you see twenty files. Don't do that. This is a time to think of yourself as a weary traveler tiptoeing through the lion's den. Don't muck anything up. You'll just have to fix it later. Which brings me to my next point...
##Step 5. Don't 'git add .' I see developers flippantly add all of their staged changes all the time, and suddenly you have a commit that includes 1643 files changed and thousands of insertions and deletions. That might be hyperbole, but the problem is very real. I usually refrain from making blanket statements, but just don't use 'git add .' - it typically makes your commit too large and reduces the effectiveness of your commit messages (which you should always include. Gary.). Anyway, when you're contributing to someone else' project, you shouldn't be making changes that aren't absolutely necessary, so commit your files individually and keep track of the edits you've made.
Version control is helpful because it creates a roadmap of the changes you've made, similar to leaving breadcrumbs so you can navigate yourself out of the forest. When you couple frequent commits with descriptive and informative commit messages, you can look back at your process to see what you did and why. Code comments can also be helpful to this end, just be sure that you remove them when it's time to assemble your pr.
If you've made two unrelated changes in a file, it be might be a good opportunity to explore 'git add --patch'. This command allows you to stage 'hunks' of code independently. This is a good option to make commits more atomic and semantic.
If you're working on your open source contribution alone, you still should have someone reviewing your contribution, and you shouldn't but that burden solely on the project's authors or maintainers. Create a feature of issue branch on your forked repository, submit those changes to your forked version's master branch, and request a review.
This really ties into step one, but when you've done the thing, made the change, reach the top. Whatever. Make sure you assemble your pull request how the project authors/maintainers want you to.
Finally You have done everything you're supposed to, you submit your pull request, and... you don't get merged. What, wait? Yeah, unfortunately, you might do all this work and come out without a contribution to show for it. For better or worse, that's part of the deal, but practice these steps and you're chances of getting a change merged are much better.