Put blocks, views, etc in git for other developers Keep in mind that I'm fairly inexperienced with drupal!

I use a docker based setup for my development environment for docker 7. I'm building a site that involves a front page that will be changed infrequently but I still want the key users to change what's necessary.

I'm firing up the drupal docker with my_theme mapped to /var/www/sites/all/themes/my_theme and the following is executed in the docker container:

# Install zen theme (needed for the sub-theme)
/usr/local/bin/drush -r /var/www en zen -y
# Install base modules
/usr/local/bin/drush -r /var/www en views, entity, pathauto, devel_node_access, backup_migrate, imce, link_css, jquery_update, ckeditor, farmmix -y
# Set our theme as default
/usr/local/bin/drush -r /var/www vset theme_default farmmix
# Disable old theme
/usr/local/bin/drush -r /var/www dis bartik -y
# Enable/Install permissions
/usr/local/bin/drush -r /var/www en views_ui, entity_token, views_content, admin_devel, color, contextual, dashboard, field_ui, file, image, list, locale, number, options, overlay, search, shortcut, taxonomy -y


This installs and enables the modules I need for development. What this does NOT do is create content types, blocks, views, etc that might be necessary for this site. 

It would be ridiculous to recreate these essentials for the site each time a new instance is spun up (e.g: another developer starts to work on it). How can I put content types, blocks, views etc in git so if another developer checks it out, he can continue where I just left off? 

Only backup and migrate helps?
You have several modules that allow to export configuration changes (like views, blocks, content types etc) into code. One is features and the other is configuration Features is much more heavily used and configuration isn't supported by the security team, so I tend to use Features. There are a number of good tutorials on using Features, like this one. Once you create a feature, it will exported into a code-based collection of files under custom modules, which you can then share with git. 

The one caveat is that using Features (or any config changes module for that matter) in a collaborative environment can become tricky: team members have to be mindful of the branches and feature versions they are working with. For example, switching from a branch where feature was installed to a branch that does not have that feature can throw fatal errors because GIT will remove the feature files according to the branch but the database will still look for the feature. In such a case you can disable the feature before switching branches or install the feature in all the branches you are working in.