Are your images original work or can they be recovered (guaranteed?) from elsewhere? Are they needed to ship a software unit built from source?
If they are original, they need backing up. Put them in your revision control, if they never change, the space penalty is the same as a backup, and they are where you need them.
Can they be edited to change the appearance of the software, accidentally or intentionally? Yes - then they MUST be revision controlled somehow, why use another way when you have a perfect solution already. Why introduce "copy and rename" version control from the dark ages?
I have seen an entire project's original artwork go "poof" when the graphics designer's MacBook hard drive died, all because someone, with infinite wisdom, decided that "binaries don't belong in rev control", and graphics designers (at least this one) don't tend to be good with backups.
Same applies to any and all binary files that fit the above criteria.
The only reason not to is disk space. I am afraid at $100/terabyte, that excuse is wearing a bit thin.
Your plan sounds great! I think you are off to a really good start.
My only advice is in regard to you Developer Workflow. I think you're dev
branch may become problematic, because developers will be merging code willy-nilly then they think its ready.
If both branchA and branchB, C, and D are merged into dev
, and it fails, you can't be certain which parts are necessarily failing. Also, if someone pushes up something with a conflict, you dont know who it was. Madness and insanity are bound to ensue.
If a feature turns out not to be ready, and code needs to be backed out of dev
, other developers will have already pulled down their additions. Those developers then will merge back into dev
, unwittingly re-introducing the broken code. Madness and insanity are bound to ensue.
You're going to need a couple steps of separation to keep untested code away from tested code.
This all depends on the skill sets of your team, and how you actually work together. What follows is my solution to problems of a quickly expanding team with differing levels of git knowledge and different levels of developers code dependability.
I always try to tell people to not simply think about developer workflow, but testing procedure, and release process. They all need to be planned as part of a singular process.
- Lead Dev or Release Mngr (whoever) creates a new
release
branch based off master
. This branch will be a container for anything going on it in the next release.
- Lead/ReleaseMngr creates
integration
branch based off release.
- Developer creates new feature branch (or topic branch, whatever you want to call it), based off the current release branch.
- Developer tests locally, is happy.
- The developers feature branch deployed somewhere and tested by QA independently of any untested code.
- QA signs off on feature - it gets merged into an
integration
branch. (ideally, IMHO, only after the feature branch has been rebased off release
, to force the conflict resolutions )
- QA tests the
integration
branch which is just the release
branch + this one feature.
- QA signs off - integration is merged into release (if not signed off, integration is blown away and recreated based on
release
). This is the reason for integration
. No one pulls form this branch, and it can be blown away as needed.
- Now the feature is in release, and can be shared with other developers making features based off
release
branch.
- Release is good, merge to master. Deploy, make a new release branch based off master.
I know it sounds like a lot, but it really will save you from the headaches and, in my experience, are inevitable with large projects with logs of people having differing levels of knowledge.
If you have a small team with a simple release process, or a team that is very experienced - all this may not be necessary - but do be aware of the inherent problem with testing multiple people's code at the same time in your dev
branch.
All that said, its my understanding the GitHub team just lets everyone merge into master directly (after a brief code review) and auto deploys ~30 times a day.
Best Answer
"It depends." For normal development tracking, no. For cloud and DevOps deployments, however, it's often convenient, or even required.
Most of the time, @ptyx is correct. Indeed, his "no" could be stated somewhat more emphatically. Something like "No. No! OMG NO!"
Why not store minified or compressed assets in source control system like Git?
They can be almost trivially regenerated by your build process on the fly from source code. Storing compressed assets is basically storing the same logical content twice. It violates the "don't repeat yourself" (aka DRY) principle.
A less philosophic but more practical reason is that minified / optimized assets have very poor compressibility when stored in Git. Source control systems work by recognizing the changes ("deltas") between different versions of each file stored. To do that, they "diff" the latest file with the previous version, and and use these deltas to avoid storing a complete copy of every version of the file. But the transformations made in the minify/optimize step often remove the similarities and waypoints the diff/delta algorithms use. The most trivial example is removing line breaks and other whitespace; the resulting asset is often just one long line. Many parts of the Web build process--tools like Babel, UglifyJS, Browserify, Less, and Sass/SCSS--aggressively transform assets. Their output is perturbable; small input changes can lead to major changes in output. As a result, the diff-algorithm will often believe it sees almost an entirely different file every time. Your repositories will grow more quickly as a result. Your disks may be large enough and your networks fast enough that isn't a massive concern, especially if there were a value to storing the minified/optimized assets twice--though based on point 1, the extra copies may be just 100% pointless bloat.
There is a major exception to this, however: DevOps / cloud deployments. A number of cloud vendors and DevOps teams use Git and similar not just to track development updates, but also to actively deploy their applications and assets to test and production servers. In this role, Git's ability to efficiently determine "what files changed?" is as important as its more granular ability to determine "what changed within each file?" If Git has to do a nearly full file copy for minified/optimized assets, that takes a little longer than it otherwise would, but no big deal since it's still doing excellent work helping avoiding a copy of "every file in the project" on each deploy cycle.
If you're using Git as a deployment engine, storing minified/optimized assets in Git may switch from "no!" to desirable. Indeed, it may be required, say if you lack robust build / post-processing opportunities on the servers / services to which you deploy. (How to segment development and deployment assets in that case is a separate can of worms. For now, it suffices to know it can be managed several ways, including with a single unified repository, multiple branches, subrepositories, or even multiple overlapping repositories.)