Share
Embed
git in teams
Jenni Naiaretti presentation on how different teams use git to collaborate.
forLoop
July 16, 2016
Transcript
21 slides
-
why git? Maintain back ups Stage your growth Create versions
Remote access Neat experiments Multitask Mix and match Keep records -
centralised * git is a distributed vcs and encourages collaboration
One main upstream branch 1..* local branches Merges are paced -
feature branch Commits for a feature are in one branch
Branch naming convention {<feature-x> != developer-a} Master is official Parent node of every branch Branches stay in sync Merge when done Review finished work Spot drastic changes Delete after merging -
gitflow Feature + extra branching Production/stable branch master Development branch
dev Feature branches Release branches Hotfix branches -
MASTER BRANCH No direct pushes Tag all merges; annotate Update
master through release/hotfix branches DEV BRANCH master -> dev Stay in sync with master Should ideally be stable, cover with tests gitflow -
FEATURE BRANCHES Based off of dev NOT master master ->
dev <-> feature RELEASE BRANCH Test & fix bugs* Change log & Documentation Version product (tag number) master <- release <-> dev <-> feature gitflow -
HOTFIX BRANCH dev not ready but master can’t wait Create
from master master <-> hotfix -> release <-> dev <-> feature master <-> hotfix -> dev <-> feature gitflow -
Omnipresent repository Track upstream remote git remote add upstream repo.git
Git pull upstream stable/master My forked repo: me@host forking -
Pushes are restricted to project owner(s) Tag, you’re it! Share
one fork - third party project Multiple forks per member: in-house Dependency CI forking -
Merging Pull request <me@host feature> → <upstream stable/master> Upstream accepts
Fix conflicts and test locally Fetch <me@host feature> git merge FETCH_HEAD forking -
damage control • Pass the test • Grep • Ctrl+Z
• Bisect • Blame someone -
debugging Git is not God Test stable/master branch GREP Search
for a pattern View the file lines/name *Rollback a release or checkout a working revision -
the good, the bad, the broken BISECT Initiate a bisect
investigation Specify the bad and the good revisions Test manually or run a test script Locate where the problem was introduced git bisect start git bisect bad git bisect good [<rev>] git bisect reset -
it was working yesterday! You can blame CLI or Toolkits
shipped with git {gitk} Clients Git services It’s all in the setup Use coding conventions to avoid false accusations Understand before you change Who should merge -
security & access Don’t track sensitive info Team-defined standards Configurations:
personal + team defined rm is not enough Branch restriction/protection Alerts -
tips Init & update all submodules in repo Git clone
-- recursive repo.git See more detail by adding -p to most commands Stay on top of stashes with meaningful messages git add can/accept multiple.files *.twig git clean -n instead of rm-ing each file Git GUI Clients https://git-scm.com/download/gui/linux -
useful resources Cheat sheet: http://ndpsoftware.com/git-cheatsheet.html Damage control flowchart: http://justinhileman.info/article/git-pretty/git-pretty.png Getting
git right: https://www.atlassian.com/git/ GitHub git cheat sheet: https://services.github.com/kit/downloads/github-git-cheat-sheet.pdf GitHub help: https://help.github.com/ Git SCM: https://git-scm.com How to: https://githowto.com/setup How to use git & GitHub: https://www.udacity.com/course/how-to-use-git-and-github--ud775 Learn git on the browser: https://www.codeschool.com/courses/try-git