USING GITHUB DEVELOPMENT PROCESS IN “(YOUR COMPANY HERE)”

By @adrian2112 & @edolopez from @icalialabs

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”

Pull request A simple discussion about code, feature

and strategy.

How to use it?

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|*.

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.

Bitbucket

Github

_____________________________________________________________________________

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

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

Issue tracker

Everything inside a platform Centralizing efforts and attention Pull requests linked to issues (only on

Github).

Pros & Cons

Time flexibility Distributed work Master is always

deployable Encourages to

constant revision and work

No meetings All team involved

Forcing pushes causes conflict among people working same branch

Everyone can push, everyone can deploy

Team need to grasp the methodology

Crucial changes don’t always follow this.

Pros Cons

http://icalialabs.com@icalialabs

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

Thanks