Contributing to open source using Git
1 like405 views
This document discusses contributing to open source projects using Git. It explains that contributing can help gain programming experience and build a resume while giving back to the community. The overview outlines that contributors commit code to their local Git repository and then send those commits to the project's maintainers and community through patches or pull requests. It provides checklists for testing, coding style and commit messages before sending code. Specifically, it details Linux's strict coding style and two main models - patches sent via email and pull requests on sites like GitHub, outlining their workflows and lifecycles for review and merging code changes.
Contributing to open source using Git
- 1. Contributing to open source using git Sameeh Jubran, Sameeh@daynix.com
- 2. Open Source
- 3. Why contribute to open source?
- 4. Why contribute to open source? ● Gain Programming Experience ● Give Back to the Community ● Build a Practical Resume
- 5. Overview
- 7. We did some commits now what? Now we need to send them to the community
- 8. Before sending commits to community
- 9. Before sending commits to community A checklist ● Coding style (tabs vs spaces) ● Testing ● Clear commit messages
- 10. Coding style - it is a big deal! ● In many open source projects such as Linux there are scripts that auto check the code and show error messages accordingly ● Code style include: ○ Indentation ○ Naming conventions: CamelCase, snake_case, strHungarianNotation ( IsEmpty, is_empty, bIsEmpty) ○ Brackets ○ Comments ( /* */ , // ) ○ Proper names ● You can find linux’s checkpatch script here: https://github.com/torvalds/linux/blob/master/scripts/checkpatch.pl
- 11. Coding style - it is a big deal! “Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.” This snippet was taken straight from the Linux kernel Coding style document, it can be found here: https://www.kernel.org/doc/Documentation/CodingStyle Please note that at Daynix we prefer spaces!
- 13. Two main models Patches Pull requests
- 14. Two main models Patches Pull requests In both models there is a main repository In both models there are maintainers which approve/reject changes to the repository
- 15. Patches
- 16. Patches - What are they? ● A patch is a small file that indicates what was changed in a repository ● Each commit is transformed into one patch using the git format-patch command
- 17. Patches ● Mainly uses mailing list ● Generated using “git format-patch” ● Sent using “git send-email”
- 18. Patches’ life cycle Set of commits Creating a patch/es Sending to mailing list Getting reviews Applying the patches
- 19. Patches - mailing list Mails in the Linux mailing list 6497 messages in one week! (8/11 - 15 /11)
- 20. Patches - mailing list
- 21. Patches - Example We have this commit
- 22. Patches - Example Create a patch out of it git format-patch
- 23. Patches - Example The Patch
- 24. Patches - Example Sending the patch git send-email
- 25. Pull requests - What are they? ● let you tell others about changes you've pushed to a GitHub repository. Once a pull request is sent, interested parties can review the set of changes, discuss potential modifications, and even push follow-up commits if necessary ● When you file a pull request, all you’re doing is requesting that another developer (the project maintainer) pulls a branch from your repository into their repository
- 26. Pull requests ● The repository needs to be accessible ( Can be a downside ) ● Generated and sent using “git request-pull” ● Github ( and other similar websites) mainly uses this methodology
- 27. Pull requests’ life cycle Set of commits Pull request Getting reviews Pulling the changes
- 28. Pull requests
- 29. Summary Patches ● Mainly uses mailing list ● Generated using “git format-patch” ● Sent using “git send-email” Pull requests ● The repository needs to be accessible ● Generated and sent using “request-pull” ● Github mainly uses this methodology
- 30. Q&A