Branching is one of the fundamental functions of Git. It allows code to be developed in a safe way (in terms of updating/editing/deleting) and allows more than one developer to work on different features at the same time without interfering with each other.
If we think of Git like a set of train tracks then it becomes easier to understand how it works. Each time you commit code to a branch it’s like making a station along a track. At any point another track can split from the current track and create it’s own set of stations and at any point a track can rejoin with another. Mostly the re-join is seamless and goes without a hitch, but on occasion it may be more complicated and require a human touch just to get things smoothed out. A branch does’t even need to ever rejoin. Now imagine that we have a branch that something goes horribly wrong on, or that we start heading off in one direction, only to find that ...
When you’re working on a project it’s vitally important to make sure that the work you are doing is backed up and saved as often as possible. Not only does this give the freedom to try out ideas easily without risking the sanity of a project, but it also allows you to roll-back unwanted changes and in the worst case recover deleted or overwritten files.
Version control works by making ‘restore points’ in our working history of a project so that we can step back and undo breakages or recover code that wasn’t useful at one point, but now is. It’s a life saver.
Another advantage of version control is the ability to branch a project and try new things, develop new features in parallel to other developers and all without risking losing or breaking the code in a project.
When you compare that to saving files with incremental version names or backing up folders before downloading from an FTP server, then you can see why developers use version control. It ...
Git is easy to get along with if you follow a few simple rules of thumb. Things can still go wrong, but they do so, it’s less often and when it does, it’ll usually less of a problem to fix!
Turning any project in to a Version controlled project is really simple and should be one of the first steps in any project workflow. By the time you realise that you need a version controlled file, it’s usually too late – whether you have accidentally overwritten a days worth of work on a file, or you deleted the wrong thing. Since it’s so easy to setup, there’s really no excuse not to. There are a few best practices and tips as well as a few gotchas to note along the way but don’t worry, I’ll be pointing them out.
We could use a GUI for setting up and managing our Git repos, but to make sure that you understand what’s going on behind the scenes we’re going to be using the command line for setting up the git repo this time.
We’re going to assume that you have an existing project that you want to turn into a Git repo. If you don’t then just create an ...
responsiveBreakpointJQ works by specifying the images that will show if the screen of the device is big enough. The data-XXX values are how the appropriate image is specified. If a screen is wider than the XXX value then that image is selected as the best one for the job.
<img src="small.jpg" data-480="medium.jpg" data-960="large.jpg" alt="Image Alt text" />
If you would like to read more then take a look at the responsiveBreakpointJQ project on github . If you feel you can make it better then be my guest :D
Download the jQuery Responsive Breakpoint Image Plugin from git hub to checkout the code: https://github.com/Designer023/responsiveBreakpointJQ