Gulp! It’s Git week!
It’s week 5!
(actually, it’s week 6 but I’ve had the flu and was unable to blog last weekend!)
To begin with, Git week felt like taking a break from the fortnight of JavaScript that we had just conquered. It was nice to be doing something with the command line and to learn about how we might approach a collaborative project.
We’d been using Github (a website that allows you to store development projects in online repositories) since day one to access resources for the course, but had yet to be introduced to the beautifully organised world of Git and version management.
Once again, I’m using this blog post as revision — so please correct me if I’ve got something wrong!
Git, init?
Git is a tool that automatically keeps track of changes in your coding project.
It’s used on the command line and allows you to revert back to a previous state if you totally f everything up. This means you have greater control over your code.
As someone who once accidentally moved her entire 90,000-word thesis to the recycle bin, and is therefore now crazy about backing up files in various places, I was ready for Git and its magical time-machine properties.
The basic idea is to take snapshots of your project at certain points in time — these are called commits.
Git tracks files automatically but won’t commit them — you have to do that yourself at regular intervals.
Here’s an example of some git commits for a PHP login system project I’ve been working on in week 6. You can see that when I run git status, it tells me that certain changes I’ve made to the files password-reset.php and register.php are ‘not staged for commit’.
If I were to run git add * (* means ‘all files’, but it’s probably better to type in names of individuals files here so that you don’t end up staging something you shouldn’t) it adds these files to a staging area where they can then be committed.
Running another git status will show that these files have been added.
Then I can commit them using the command git commit -m “a message to future me about what changes I’ve made”.
It’s important to include a useful message (and one without typos ffs!) so that if you need to revert back to a previous state, you can see what you were doing at each step. You can bring up a list of your commits by doing git log or git reflog.
Here’s a visual description of this process that our fab teacher, Oli, showed us. It really stuck in my head and helped a lot with my understanding of what was going on with Git:
You can see from the above that it is possible to bypass the staging area completely using git commit -am “comment”.
There’s a load of different commands that can be used with Git that I won’t go into here, but it is important to mention that you don’t want Git to track absolutely everything that you are doing, particularly if you have sensitive information (like security info) in your project. So you can create a .gitignore file that lists all the project files that you don’t want to track.
The best thing about Git is that if you go wrong somewhere it isn’t the end of the world — you can Marty McFly it back to a time when you weren’t such an idiot. Just have a look at how to resolve your issue on the brilliantly named, ‘Oh Shit, Git’ https://ohshitgit.com
Github
Once we had learnt how to use Git locally (i.e on our own computers) we moved on to Github.
Github is great for storing a collaborative project remotely so that it can be accessed by everyone. All of your version-managed work can be pushed to the remote repository using the command line.
Here’s how it works:
1. You all connect to the remote repo (git clone {repository URL} {new local folder name} is a good way to bring a shared repo down to your computer).
2. You make your changes to the project.
3. You add and commit them locally.
4. You git pull from the remote repo so that you have the most up-to-date version of the shared project
5. You git push your changes to the repository to update it
But it isn’t quite as simple as that.
Obviously, if you and a team of colleagues are all working on the same project and pushing your changes to Github — there are going to be conflicts where your changes overlap.
We learnt this the hard way when the whole class started using Github to make changes to a page and ended up with something that looked like this …
What a mess.
I barely got a look in with my changes because every time I tried to git push, the remote repo had been changed and I had to git pull again to keep up.
So that’s why our next project incorporated a feature branch workflow.
(It goes without saying that it helps if you get together face-to-face first to decide who will work on what … sometimes good-old-fashioned human contact is also the best answer.)
Feature Branch Workflow
If you aren’t using feature branches, then all your changes are being made on a master branch.
That’s like a trainee brain surgeon doing all her initial surgical practice on live subjects — potentially disastrous. Much better to go and practice on something less risky (*insert detached HEAD reference here*).
(a brief aside — when, out of morbid curiosity, I Googled ‘how do brain surgeons practice?’ I got this interesting article about the use of 3D models in neurosurgery … https://www.cnbc.com/2015/11/23/new-brain-surgery-innovation-practice-on-a-3-d-model.html)
Enter feature branches.
Feature branches allow you to work on the project files separately from the master, then merge your changes at a later date — preferably after another member of your team has checked them for conflicts.
By the end of the week, the word git was so etched into my brain that I accidentally called my team mates (whose real names are Kit and Jim) “Git” and “Git”.
N.b. avoid this in future.
Gulp
But the fun doesn’t end there.
You can also use a toolkit called Gulp in your development workflow.
Although initially hard to get your head round, Gulp is actually incredibly useful because it automates a lot of stuff that you certainly wouldn’t ever want to have to do manually — like minifying CSS files or uglifying JS files (both of these mean taking all the extraneous whitespace, letters, etc. out of the code and squishing it all together in a horrific looking mess that might cause your eyes to catch fire if you tried to make sense of it).
an uglified JS file
You have to install Gulp using JavaScript’s Node Package Manager (NPM). This creates a package.json file to which you can add other useful packages like Bootstrap or jQuery (for more see https://www.npmjs.com/).
Once installed, using npm install gulp in the command line, you need to create a gulpfile.js file (a JavaScript file) for your project where you will outline all of your Gulp tasks.
And so we are back to JavaScript again.
As you can see from the example below, Gulp tasks are like JS functions/methods and therefore use all the familiar syntax we learnt last week.
The examples below combine all the project’s other JavaScript files (Bootstrap, jQuery and popper) into one file called all.js and then uglify it into all.min.js. This tidies up space in your files to make your code as efficient and as manageable as possible.
You can also use Gulp to automatically combine those two tasks together.
And, further, you can use Gulp to ‘watch’ for any changes that you make to the JS files, then automatically update the all.js and the all.min.js respectively.
Phew.
It’s very easy to fall into the trap of recursion here.
I discovered this when I first attempted to combine and minify my JS files and ended up creating an all.min.js file, then an all.min.min.js, then an all.min.min.min.js, then an all.min.min.min.min.js … and so on until my MacBook’s fan started going nuts and I realised what was happening and cancelled it.
It’s good to learn the hard way.
Next week … PHP.
Originally published in November 2019 at https://www.tumblr.com.