When developing a Drupal website some sort of code repository is a useful tool. Especially when developing with a team it's a must-have to streamline your workflow. And since GIT is the weapon of choice on Drupal.org we stick to that. (If it wasn't we should anyway, GIT rocks bigtime as a repo)
How to use GIT?
No need to describe that in length here, lots of quility info is available:
- What is GIT
- Install GIT server
- GIT commands
- Initialize GIT repository
- GIT client GUI's
- Using GIT with Drupal
I recommend using Gitflow if your project involves coding larger chuncks of custom functionality. Gitflow makes it easier to maintain seperate branches to develop seperately and merge later.
Git and features module
One of Drupal's "strongpoints" is that it stores almost all settings and data-model configurations in the database. This makes it chalenging to deploy all changes to a GIT repository, because not all changes are code. Think of views, contexts, menu's, content types etc.
Since a "feature" is generated code (and sometimes a lot of it), its hard to see what changes are made exactly by a fellow developer to judge what should be merged. This makes it hard to develop seperately and merge later.
Lets say you build a Drupal website with a news section. This news section includes building components like a contenttype, taxonomies, a view with a bunch of displays for showing news on several places and provide an XML feed. And some contexts to position the block-displays. Since it's one piece of functionality, it's common sense to export all these components in one feature. Now lets say the themer is changing some contenttype settings and some HTML wrappers in a view display for front-end purposes. If simultanously a backender is changing the XML view-display and introducing a new context they both make changes to the same feature. These changes can be litteraly mean hundreds of lines of PHP code, all auto-generated. You have to be a wizzard to merge this without breaking someting.
How to address this
- Make sure you separate features as much as possible, without loosing track of sane architecture. This can mean you may want to separate views too!
- Try to prevent changes to the same feature across multiple branches. This makes feature branches and GITFlow usage tricky. If you are making changes in multiple branches simultanously, do merge often, use cherrypicking if necesary.
- If you are really rudementary, try to make sure only one person at a time is making changes to a feature. This can only be done with team-agreements. Like, if branch "featurename_developername" exists no other teammembers should make changes to that feature.
Have other thougts about this? Let me know!