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

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

6. Overview
Git
repository
Maintainers
You
Open Source
project

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!

12. Sending commits to
community

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