SlideShare a Scribd company logo
A Git MVP Workflow
INTRO/PURPOSE
Getting a product out, especially for demo purposes, can be both exciting and stressinducing. When dealing with a team where more than one area of your codebase is being
worked on at once, the complexity of code management is something you don’t want existing
as a big deal, especially under a time crunch.
The following is a slightly opinionated Git-based workflow that helps you to manage your
project with a team without having to worry too much about the politics of code
management. There are good reference posts like A Successful Git Branching Model (http://
nvie.com/posts/a-successful-git-branching-model/) and the Git Branching and Merging guide
(http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging). This will
incorporate ideas from that while trying to keep things simple and let you focus on your work.
Note that the following model does the following:
• relies somewhat on being comfortable with the people you work with (that means physical access
or, at least, direct chat access)
• ignores automated testing setups (though doesn’t discount them — test if you can!)
• assumes that you are using the GitHub for Mac client. You can still follow the branching model if
you’re familiar with Git on the command line.

We’ll start with a quick intro on actually getting everyone on Github and starting a project
there.
NOTE: The following next couple of steps assumes that the project is being managed from a
personal account instead of Github Organizations.

GET EVERYONE ON GITHUB
Everyone on the team — designers, developers, business analysts, your barber, the mail man
— need to make sure they’re on Github. Get everyone’s Github names immediately, and email
it to everyone on the team in a list for reference.
For those that haven’t yet, make sure those on Github have their SSH keys added to their
accounts. Directions: https://help.github.com/articles/generating-ssh-keys
CREATE YOUR PROJECT
Come up with a name for your project to get started. Don’t worry, you can always change it
later. Invite everyone to the project as collaborators, which will allow them to contribute
directly to the project. Directions: https://help.github.com/articles/howdo-i-add-a-collaborator

TRACKING ISSUES
It’s important to track and assign issues to everyone working on the
project so that everyone has direction on how to contribute — this is true
for everyone involved in the project, even non-developers. Using the
issues section of your code repository in Github will help to keep track of
everything that’s going on and assign issues to people.
We won’t go over how to use the issue tracker here (it’s really easy!), but
Github has a great writeup on it – https://github.com/blog/831issues-2-0-the-next-generation.
For every new feature, bug, requested change, everyone on the team should use the issue
tracker to input issues into the system. When inputting issues, make sure to assign someone
to the issue so that they know to take a look at it. If you’re not sure who the issue should be
assigned to, create the issue and speak to your team the next time there’s a status meet up.

OWNERSHIP

Communication is a big factor in a successful team project. It’s good to have a general sense
of who currently “owns” what in the team. If one person is generally handling most of the
front-end issues, assign some of the HTML and CSS issues to that person so it’s easier to
prioritize or resource help if needed.

USING GIT
Download the GitHub Mac client — http://mac.github.com/. After installing and opening it,
walk through the setup, including signing in to your account. When complete, you should see
your account name on the left and all your Git repositories on the right. If the project is not yet
on computer, choose the project and choose “Clone to Computer”. After the project’s done
downloading, or if it’s already been downloaded, double-click it.
From here, you’ll be able to see everything about your project:
• History will show you all the changes that have been made to the project by
everyone on the team.
• Changes shows all the current changes that you’ve made to your code.
• Branches shows all the code branches you’ve made — refer to the branching
model in the next section.
• Settings allows you to configure the address of the repository and which files
you may want to ignore.

THE BRANCHING MODEL
DEVELOPMENT

data engine
finished
data engine

start

data controllers
finished
data controllers

Refine
issues +
conflicts

front-end
layout
JS interaction

finished
JS interaction
merge
current
Refine issues +
conflicts
finished
front-end layout

Refine
issues +
conflicts

MASTER
start
When you start a project, your code lives on the master branch. Keep this branch clean,
meaning don’t put unfinished or buggy pieces of code on there. The master branch is what
the public will see when code is released.
Right after the project is created, create a development branch. You can do this in GitHub for
Mac by going to the Branches section of your project, choosing a branch (in this case master)
and clicking the + button at the end of the branch description. Name the branch
development.
From here, the team can create branches from the development branch to work on different
features. The rule of thumb: if it’s a feature, issue, bug, or idea that you’re trying, branch it. As
much as possible, try not to commit directly to the development branch.

BRANCHING EXAMPLE

For example: if someone is working on adding a footer to the layout, create an issue for it in
GitHub — “Front-end layout - create footer.” Create a new branch from the development
branch and name it something similar. Even better, reference the issue number in the branch
name. (e.g. “create_footer-43”).

!
COMMITTING YOUR CODE

While you’re working on your code, make frequent commits to your code when you complete
either the entire issue you’re working on or parts of the issue you’re working on. Committing
broken code is frowned upon, so make sure what you’re committing doesn’t break the project
as much as possible.
The commits that you make should also stay in context to the issue you’re working on. If
you’re working on implementing a page footer, don’t include work on fixing issues with the
navigation bar if it’s irrelevant to working on the footer.
You can view all the changes you’ve made to your code in the Changes tab of your project.
Once you’re satisfied with your work and you want to commit, write a short description in the
Summary field (and a longer description if necessary in the Description field) and click
commit.
If you’re confident you’re finished with a feature, include “Fixed #(issue number)” somewhere
in the summary, preferably at the end. (e.g. “Implements the page footer. Fixes #23”). This will
automatically close the issue in GitHub. See more — https://help.github.com/articles/closing-
issues-via-commit-messages. When an issue is closed, whoever opened it will be notified. If
you were not the one who opened the issue, you may want to work with the person who
opened it to verify that the issue is addressed. The issue-opener may decide to re-open the
issue if the solution is needs additional attention.
Whenever you commit code, it stays on your computer until you sync your branch. Click the
button to Sync Branch in order to push your code up to the repository at GitHub.

PULL REQUESTS - GETTING YOUR CODE INTO THE
MAIN BRANCH
After you’re done committing your last piece of code for
your branch, head to the web interface for your project
at github.com. From the home screen of your project,
there’s a drop-down menu for branches. Choose the branch that you worked on, then click
the green button. This will create a pull request.
A pull request is a request to the team to look at the code you’ve done and test it out. If
everything looks fine, whoever has the authority to merge the code (this should be figured
out internally within the team) in can pull the code in to the original branch the code had
branched from. That is, if a feature branch called refactor had originated from the
development branch, then the code will be pulled in to the development branch.
After pulling the code in, there should be a button to delete the branch the code came from
(i.e. delete the refactor branch, in this case). Go ahead and delete the branch so that your
repository doesn’t fill with unneeded branches.

COME TOGETHER (OFTEN)
Set frequent internal milestones for merging in Pull Requests and testing the development
branch as often as possible. Every two or three days could do it, depending on the project and
the size of the team. This way, everyone can more or less stay on the same page.
If there is a feature branch that takes long to develop, but pull requests are being brought into
the development branch, be sure to merge the updated code from the development branch
often. You may run into conflicts, but this way you can fix your code in context of the most upto-date code work on the development branch. This will help to actively fix bugs and reduce
larger code conflicts.
When it is determined by the team that the development branch has a good number of
features, and that everything generally works, merge it into the master branch.

You can do this in GitHub for Mac by heading to the Branches tab and clicking Merge View.
Drag the branches into their positions with the branch that you want to merge into on the
right. When merging development into master, master would be on the right.

TEST, TEST, TEST
During the internal milestone period, make sure to test your project amongst the team and
continue to add new issues in GitHub as necessary.

More Related Content

What's hot

Legal Analytics Course - Class #4 - Github and RMarkdown Tutorial - Professor...
Legal Analytics Course - Class #4 - Github and RMarkdown Tutorial - Professor...Legal Analytics Course - Class #4 - Github and RMarkdown Tutorial - Professor...
Legal Analytics Course - Class #4 - Github and RMarkdown Tutorial - Professor...
Daniel Katz
 
Pain Driven Development by Alexandr Sugak
Pain Driven Development by Alexandr SugakPain Driven Development by Alexandr Sugak
Pain Driven Development by Alexandr Sugak
Sigma Software
 
One Click Deployment with Jenkins
One Click Deployment with JenkinsOne Click Deployment with Jenkins
One Click Deployment with Jenkins
Mayflower GmbH
 
Grails beginners workshop
Grails beginners workshopGrails beginners workshop
Grails beginners workshop
JacobAae
 
Paul Campbell — A Modern Approach to Third-Party Embedded Widgets (Turing Fes...
Paul Campbell — A Modern Approach to Third-Party Embedded Widgets (Turing Fes...Paul Campbell — A Modern Approach to Third-Party Embedded Widgets (Turing Fes...
Paul Campbell — A Modern Approach to Third-Party Embedded Widgets (Turing Fes...
Turing Fest
 
Using galen framework for automated cross browser layout testing
Using galen framework for automated cross browser layout testingUsing galen framework for automated cross browser layout testing
Using galen framework for automated cross browser layout testing
Sarah Elson
 
One click deployment with Jenkins - PHP Munich
One click deployment with Jenkins - PHP MunichOne click deployment with Jenkins - PHP Munich
One click deployment with Jenkins - PHP Munich
Mayflower GmbH
 
One Click Deployment with Jenkins - PHP Unconference 2011
One Click Deployment with Jenkins - PHP Unconference 2011One Click Deployment with Jenkins - PHP Unconference 2011
One Click Deployment with Jenkins - PHP Unconference 2011
Mayflower GmbH
 
Load webcam images with google’s blogger
Load webcam images with google’s bloggerLoad webcam images with google’s blogger
Load webcam images with google’s blogger
Key difference
 

What's hot (9)

Legal Analytics Course - Class #4 - Github and RMarkdown Tutorial - Professor...
Legal Analytics Course - Class #4 - Github and RMarkdown Tutorial - Professor...Legal Analytics Course - Class #4 - Github and RMarkdown Tutorial - Professor...
Legal Analytics Course - Class #4 - Github and RMarkdown Tutorial - Professor...
 
Pain Driven Development by Alexandr Sugak
Pain Driven Development by Alexandr SugakPain Driven Development by Alexandr Sugak
Pain Driven Development by Alexandr Sugak
 
One Click Deployment with Jenkins
One Click Deployment with JenkinsOne Click Deployment with Jenkins
One Click Deployment with Jenkins
 
Grails beginners workshop
Grails beginners workshopGrails beginners workshop
Grails beginners workshop
 
Paul Campbell — A Modern Approach to Third-Party Embedded Widgets (Turing Fes...
Paul Campbell — A Modern Approach to Third-Party Embedded Widgets (Turing Fes...Paul Campbell — A Modern Approach to Third-Party Embedded Widgets (Turing Fes...
Paul Campbell — A Modern Approach to Third-Party Embedded Widgets (Turing Fes...
 
Using galen framework for automated cross browser layout testing
Using galen framework for automated cross browser layout testingUsing galen framework for automated cross browser layout testing
Using galen framework for automated cross browser layout testing
 
One click deployment with Jenkins - PHP Munich
One click deployment with Jenkins - PHP MunichOne click deployment with Jenkins - PHP Munich
One click deployment with Jenkins - PHP Munich
 
One Click Deployment with Jenkins - PHP Unconference 2011
One Click Deployment with Jenkins - PHP Unconference 2011One Click Deployment with Jenkins - PHP Unconference 2011
One Click Deployment with Jenkins - PHP Unconference 2011
 
Load webcam images with google’s blogger
Load webcam images with google’s bloggerLoad webcam images with google’s blogger
Load webcam images with google’s blogger
 

Viewers also liked

Social Media in Government
Social Media in GovernmentSocial Media in Government
Social Media in Government
Burt Lum
 
Civic*Celerator Apps Walkthrough
Civic*Celerator Apps WalkthroughCivic*Celerator Apps Walkthrough
Civic*Celerator Apps Walkthrough
Burt Lum
 
Social Media Tools for Disasters
Social Media Tools for DisastersSocial Media Tools for Disasters
Social Media Tools for Disasters
Burt Lum
 
Campaign Spending Dataset Layouts
Campaign Spending Dataset LayoutsCampaign Spending Dataset Layouts
Campaign Spending Dataset Layouts
Burt Lum
 
Open Data 2015
Open Data 2015Open Data 2015
Open Data 2015
Burt Lum
 
Building community
Building communityBuilding community
Building community
Burt Lum
 
Bill 53 FD1
Bill 53 FD1Bill 53 FD1
Bill 53 FD1
Burt Lum
 
New Year 2014 Calendar
New Year 2014 CalendarNew Year 2014 Calendar
New Year 2014 Calendar
Burt Lum
 
Kahoolawe and the Makahiki Ceremony: The Healing of an Island
Kahoolawe and the Makahiki Ceremony: The Healing of an IslandKahoolawe and the Makahiki Ceremony: The Healing of an Island
Kahoolawe and the Makahiki Ceremony: The Healing of an Island
Burt Lum
 
KIRC Summer 2010 Newsletter
KIRC Summer 2010 NewsletterKIRC Summer 2010 Newsletter
KIRC Summer 2010 Newsletter
Burt Lum
 
How To Plant A Native Hawaiian Garden
How To Plant A Native Hawaiian GardenHow To Plant A Native Hawaiian Garden
How To Plant A Native Hawaiian Garden
Burt Lum
 
Top 20 Social Media Geeks
Top 20 Social Media GeeksTop 20 Social Media Geeks
Top 20 Social Media Geeks
Burt Lum
 
Open Data Apps
Open Data AppsOpen Data Apps
Open Data Apps
Burt Lum
 
Innovating in a hyper-connected world
Innovating in a hyper-connected worldInnovating in a hyper-connected world
Innovating in a hyper-connected world
Burt Lum
 
HBTF Broadband Update Oct09
HBTF Broadband Update Oct09HBTF Broadband Update Oct09
HBTF Broadband Update Oct09
Burt Lum
 
Data Journalism
Data JournalismData Journalism
Data Journalism
Burt Lum
 
Peace through Technology
Peace through TechnologyPeace through Technology
Peace through Technology
Burt Lum
 
Hawaii Open Data Bill
Hawaii Open Data BillHawaii Open Data Bill
Hawaii Open Data Bill
Burt Lum
 
Imagenes De Nuestra Infancia
Imagenes De Nuestra InfanciaImagenes De Nuestra Infancia
Imagenes De Nuestra Infancia
nachouman
 

Viewers also liked (19)

Social Media in Government
Social Media in GovernmentSocial Media in Government
Social Media in Government
 
Civic*Celerator Apps Walkthrough
Civic*Celerator Apps WalkthroughCivic*Celerator Apps Walkthrough
Civic*Celerator Apps Walkthrough
 
Social Media Tools for Disasters
Social Media Tools for DisastersSocial Media Tools for Disasters
Social Media Tools for Disasters
 
Campaign Spending Dataset Layouts
Campaign Spending Dataset LayoutsCampaign Spending Dataset Layouts
Campaign Spending Dataset Layouts
 
Open Data 2015
Open Data 2015Open Data 2015
Open Data 2015
 
Building community
Building communityBuilding community
Building community
 
Bill 53 FD1
Bill 53 FD1Bill 53 FD1
Bill 53 FD1
 
New Year 2014 Calendar
New Year 2014 CalendarNew Year 2014 Calendar
New Year 2014 Calendar
 
Kahoolawe and the Makahiki Ceremony: The Healing of an Island
Kahoolawe and the Makahiki Ceremony: The Healing of an IslandKahoolawe and the Makahiki Ceremony: The Healing of an Island
Kahoolawe and the Makahiki Ceremony: The Healing of an Island
 
KIRC Summer 2010 Newsletter
KIRC Summer 2010 NewsletterKIRC Summer 2010 Newsletter
KIRC Summer 2010 Newsletter
 
How To Plant A Native Hawaiian Garden
How To Plant A Native Hawaiian GardenHow To Plant A Native Hawaiian Garden
How To Plant A Native Hawaiian Garden
 
Top 20 Social Media Geeks
Top 20 Social Media GeeksTop 20 Social Media Geeks
Top 20 Social Media Geeks
 
Open Data Apps
Open Data AppsOpen Data Apps
Open Data Apps
 
Innovating in a hyper-connected world
Innovating in a hyper-connected worldInnovating in a hyper-connected world
Innovating in a hyper-connected world
 
HBTF Broadband Update Oct09
HBTF Broadband Update Oct09HBTF Broadband Update Oct09
HBTF Broadband Update Oct09
 
Data Journalism
Data JournalismData Journalism
Data Journalism
 
Peace through Technology
Peace through TechnologyPeace through Technology
Peace through Technology
 
Hawaii Open Data Bill
Hawaii Open Data BillHawaii Open Data Bill
Hawaii Open Data Bill
 
Imagenes De Nuestra Infancia
Imagenes De Nuestra InfanciaImagenes De Nuestra Infancia
Imagenes De Nuestra Infancia
 

Similar to A Git MVP Workflow

Introduction to Git (part 3)
Introduction to Git (part 3)Introduction to Git (part 3)
Introduction to Git (part 3)
Salvatore Cordiano
 
Contributing to Upstream Open Source Projects
Contributing to Upstream Open Source ProjectsContributing to Upstream Open Source Projects
Contributing to Upstream Open Source Projects
Scott Garman
 
Git best practices 2016
Git best practices 2016Git best practices 2016
Git best practices 2016
Otto Kekäläinen
 
Git Pull Requests
Git Pull RequestsGit Pull Requests
Git Pull Requests
Callon Campbell
 
Git Makes Me Angry Inside
Git Makes Me Angry InsideGit Makes Me Angry Inside
Git Makes Me Angry Inside
Emma Jane Hogbin Westby
 
Untangling4
Untangling4Untangling4
Untangling4
Derek Jacoby
 
Introduction to git and Github
Introduction to git and GithubIntroduction to git and Github
Introduction to git and Github
Wycliff1
 
[2015/2016] Collaborative software development with Git
[2015/2016] Collaborative software development with Git[2015/2016] Collaborative software development with Git
[2015/2016] Collaborative software development with Git
Ivano Malavolta
 
Introducing Git and git flow
Introducing Git and git flow Introducing Git and git flow
Introducing Git and git flow
Sebin Benjamin
 
E caregitpresentation
E caregitpresentationE caregitpresentation
E caregitpresentation
Rakesh Kumar Shardiwal
 
GitHub Integration for Orangescrum Cloud Released!
GitHub Integration for Orangescrum Cloud Released!GitHub Integration for Orangescrum Cloud Released!
GitHub Integration for Orangescrum Cloud Released!
Orangescrum
 
Autotools, Design Patterns and more
Autotools, Design Patterns and moreAutotools, Design Patterns and more
Autotools, Design Patterns and more
Vicente Bolea
 
Git & GitLab
Git & GitLabGit & GitLab
Git & GitLab
Gaurav Wable
 
Workshop on Git and GitHub
Workshop on Git and GitHubWorkshop on Git and GitHub
Workshop on Git and GitHub
DSCVSSUT
 
OpenStack Contribution Process
OpenStack Contribution ProcessOpenStack Contribution Process
OpenStack Contribution Process
openstackindia
 
Openstack contribution process
Openstack contribution processOpenstack contribution process
Openstack contribution process
Syed Armani
 
Git for work groups ironhack talk
Git for work groups ironhack talkGit for work groups ironhack talk
Git for work groups ironhack talk
Tiago Ameller
 
Hacktoberfest 2020 - Open source for beginners
Hacktoberfest 2020 - Open source for beginnersHacktoberfest 2020 - Open source for beginners
Hacktoberfest 2020 - Open source for beginners
DeepikaRana30
 
Technical Seminar Series: GIT Pull Requests Best Practices
Technical Seminar Series:  GIT Pull Requests Best PracticesTechnical Seminar Series:  GIT Pull Requests Best Practices
Technical Seminar Series: GIT Pull Requests Best Practices
Singsys Pte Ltd
 
Programming Sessions KU Leuven - Session 01
Programming Sessions KU Leuven - Session 01Programming Sessions KU Leuven - Session 01
Programming Sessions KU Leuven - Session 01
Rafael Camacho Dejay
 

Similar to A Git MVP Workflow (20)

Introduction to Git (part 3)
Introduction to Git (part 3)Introduction to Git (part 3)
Introduction to Git (part 3)
 
Contributing to Upstream Open Source Projects
Contributing to Upstream Open Source ProjectsContributing to Upstream Open Source Projects
Contributing to Upstream Open Source Projects
 
Git best practices 2016
Git best practices 2016Git best practices 2016
Git best practices 2016
 
Git Pull Requests
Git Pull RequestsGit Pull Requests
Git Pull Requests
 
Git Makes Me Angry Inside
Git Makes Me Angry InsideGit Makes Me Angry Inside
Git Makes Me Angry Inside
 
Untangling4
Untangling4Untangling4
Untangling4
 
Introduction to git and Github
Introduction to git and GithubIntroduction to git and Github
Introduction to git and Github
 
[2015/2016] Collaborative software development with Git
[2015/2016] Collaborative software development with Git[2015/2016] Collaborative software development with Git
[2015/2016] Collaborative software development with Git
 
Introducing Git and git flow
Introducing Git and git flow Introducing Git and git flow
Introducing Git and git flow
 
E caregitpresentation
E caregitpresentationE caregitpresentation
E caregitpresentation
 
GitHub Integration for Orangescrum Cloud Released!
GitHub Integration for Orangescrum Cloud Released!GitHub Integration for Orangescrum Cloud Released!
GitHub Integration for Orangescrum Cloud Released!
 
Autotools, Design Patterns and more
Autotools, Design Patterns and moreAutotools, Design Patterns and more
Autotools, Design Patterns and more
 
Git & GitLab
Git & GitLabGit & GitLab
Git & GitLab
 
Workshop on Git and GitHub
Workshop on Git and GitHubWorkshop on Git and GitHub
Workshop on Git and GitHub
 
OpenStack Contribution Process
OpenStack Contribution ProcessOpenStack Contribution Process
OpenStack Contribution Process
 
Openstack contribution process
Openstack contribution processOpenstack contribution process
Openstack contribution process
 
Git for work groups ironhack talk
Git for work groups ironhack talkGit for work groups ironhack talk
Git for work groups ironhack talk
 
Hacktoberfest 2020 - Open source for beginners
Hacktoberfest 2020 - Open source for beginnersHacktoberfest 2020 - Open source for beginners
Hacktoberfest 2020 - Open source for beginners
 
Technical Seminar Series: GIT Pull Requests Best Practices
Technical Seminar Series:  GIT Pull Requests Best PracticesTechnical Seminar Series:  GIT Pull Requests Best Practices
Technical Seminar Series: GIT Pull Requests Best Practices
 
Programming Sessions KU Leuven - Session 01
Programming Sessions KU Leuven - Session 01Programming Sessions KU Leuven - Session 01
Programming Sessions KU Leuven - Session 01
 

Recently uploaded

Poznań ACE event - 19.06.2024 Team 24 Wrapup slidedeck
Poznań ACE event - 19.06.2024 Team 24 Wrapup slidedeckPoznań ACE event - 19.06.2024 Team 24 Wrapup slidedeck
Poznań ACE event - 19.06.2024 Team 24 Wrapup slidedeck
FilipTomaszewski5
 
AI in the Workplace Reskilling, Upskilling, and Future Work.pptx
AI in the Workplace Reskilling, Upskilling, and Future Work.pptxAI in the Workplace Reskilling, Upskilling, and Future Work.pptx
AI in the Workplace Reskilling, Upskilling, and Future Work.pptx
Sunil Jagani
 
What is an RPA CoE? Session 2 – CoE Roles
What is an RPA CoE?  Session 2 – CoE RolesWhat is an RPA CoE?  Session 2 – CoE Roles
What is an RPA CoE? Session 2 – CoE Roles
DianaGray10
 
"Frontline Battles with DDoS: Best practices and Lessons Learned", Igor Ivaniuk
"Frontline Battles with DDoS: Best practices and Lessons Learned",  Igor Ivaniuk"Frontline Battles with DDoS: Best practices and Lessons Learned",  Igor Ivaniuk
"Frontline Battles with DDoS: Best practices and Lessons Learned", Igor Ivaniuk
Fwdays
 
AWS Certified Solutions Architect Associate (SAA-C03)
AWS Certified Solutions Architect Associate (SAA-C03)AWS Certified Solutions Architect Associate (SAA-C03)
AWS Certified Solutions Architect Associate (SAA-C03)
HarpalGohil4
 
Northern Engraving | Nameplate Manufacturing Process - 2024
Northern Engraving | Nameplate Manufacturing Process - 2024Northern Engraving | Nameplate Manufacturing Process - 2024
Northern Engraving | Nameplate Manufacturing Process - 2024
Northern Engraving
 
GlobalLogic Java Community Webinar #18 “How to Improve Web Application Perfor...
GlobalLogic Java Community Webinar #18 “How to Improve Web Application Perfor...GlobalLogic Java Community Webinar #18 “How to Improve Web Application Perfor...
GlobalLogic Java Community Webinar #18 “How to Improve Web Application Perfor...
GlobalLogic Ukraine
 
inQuba Webinar Mastering Customer Journey Management with Dr Graham Hill
inQuba Webinar Mastering Customer Journey Management with Dr Graham HillinQuba Webinar Mastering Customer Journey Management with Dr Graham Hill
inQuba Webinar Mastering Customer Journey Management with Dr Graham Hill
LizaNolte
 
"Choosing proper type of scaling", Olena Syrota
"Choosing proper type of scaling", Olena Syrota"Choosing proper type of scaling", Olena Syrota
"Choosing proper type of scaling", Olena Syrota
Fwdays
 
Biomedical Knowledge Graphs for Data Scientists and Bioinformaticians
Biomedical Knowledge Graphs for Data Scientists and BioinformaticiansBiomedical Knowledge Graphs for Data Scientists and Bioinformaticians
Biomedical Knowledge Graphs for Data Scientists and Bioinformaticians
Neo4j
 
Lee Barnes - Path to Becoming an Effective Test Automation Engineer.pdf
Lee Barnes - Path to Becoming an Effective Test Automation Engineer.pdfLee Barnes - Path to Becoming an Effective Test Automation Engineer.pdf
Lee Barnes - Path to Becoming an Effective Test Automation Engineer.pdf
leebarnesutopia
 
Mutation Testing for Task-Oriented Chatbots
Mutation Testing for Task-Oriented ChatbotsMutation Testing for Task-Oriented Chatbots
Mutation Testing for Task-Oriented Chatbots
Pablo Gómez Abajo
 
Leveraging the Graph for Clinical Trials and Standards
Leveraging the Graph for Clinical Trials and StandardsLeveraging the Graph for Clinical Trials and Standards
Leveraging the Graph for Clinical Trials and Standards
Neo4j
 
MySQL InnoDB Storage Engine: Deep Dive - Mydbops
MySQL InnoDB Storage Engine: Deep Dive - MydbopsMySQL InnoDB Storage Engine: Deep Dive - Mydbops
MySQL InnoDB Storage Engine: Deep Dive - Mydbops
Mydbops
 
A Deep Dive into ScyllaDB's Architecture
A Deep Dive into ScyllaDB's ArchitectureA Deep Dive into ScyllaDB's Architecture
A Deep Dive into ScyllaDB's Architecture
ScyllaDB
 
Y-Combinator seed pitch deck template PP
Y-Combinator seed pitch deck template PPY-Combinator seed pitch deck template PP
Y-Combinator seed pitch deck template PP
c5vrf27qcz
 
Demystifying Knowledge Management through Storytelling
Demystifying Knowledge Management through StorytellingDemystifying Knowledge Management through Storytelling
Demystifying Knowledge Management through Storytelling
Enterprise Knowledge
 
LF Energy Webinar: Carbon Data Specifications: Mechanisms to Improve Data Acc...
LF Energy Webinar: Carbon Data Specifications: Mechanisms to Improve Data Acc...LF Energy Webinar: Carbon Data Specifications: Mechanisms to Improve Data Acc...
LF Energy Webinar: Carbon Data Specifications: Mechanisms to Improve Data Acc...
DanBrown980551
 
"Scaling RAG Applications to serve millions of users", Kevin Goedecke
"Scaling RAG Applications to serve millions of users",  Kevin Goedecke"Scaling RAG Applications to serve millions of users",  Kevin Goedecke
"Scaling RAG Applications to serve millions of users", Kevin Goedecke
Fwdays
 
GraphRAG for LifeSciences Hands-On with the Clinical Knowledge Graph
GraphRAG for LifeSciences Hands-On with the Clinical Knowledge GraphGraphRAG for LifeSciences Hands-On with the Clinical Knowledge Graph
GraphRAG for LifeSciences Hands-On with the Clinical Knowledge Graph
Neo4j
 

Recently uploaded (20)

Poznań ACE event - 19.06.2024 Team 24 Wrapup slidedeck
Poznań ACE event - 19.06.2024 Team 24 Wrapup slidedeckPoznań ACE event - 19.06.2024 Team 24 Wrapup slidedeck
Poznań ACE event - 19.06.2024 Team 24 Wrapup slidedeck
 
AI in the Workplace Reskilling, Upskilling, and Future Work.pptx
AI in the Workplace Reskilling, Upskilling, and Future Work.pptxAI in the Workplace Reskilling, Upskilling, and Future Work.pptx
AI in the Workplace Reskilling, Upskilling, and Future Work.pptx
 
What is an RPA CoE? Session 2 – CoE Roles
What is an RPA CoE?  Session 2 – CoE RolesWhat is an RPA CoE?  Session 2 – CoE Roles
What is an RPA CoE? Session 2 – CoE Roles
 
"Frontline Battles with DDoS: Best practices and Lessons Learned", Igor Ivaniuk
"Frontline Battles with DDoS: Best practices and Lessons Learned",  Igor Ivaniuk"Frontline Battles with DDoS: Best practices and Lessons Learned",  Igor Ivaniuk
"Frontline Battles with DDoS: Best practices and Lessons Learned", Igor Ivaniuk
 
AWS Certified Solutions Architect Associate (SAA-C03)
AWS Certified Solutions Architect Associate (SAA-C03)AWS Certified Solutions Architect Associate (SAA-C03)
AWS Certified Solutions Architect Associate (SAA-C03)
 
Northern Engraving | Nameplate Manufacturing Process - 2024
Northern Engraving | Nameplate Manufacturing Process - 2024Northern Engraving | Nameplate Manufacturing Process - 2024
Northern Engraving | Nameplate Manufacturing Process - 2024
 
GlobalLogic Java Community Webinar #18 “How to Improve Web Application Perfor...
GlobalLogic Java Community Webinar #18 “How to Improve Web Application Perfor...GlobalLogic Java Community Webinar #18 “How to Improve Web Application Perfor...
GlobalLogic Java Community Webinar #18 “How to Improve Web Application Perfor...
 
inQuba Webinar Mastering Customer Journey Management with Dr Graham Hill
inQuba Webinar Mastering Customer Journey Management with Dr Graham HillinQuba Webinar Mastering Customer Journey Management with Dr Graham Hill
inQuba Webinar Mastering Customer Journey Management with Dr Graham Hill
 
"Choosing proper type of scaling", Olena Syrota
"Choosing proper type of scaling", Olena Syrota"Choosing proper type of scaling", Olena Syrota
"Choosing proper type of scaling", Olena Syrota
 
Biomedical Knowledge Graphs for Data Scientists and Bioinformaticians
Biomedical Knowledge Graphs for Data Scientists and BioinformaticiansBiomedical Knowledge Graphs for Data Scientists and Bioinformaticians
Biomedical Knowledge Graphs for Data Scientists and Bioinformaticians
 
Lee Barnes - Path to Becoming an Effective Test Automation Engineer.pdf
Lee Barnes - Path to Becoming an Effective Test Automation Engineer.pdfLee Barnes - Path to Becoming an Effective Test Automation Engineer.pdf
Lee Barnes - Path to Becoming an Effective Test Automation Engineer.pdf
 
Mutation Testing for Task-Oriented Chatbots
Mutation Testing for Task-Oriented ChatbotsMutation Testing for Task-Oriented Chatbots
Mutation Testing for Task-Oriented Chatbots
 
Leveraging the Graph for Clinical Trials and Standards
Leveraging the Graph for Clinical Trials and StandardsLeveraging the Graph for Clinical Trials and Standards
Leveraging the Graph for Clinical Trials and Standards
 
MySQL InnoDB Storage Engine: Deep Dive - Mydbops
MySQL InnoDB Storage Engine: Deep Dive - MydbopsMySQL InnoDB Storage Engine: Deep Dive - Mydbops
MySQL InnoDB Storage Engine: Deep Dive - Mydbops
 
A Deep Dive into ScyllaDB's Architecture
A Deep Dive into ScyllaDB's ArchitectureA Deep Dive into ScyllaDB's Architecture
A Deep Dive into ScyllaDB's Architecture
 
Y-Combinator seed pitch deck template PP
Y-Combinator seed pitch deck template PPY-Combinator seed pitch deck template PP
Y-Combinator seed pitch deck template PP
 
Demystifying Knowledge Management through Storytelling
Demystifying Knowledge Management through StorytellingDemystifying Knowledge Management through Storytelling
Demystifying Knowledge Management through Storytelling
 
LF Energy Webinar: Carbon Data Specifications: Mechanisms to Improve Data Acc...
LF Energy Webinar: Carbon Data Specifications: Mechanisms to Improve Data Acc...LF Energy Webinar: Carbon Data Specifications: Mechanisms to Improve Data Acc...
LF Energy Webinar: Carbon Data Specifications: Mechanisms to Improve Data Acc...
 
"Scaling RAG Applications to serve millions of users", Kevin Goedecke
"Scaling RAG Applications to serve millions of users",  Kevin Goedecke"Scaling RAG Applications to serve millions of users",  Kevin Goedecke
"Scaling RAG Applications to serve millions of users", Kevin Goedecke
 
GraphRAG for LifeSciences Hands-On with the Clinical Knowledge Graph
GraphRAG for LifeSciences Hands-On with the Clinical Knowledge GraphGraphRAG for LifeSciences Hands-On with the Clinical Knowledge Graph
GraphRAG for LifeSciences Hands-On with the Clinical Knowledge Graph
 

A Git MVP Workflow

  • 1. A Git MVP Workflow INTRO/PURPOSE Getting a product out, especially for demo purposes, can be both exciting and stressinducing. When dealing with a team where more than one area of your codebase is being worked on at once, the complexity of code management is something you don’t want existing as a big deal, especially under a time crunch. The following is a slightly opinionated Git-based workflow that helps you to manage your project with a team without having to worry too much about the politics of code management. There are good reference posts like A Successful Git Branching Model (http:// nvie.com/posts/a-successful-git-branching-model/) and the Git Branching and Merging guide (http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging). This will incorporate ideas from that while trying to keep things simple and let you focus on your work. Note that the following model does the following: • relies somewhat on being comfortable with the people you work with (that means physical access or, at least, direct chat access) • ignores automated testing setups (though doesn’t discount them — test if you can!) • assumes that you are using the GitHub for Mac client. You can still follow the branching model if you’re familiar with Git on the command line. We’ll start with a quick intro on actually getting everyone on Github and starting a project there. NOTE: The following next couple of steps assumes that the project is being managed from a personal account instead of Github Organizations. GET EVERYONE ON GITHUB Everyone on the team — designers, developers, business analysts, your barber, the mail man — need to make sure they’re on Github. Get everyone’s Github names immediately, and email it to everyone on the team in a list for reference. For those that haven’t yet, make sure those on Github have their SSH keys added to their accounts. Directions: https://help.github.com/articles/generating-ssh-keys
  • 2. CREATE YOUR PROJECT Come up with a name for your project to get started. Don’t worry, you can always change it later. Invite everyone to the project as collaborators, which will allow them to contribute directly to the project. Directions: https://help.github.com/articles/howdo-i-add-a-collaborator TRACKING ISSUES It’s important to track and assign issues to everyone working on the project so that everyone has direction on how to contribute — this is true for everyone involved in the project, even non-developers. Using the issues section of your code repository in Github will help to keep track of everything that’s going on and assign issues to people. We won’t go over how to use the issue tracker here (it’s really easy!), but Github has a great writeup on it – https://github.com/blog/831issues-2-0-the-next-generation. For every new feature, bug, requested change, everyone on the team should use the issue tracker to input issues into the system. When inputting issues, make sure to assign someone to the issue so that they know to take a look at it. If you’re not sure who the issue should be assigned to, create the issue and speak to your team the next time there’s a status meet up. OWNERSHIP Communication is a big factor in a successful team project. It’s good to have a general sense of who currently “owns” what in the team. If one person is generally handling most of the front-end issues, assign some of the HTML and CSS issues to that person so it’s easier to prioritize or resource help if needed. USING GIT Download the GitHub Mac client — http://mac.github.com/. After installing and opening it, walk through the setup, including signing in to your account. When complete, you should see your account name on the left and all your Git repositories on the right. If the project is not yet on computer, choose the project and choose “Clone to Computer”. After the project’s done downloading, or if it’s already been downloaded, double-click it.
  • 3. From here, you’ll be able to see everything about your project: • History will show you all the changes that have been made to the project by everyone on the team. • Changes shows all the current changes that you’ve made to your code. • Branches shows all the code branches you’ve made — refer to the branching model in the next section. • Settings allows you to configure the address of the repository and which files you may want to ignore. THE BRANCHING MODEL DEVELOPMENT data engine finished data engine start data controllers finished data controllers Refine issues + conflicts front-end layout JS interaction finished JS interaction merge current Refine issues + conflicts finished front-end layout Refine issues + conflicts MASTER start
  • 4. When you start a project, your code lives on the master branch. Keep this branch clean, meaning don’t put unfinished or buggy pieces of code on there. The master branch is what the public will see when code is released. Right after the project is created, create a development branch. You can do this in GitHub for Mac by going to the Branches section of your project, choosing a branch (in this case master) and clicking the + button at the end of the branch description. Name the branch development. From here, the team can create branches from the development branch to work on different features. The rule of thumb: if it’s a feature, issue, bug, or idea that you’re trying, branch it. As much as possible, try not to commit directly to the development branch. BRANCHING EXAMPLE For example: if someone is working on adding a footer to the layout, create an issue for it in GitHub — “Front-end layout - create footer.” Create a new branch from the development branch and name it something similar. Even better, reference the issue number in the branch name. (e.g. “create_footer-43”). !
  • 5. COMMITTING YOUR CODE While you’re working on your code, make frequent commits to your code when you complete either the entire issue you’re working on or parts of the issue you’re working on. Committing broken code is frowned upon, so make sure what you’re committing doesn’t break the project as much as possible. The commits that you make should also stay in context to the issue you’re working on. If you’re working on implementing a page footer, don’t include work on fixing issues with the navigation bar if it’s irrelevant to working on the footer. You can view all the changes you’ve made to your code in the Changes tab of your project. Once you’re satisfied with your work and you want to commit, write a short description in the Summary field (and a longer description if necessary in the Description field) and click commit. If you’re confident you’re finished with a feature, include “Fixed #(issue number)” somewhere in the summary, preferably at the end. (e.g. “Implements the page footer. Fixes #23”). This will automatically close the issue in GitHub. See more — https://help.github.com/articles/closing-
  • 6. issues-via-commit-messages. When an issue is closed, whoever opened it will be notified. If you were not the one who opened the issue, you may want to work with the person who opened it to verify that the issue is addressed. The issue-opener may decide to re-open the issue if the solution is needs additional attention. Whenever you commit code, it stays on your computer until you sync your branch. Click the button to Sync Branch in order to push your code up to the repository at GitHub. PULL REQUESTS - GETTING YOUR CODE INTO THE MAIN BRANCH After you’re done committing your last piece of code for your branch, head to the web interface for your project at github.com. From the home screen of your project, there’s a drop-down menu for branches. Choose the branch that you worked on, then click the green button. This will create a pull request. A pull request is a request to the team to look at the code you’ve done and test it out. If everything looks fine, whoever has the authority to merge the code (this should be figured out internally within the team) in can pull the code in to the original branch the code had branched from. That is, if a feature branch called refactor had originated from the development branch, then the code will be pulled in to the development branch. After pulling the code in, there should be a button to delete the branch the code came from (i.e. delete the refactor branch, in this case). Go ahead and delete the branch so that your repository doesn’t fill with unneeded branches. COME TOGETHER (OFTEN) Set frequent internal milestones for merging in Pull Requests and testing the development branch as often as possible. Every two or three days could do it, depending on the project and the size of the team. This way, everyone can more or less stay on the same page. If there is a feature branch that takes long to develop, but pull requests are being brought into the development branch, be sure to merge the updated code from the development branch often. You may run into conflicts, but this way you can fix your code in context of the most upto-date code work on the development branch. This will help to actively fix bugs and reduce larger code conflicts.
  • 7. When it is determined by the team that the development branch has a good number of features, and that everything generally works, merge it into the master branch. You can do this in GitHub for Mac by heading to the Branches tab and clicking Merge View. Drag the branches into their positions with the branch that you want to merge into on the right. When merging development into master, master would be on the right. TEST, TEST, TEST During the internal milestone period, make sure to test your project amongst the team and continue to add new issues in GitHub as necessary.