Git for work groups and some advices from the real world How to avoid the git-tastrophe

1. Git for work groups
and some advices from
the real world
How to avoid the git-tastrophe
@tiagoameller
tiago.ameller@gmail.com
Ironhack talks

2. Do we really need a
version control system?

3. No, I don’t need that
I use DROPBOX!

4. A VCS is more than a code backup:
Centralized repository
Revisions history
Team management
Milestones
Branches for new (or experimental) features
Revise other developers code

5. VCS for a single developer?
Yes.

6. Do you can use Git with no defined
workflow?
No.

7. What’s is the best workflow for you
or your team?
There are some variables:
1. Complexity of your product
2. Size of your team
3. It’s an in production software or it’s not
released yet?

8. What do you need? (I)
Centralized repository.
Most popular:
● Github
○ Free for public repositories
● Bitbucket
○ Also free for private repositories

9. What do you need? (II)
Issue tracker.
There are many options. My advice is a pure issue
tracker, not a collaborative utility such Trello, Kanbanflow,
etc.
17 Bug and issue tracking systems:
http://mashable.com/2014/02/16/bug-tracking-apps/
We use Mantis: http://www.mantisbt.org/
In few years, you get thousands of issues

10. Features an Issue tracker should have
● Project oriented (multi project)
● Support for SCRUM
● Release numbering
● Roles for users
● Time tracking (estimate, remaining, done)
● Priority management
● Searching
● Logging
● Customization for, by example, integration with other in
house tools
● External interface for customers, to show them project
pace, let them to make comments, report problems …
But do not authorize them to create new issues!

11. What do you need? (III)
A project master person
1. Can be the Product Owner in SCRUM.
2. Revises all code before merging
3. Fixes all code conflicts
git diff is not enough, there are some utilities. We can use
them with git difftool and git mergetool
Meld
http://meld.sourceforge.net/install.html
p4merge
http://www.perforce.com
Diffmerge
http://www.sourcegear.com/diffmerge/

12. Let’s see a
feature based
workflow

13. Branches.
Master
● Tagged for every release version
● Is untouchable. Any change implies a new release
● Only project master can merge to it
devname-m<issue#>
● Every issue (new features or bug fixes) have is own branch. Prepended by
developer name: Example: victoria-m1234
In one developer team, just use m<issue#>
Staging or QA (quality assurance)
Optional in small projects
● Release candidates
● Used for testing or limited releases to a small group of users

14. Our goal is having an stable Master Branch in every
moment.
New features must be implemented in a separate branch.
This branch can be abandoned not affecting project stability.
Every developer must frequently pull from last stable branch
for starting a new issue:
Imagine issue “1234 Add new taxes calculation to intl.
invoices”
In Victoria’s computer ...

15. Day 2
… work on it …
git commit -am “WIP do calcs in cases a and b”
git push
Day 1
git pull origin master
git checkout -b victoria-m1234
… work on it …
git commit -am “WIP define new fields on tax calculation”
git push --set-upstream origin victoria-m1234
Day 3
… work on it … and finish!
git commit -am “1234 Add new taxes calculation to intl. invoices”
git push
Update issue tracker with incidences, time spent, etc regarding this issue.
Inform project manager (he gets informed by email from issue tracker)

16. In project’s manager computer … (BTW, he’s name is Sheldom)
git fetch origin
New branches created (victoria-m1234 and others)
git checkout staging
git merge sheldom # here are all issues done by all developers
git push origin
repeat with other developers branches and issues
Fix conflicts, if any
git checkout sheldom
git diff victoria-m1234 # seems good job
git merge victoria-m1234 # no conflicts Great!
git checkout staging
git merge sheldom

17. Variants:
● Merge locally your
issue branches and
just push to origin
your named branch
● Use rebase to
remove WIP
commits
● Use pull request
Approve and merge
code online
● Use tags for
releases
● Drop issue
branches after
merging

18. Advices
● Commit, commit and commit! (thanks, Nick)
● Before any commit (also the 4 am ones),
use git diff to revise your changes from last
commit or reference branch
● Write USEFUL commit messages
● Is better to create unnecessary branches
● Use stash for rapid change between
contexts
● The issue ID is your friend. Use it
everywhere: commit messages and
comments in code

19. Advices for issue tracking
● Be verbose: When writing a new issue, may
be you or another developer will work on it
weeks or months later. Then nobody will
remember why this issue was created
● Attach sample data, user emails, screen
shots, etc to your issues
● If it’s a bug, write how to reproduce it. Also
who reported it (end user?) Probably you’ll
need more info
● Every issue should have an estimated time
to completion. Compare with your actual
results. It’ll help to your team to make more

20. @tiagoameller
with great help from
@luislopezcamps
Thank you for your
attention