This document provides an introduction to using Git and version control. It explains the basic concepts and workflow of Git, including initializing and committing to a local repository, pushing changes to a remote repository, and using branches for features and releases. It also discusses how to manage Drupal configuration changes using features in Git.

1. Git Going w/ Git

2. Michael Potter
@hey__MP

3. So what is Git?

5. Why use version
control?

7. So why Git?

8. Top four reasons
Fast
Popular
Distributed
Branching!

9. So how does it work
exactly?

10. Basic Model
• There is a Git repo that lives on a server
• Developers can checkout the repo independently

11. What’s happening locally?
• Every dev can fetch or pull
down from the remote
repo
• Work on the files then add
them to the staging area
• Commit the staged files
locally
• Push the changes to the
remote repo

12. So how does it handle
workflow?

13. How about this for workflow?

14. We’ll get back to that
later…

15. Basic Commands

16. Initialize Repo
• git init

17. Add files to stage
• git add <filename or directory>

18. Commit to local repo
• git commit -m “<description>”

19. Push to the remote repo

20. Branching

21. Branching = Workflow
• Branching is a tool to build a workflow
• ‘Master’ is the only branch you start with
• You can have as many or as little as you want

22. Basic workflow

23. Average workflow

24. Advanced workflow

25. Git-flow

26. Feature branches
• Where the code is made
• Examples of feature branch:
• “Calendar”, “Twitter Widget”, “New Article field”
• Feature branch could have multiple branches of
of it (so meta)

27. Develop branch
• Completed features are tested
• Multiple features can be tested to see how they
impact each other
• Can be linked to a development server, often
named “integration server”

28. Release branches
• Collection of features that passed testing on the
develop branch
• Production ready code ready to be merged into
master
• Could be linked to a QA server

29. Hotfix
• The “Oh no” branch
• Branched directly off of master
• Once fixed, it’s merged up to master and down to
develop branch

30. Master
• The projects live code
• Only for merging!

31. Branching tips
• Break down your work into different features with
their own branch
• Minimize merge conflicts by not editing the same
file simultaneously with other developers

32. Lets talk Drupal!

33. Drupal config
• Drupal 8 configuration is stored in .yml files
• Drupal 7 configuration still lives in the database

34. So how are we supposed
to commit configuration
changes?

35. Features

37. Features workflow
• On your dev environment create a new “photo”
content type w/ three new fields and a “gallery”
view.
• Create a new feature called “mywebsite_photos”
and export the content type, fields, and view.
• Commit the new feature to your repo.
• Deploy the changes to the live site and enable the
feature.

38. Updating a feature
Lets say a change has been made, a new field has
been added to the content type and the view.
1. Re-export the feature (Protip: drush fu <feature_name>)
2. Deploy the change to the live site
3. Revert the feature on the live site
(Protip: drush fr <feature_name>)

39. Whoa, that’s cool…

40. How many features
should I have?
That’s up to you!

41. Features methodology #1
• News Section
• Courses Section
• Events Section
• Homepage
• Sitewide Defaults

42. Features methodology #2
• Content Types
• Context
• Field Bases
• Media Config
• Pathauto
• Rules
• Site config
• Taxonomy
• User Config
• Views
• XML Sitemap

43. Critical feature helpers
• Strongarm (drupal.org/strongarm)
• Diff (drupal.org/diff)
• Features Override (drupal.org/features_override)
• Drush!

44. Demo