Embed Size (px)
DESCRIPTION
You are a clever and talented person. You create beautiful designs, or perhaps you can architect a system that even a cat could use. Your peers adore you. Your clients love you. But (until now) you haven't *&^#^ been able to make Git bend to your will. It makes you angry inside that you have to ask your co-worker, again, for that *&^#^ command to share your work. It's not you. It's Git. Promise. We'll kick off this session with an explanation of why Git is so freaking hard to learn. Then we'll flip the tables and make YOU (not Git) the centre of attention. You'll learn how to define, and sketch out how version control works, using terms and scenarios that make sense to you. Yup, sketch. On paper. (Tablets and other electronic devices will be allowed, as long as you promise not to get distracted choosing the perfect shade for rage.) To this diagram you'll layer on the common Git commands that are used regularly by efficient Git-using teams. It'll be the ultimate cheat sheet, and specific to your job. If you think this sounds complicated, it's not! Your fearless leader, Emma Jane, has been successfully teaching people how-to-tech for over a decade. She is well known for her non-technical metaphors which ease learners into complex, work-related topics that previously felt inaccessible. Yes, this is an introductory session. No, you don't have to have Git installed to attend. You don't even need to know where the command line is on your computer. Yes, you should attend if you've been embarrassed to ask team-mates what Git command you used three weeks ago to upload your work...just in case you're supposed to remember. If you're a super-human Git fanatic who is frustrated by people who don't just "git it", this session is also for you. You'll learn new ways to effectively communicate your ever-loving Git, and you may develop a deeper understanding of why your previous attempts to explain Git have failed.
Citation preview
25 September, 2013
GitMakes Me Angry Inside
1
Emma JaneDrupalize.Me
IRC: emmajane@emmajanehw
2
I’ve tried! I can’t learn this stuff.
3
It’s not your fault. Honest.The way we teach web stuff isn’t the way that you probably need to be exposed to the information in order to learn it.Blame the teachers, not yourself.Or maybe not blame but, be persistent when working to solve important and sticky problems.
Git was built for and by Linux kernel developers.
4
Quick show of hands: How many people will raise their hand when asked?Great.And how many people here are Linux kernel developers?
How we typically teach people how to tech has nothing to do with adult education best practices.
5
RTFM: read the manualHere are all the commands, here are all the options. Memorize everything, and figure out later how to apply the knowledge.
Adults learn best when they can be selfish.
6
Andragogy assumes the following about the design of learning: Adults have the need to know why they are learning something. Adults learn through doing.Adults are problem-solvers.Adults learn best when the subject is of immediate use.
“Please memorize all Git commands and use only rebasing when merging your work.”
No client ever
7
Your problem might sound like: My client keeps changing his mind, and but they don’t want to pay me to redo the work.Your problem doesn’t sound like: My client wants me to memorize all the parameters for using Git at the command line.
Start with the whole to solve real problems.
8
Define your real problem clearly.Learn how to use a tool to get your problem solved.Try solving the problem. Take notes about how smooth it was to solve your problem. Write recommendations to your future self on how you’d solve the problem in the future now that you know what you know.
Bloom’s Taxonomy
http://lb.cm/bt9
Agenda
• Sample team workflow
• Branch management strategies
• Q&A / therapy session
10
How do we make Git do that?
Git Shell, cross-platform
11
Your problems are 90% social.
12
What’s your role?
13
What are your tasks?
download work
create snapshot
share work
14
What’s your workflow?
15
Who’s on your code team?
Write down a list of all of the people on your code team. This list may include:
• developers
• designers
• project managers
• clients
16
Where do you fit in?
Maybe you do everything. Maybe you only do some things. Write a list of all the tasks you are actually responsible for. This might include:
• Writing code.
• Reviewing code.
• Pushing tested code to the server.
• Fixing broken code.
17
What are your tools and restraints?
Often there are other things we need to fit into our workflow. Create a third list of any tools and restraints you are aware of. This list might include:
• Version control software (we’ll always assume Git)
• Code hosting system (Bitbucket, GitHub, self-hosted)
• Server ecosystem (dev / staging / live)
• Code editors & integrated developer environments (vim, Dreamweaver, Sublime, PHPstorm)
• Automated testing systems or review “gates”
18
What’s your workflow?
With the team members identified, it’s time to sketch out how these people (ideally) work together.
19
Centralized workflow
20
Decentralized with human gatekeeper
21
Decentralized with automated gatekeeper
22
Sketch out your workflow
• Identify the roles on your team.
• Identify the relationships between the team members.
• Draw arrows to show how code flows between team members.
23
How will you manage your branches?
With the workflow described, it’s time to look at how the code will be segregated into different branches.
24
Popular strategies
• http://nvie.com/posts/a-successful-git-branching-model
• http://scottchacon.com/2011/08/31/github-flow.html
25
Work flow and branch management
26
Work flow and branch management
26
Work flow and branch management
peer review
26
Work flow and branch management
peer review
public / live server
26
Work flow and branch management
peer review
public / live server
26
Work flow and branch management
peer review
public / live server
dev / testing server
26
Work flow and branch management
peer review
public / live server
dev / testing server
master
master
master
26
Work flow and branch management
peer review
public / live server
dev / testing server
master
master
master
dev
dev
dev
26
Work flow and branch management
feature feature
hotfix feature
peer review
public / live server
dev / testing server
master
master
master
dev
dev
dev
26
Work flow and branch management
feature feature
hotfix feature
peer review
public / live server
dev / testing server
master
master
master
dev
dev
dev
26
Sketch out your branch management strategy
• Identify the roles on your team.
• Identify the relationships between the team members.
• Draw arrows to show how code flows between team members.
• Time: 10 minutes
27
Q&A + Git Therapy Session
28
29
THANK YOU!
WHAT DID YOU THINK?
Locate this session at the DrupalCon Prague website:
http://prague2013.drupal.org/schedule
Click the “Take the survey” link
29
Terminology: locations
origin
localrepository
index, cache, or stageworking tree
30
UpstreamOrigin: where you downloaded the code fromWorking copy: your local copyTrunk (aka main): The current, primary source for unchanged code.Head: the latest revision in the repository.
Upstream: Source Repository: the database of changes to your files.Server: the computer storing the repository.Client: The computer connecting to the repository.Working copy: Your local playground where changes are made.
Actions and tasks
31
You can make Git do what you want...now that you know what you want.
@emmajanehwhttp://drupalize.mehttp://developerworkflow.com/
32
