This a description of how to use the Github development philosophy in a software product development and the technical considerations.

1. USING GITHUB
DEVELOPMENT PROCESS IN
“(YOUR COMPANY HERE)”
By @adrian2112 & @edolopez from @icalialabs

2. Background
 Software development is hard.
 Agile methodologies available aren‟t enough.
 Lot of tests, lot of deals around.
 Constant problems with stakeholders, so let‟s make
this easy.
 Proposal: “How Github uses Github to build Github”

3.  Pull request
A simple discussion about code, feature and strategy.

5. How to use it?

6. Making pull requests
1: Updating remote branches and master on local
machine
(master) % git fetch
(master) % git pull origin master
** There shouldn’t be any conflicts. If so, your master has something bad, i.e. somebody forced a push
to master.
2: Make a new branch from master, commit changes
and upload to „Github|Bitbucket|*‟
(master) % git checkout –b new_branch
(new-branch) % git add .
(new-branch) % git commit -m "Algunos cambios"
(new-branch) % git push origin mi-nuevo-branch
** Now you or somebody can accept changes via github|bitbucket|*.

7. Additional: Obsolete branch, i.e. Github can not merge
as fast-forward or color status is different than green.
- Update remote branches on local machine
(new-branch) % git fetch
- Make interactive rebase in order to align local master
with remote master
(new-branch) % git rebase -i origin/master
(new-branch) % git push origin mi-nuevo-branch
** Now pull request should appear green and ready to push directly to master.

8. Github
_____________________________________________________________________________
Bitbucket

9. Approving pull requests
1: Update remote branches on local machine
(master) % git fetch
2: Open a local branch with branch interested for test
(master) % git checkout -b testable origin/testable

10. 3: Run specs and make sure it works
(testable) % bundle install; foreman start
4: Add notes and discuss on Github. Otherwise, if
everything‟s OK, merge pull request through Github

12. Issue tracker
 Everything inside a platform
 Centralizing efforts and attention
 Pull requests linked to issues (only on Github).

14. Pros & Cons
Pros Cons
 Time flexibility  Forcing pushes causes
 Distributed work conflict among people
 Master is always working same branch
deployable  Everyone can
 Encourages to constant push, everyone can
revision and work deploy
 No meetings  Team need to grasp
 All team involved the methodology
 Crucial changes don‟t
always follow this.

15. Thanks
http://icalialabs.com
@icalialabs
References:
- @rod_wilhelmy
- @holman http://zachholman.com/talk/how-
github-uses-github-to-build-github/