Linus Torvalds created git in 2005 as a source control system for kernel development. Git uses a distributed model where any number of users can collaborate by making and sharing changes. The document suggests replacing the typical "bucket" metaphor for content management with a metaphor of a many-headed hydra to better capture how git tracks and manages changes by multiple contributors. It then provides instructions for installing git, making an edit to Mysti's sample repository, and pushing the change for her to review and merge into the master branch. The goal is to demonstrate git's basic workflow through hands-on practice.

1. Dumping the Bucket:
Making it Easy
Suggested Metaphors and Tactics
by Mysti Berry

2. Dumping the Bucket:
Making it Easier
Suggested Metaphors and Tactics
by Mysti Berry

3. Mysti is an expert technical writer.
She is not a Git expert.
She noticed how hard it is for writers,
who use myriad tools all the time, to
adapt to git--so many mysterious
mistakes!
It doesn’t have to as confusing as it
seems.

4. Today you’ll learn:
A way to think about git that helps
you avoid some problems.
A process that helps you avoid even
more problems.
The basic commands that you’ll use
all the time.
The difference between git and
GitHub.

5. Today you won’t learn:
• How to read those bubble/arrow
diagrams
• All the commands
• Deep architectural secrets

6. Who created git?
Linus Torvalds in 2005, while
coding a kernel.
Source control, but
not for content...
Tip
Git has a lot of
documentation.
Many people ask
questions, so use Google
early and often when
working with git, to find a
source that speaks to
you.

7. But doc is distributed, too!
We want co-workers, customers, anyone to
safely give us updates!
At large companies, a hundred people
may need to access the same content.
Your mileage may vary.
Tip
Developers can
contribute more to your
content if you use a tool
and a process they
understand.

8. What’s good about git?
● Fast and free and not bug-ridden
● Not much typing or clicking to get stuff done
● Easy to fix mistakes (no, really! It is! I’ll show you!)
● With a few simple rules, you can get back to writing:
○ Check status often
○ Follow regular process
○ Use log & history (and google) to fix problems

9. Worth the learning curve?

10. Making It Easier
➔ 1. Change your metaphor
➔ 2. Do it the same way every time!
➔ 3. Embrace your confusion
(Devs get confused too!)

11. 1. Kick the bucket
➔ The bucket metaphor doesn’t
work with git

12. Source Control = Bucket
Most technical writers and content management
or source control systems use a bucket
metaphor--here’s your bucket of stuff!
● Do what you want!
● Only other tech writers touch your files.
● Conflict resolutions are the exception!

13. Git Metaphor != Bucket
Git manages changes, not content.
● Strangers touch your files!!!
● Conflict resolution is common.
● You don’t know what’s going on
unless you ask git
You need a many-headed hydra map!

14. Concepts
Repo: A collection of files and the record of
changes
Clone: Copy repository from remote server
Master: “Known good copy” git creates
Branches: Create branches to manage changes
Remote/local: Local is your stuff in your branch,
remote is where you push your stuff.

15. 2. Always check
➔ Always check your current state
➔ Check history, log often
Suggestion: use git from the
command line for everything but
reviews until you really understand
it. Otherwise you may never
understand it.
Once you install git, look around…

16. git status: ALWAYS DO THIS FIRST!!!!!
git log: Always do this before doing something
fancy.
git fetch: update my branch with changes from
another branch, but don’t “bundle” them into
my set of changes
“Show me” commands

17. 3. Confusion
➔ Embrace git’s inconsistencies
git checkout -b my-new-branch
vs.
git branch -d my-new-branch
Even experienced developers don’t do
the fancy stuff without looking at the doc.

18. Check it out!
➔ Let’s look at my repo
➔ Make an edit
➔ Push the changes up for review
➔ Merge our changes into master

21. Git pull: put all changes in my branch
git checkout <branchname>: Move “into” one of
my branches
git checkout –b <branchname>: Create a new
branch
git commit: Bundle up these changes and
prepare to…
git push: Push my commit(s) to another branch
git rebase: take commits from this branch and
another branch and sort them all out
Action commands

22. 3. Try this
➔ Install git
➔ Make an edit
➔ Push the changes up for review
➔ The admin of the repo will merge
your changes (me!)

23. Install git and check
1. Install git.
2. Check the readme.txt for gotchas.
3. Find your terminal window.
4. Move to git directory.
5. Type git --version

24. Follow These Instructions to fork my repo
http://kbroman.org/github_tutorial/pages/fork.html
My repo is git://github.com/MystiAnne/TechCampClass.git
(github.com/MystiAnne/TechCampCLass

25. I’ll Respond!
If you get stuck, email
mysti.berry@mac.com
If you send me a pull request, I’ll
answer it!

26. thank you!