USING GITHUBDEVELOPMENT 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.
Making pull requests1: Updating remote branches and master on localmachine (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 changesand 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 mergeas 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 masterwith 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.
Approving pull requests1: Update remote branches on local machine (master) % git fetch2: 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 start4: Add notes and discuss on Github. Otherwise, ifeverything‟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 & ConsPros 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.