Git/GitHub tip No. 15: Follow friends
GitHub suggests that you follow GitHub employees "in a non-creepy way." You should also follow people from projects that interest you, and that might lead you to other projects that interest you. I followed dmethvin on GitHub -- but that's not creepy since we've worked together on and off since he was at PC Tech Journal, and now he's president of the jQuery Foundation.
Git/GitHub tip No. 16: Send pull requests
In tip No. 13, we talked about forking a GitHub repository. The way to get the upstream repository (the one you forked from to make yours) to incorporate some or all of your changes is to send them a pull request, following this guide.
Git/GitHub tip No. 17: Create and resolve issues
All software has bugs. Many software projects use a separate bug-tracking system, but some use the Issues feature in GitHub. You can be useful to a project by reporting an issue, and even more useful by solving one.
Git/GitHub tip No. 18: Write informative README pages
In tip No. 11, I sent you to the README page of jquery/jquery to find out about the project. Write good README pages for your projects, and you won't regret it.
README has been an established convention in software development since at least the 1960s, when I saw my first one printed out IN ALL CAPS on the green-and-white paper that was wrapping a stack of Hollerith cards intended to be run on an IBM 1640. I saw many more in the 1970s, on every conceivable media and operating system, when I worked on DEC minicomputers and large IBM mainframes. See also REAMDE.
Git/GitHub tip No. 19: Use Markdown
Early README files IN ALL CAPS were more than a little basic. The current standard for formatting README files is Markdown, specifically GitHub Flavored Markdown. I used to see README files in HTML, but the practice seems to be fading.
Git/GitHub tip No. 20: Convert your older repos to Git
Of all the tips I've listed, this one might be the hardest to implement, both technically and politically. Politically it's hard because programmers are by nature conservative about their tools. That needs to be addressed with training (see tip No. 5).
It's technically hard to convert big, old repositories with millions of lines of code, tens of thousands of commits, and thousands of tags because the processes for this use a metric ton of memory. I have had decade-old CVS repositories that would only convert on large or extralarge Amazon EC2 instances, and they still took days for the conversion to complete. If you're converting from Subversion, try using svn2git. If you're converting from CVS, consider
git -cvsimport and cvs2git.
- Pro Git book
- Git -- the simple guide
- GitHub help
- Get Started with Git
- GitHub for Beginners
- Git Immersion
- Git Community Book
- Git from the bottom up [PDF]
- Git Magic
- A Visual Git Reference
- Atlassian Git Tutorials
This article, "Git smart! 20 essential tips for Git and GitHub users," was originally published at InfoWorld.com. Follow the latest developments in application development and cloud computing at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.