Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Contributing to open
source using git
Sameeh Jubran, Sameeh@daynix.com
Open Source
Why contribute to open
source?
Why contribute to open source?
● Gain Programming Experience
● Give Back to the Community
● Build a Practical Resume
Overview
Overview
Git
repository
Maintainers
You
Open Source
project
We did some commits now
what?
Now we need to send them to the community
Before sending commits to
community
Before sending
commits to
community
A checklist
● Coding style (tabs vs spaces)
● Testing
● Clear commit messages
Coding style - it is a big deal!
● In many open source projects such as Linux there are scripts that auto
check the code a...
Coding style - it is a big deal!
“Tabs are 8 characters, and thus indentations are also 8 characters. There are
heretic mo...
Sending commits to
community
Two main models
Patches Pull requests
Two main models
Patches Pull requests
In both models there is a main repository
In both models there are maintainers which...
Patches
Patches - What are they?
● A patch is a small file that indicates what was changed in a repository
● Each commit is transf...
Patches
● Mainly uses mailing list
● Generated using “git format-patch”
● Sent using “git send-email”
Patches’ life cycle
Set of
commits
Creating a
patch/es
Sending to
mailing list
Getting
reviews
Applying the
patches
Patches - mailing list
Mails in the Linux mailing list
6497 messages in one week! (8/11 - 15 /11)
Patches - mailing list
Patches - Example
We have this commit
Patches - Example
Create a patch out of it
git format-patch
Patches - Example
The Patch
Patches - Example
Sending the patch
git send-email
Pull requests - What are
they?
● let you tell others about changes you've pushed to a GitHub repository. Once
a pull reque...
Pull requests
● The repository needs to be accessible ( Can be a downside )
● Generated and sent using “git request-pull”
...
Pull requests’ life cycle
Set of
commits
Pull request
Getting
reviews
Pulling the
changes
Pull requests
Summary
Patches
● Mainly uses mailing list
● Generated using “git
format-patch”
● Sent using “git send-email”
Pull request...
Q&A
Upcoming SlideShare
Loading in …5
×

Contributing to open source using Git

Contributing to open source using Git - lecture for Technion students by Sameeh Jubran.

  • Login to see the comments

  • Be the first to like this

Contributing to open source using Git

  1. 1. Contributing to open source using git Sameeh Jubran, Sameeh@daynix.com
  2. 2. Open Source
  3. 3. Why contribute to open source?
  4. 4. Why contribute to open source? ● Gain Programming Experience ● Give Back to the Community ● Build a Practical Resume
  5. 5. Overview
  6. 6. Overview Git repository Maintainers You Open Source project
  7. 7. We did some commits now what? Now we need to send them to the community
  8. 8. Before sending commits to community
  9. 9. Before sending commits to community A checklist ● Coding style (tabs vs spaces) ● Testing ● Clear commit messages
  10. 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. 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!
  12. 12. Sending commits to community
  13. 13. Two main models Patches Pull requests
  14. 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. 15. Patches
  16. 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. 17. Patches ● Mainly uses mailing list ● Generated using “git format-patch” ● Sent using “git send-email”
  18. 18. Patches’ life cycle Set of commits Creating a patch/es Sending to mailing list Getting reviews Applying the patches
  19. 19. Patches - mailing list Mails in the Linux mailing list 6497 messages in one week! (8/11 - 15 /11)
  20. 20. Patches - mailing list
  21. 21. Patches - Example We have this commit
  22. 22. Patches - Example Create a patch out of it git format-patch
  23. 23. Patches - Example The Patch
  24. 24. Patches - Example Sending the patch git send-email
  25. 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. 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. 27. Pull requests’ life cycle Set of commits Pull request Getting reviews Pulling the changes
  28. 28. Pull requests
  29. 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. 30. Q&A

×