Over the course of my work in software development this semester, I've answered a lot of small questions that are frequently asked by beginners to web and applications development. Whilst these questions are relatively basic, they're the things you really NEED to know to get up and running, and very few people want to spend all day reading Stack Overflow articles, so I've written a few of the answers here in case they come in handy later on.

What even is Git?

Start with this (fairly intensive) tutorial. Set aside a chunk of time for this. Do it completely. In one sitting. Don't stop. Then read a bit more through the Atlassian guides on Git to understand it in a more holistic sense.

Once you've started to understand Git and use it on a few of your personal projects, read this for some "best practices" on how to work in a team on a Git project.

How do I complete a pull request that has a merge conflict, and how do I see the conflicts?


1. Make sure you've got all your work committed so far

2. Run:

git pull origin master

which will trigger a merge automatically of master into your branch (you should do this whenever someone else's pull req. gets merged into master to make sure you code doesn't deviate too far from master and fuck up).

If the merge can't be completed, it'll knock out a merge conflict error and ask you to fix the conflicts. It'll then list the files that have conflicts - these files will be edited to show the conflicts. Conflicts are marked in the files by a certain syntax I don't remember off the top of my head right now but you can look up a guide to conflict resolution if you want.

Then you commit and it'll auto resolve the conflict. You should generally do this before you make your pull request as well to make the approver's life far easier; you know the code best since you wrote it, after all.

What the hell is dependency injection?


Based on the idea that you should not write code in your objects that are directly involved in the instantiation of other objects; dependency injection reduces the 'coupling' of two objects by automagically pushing one into the other (usually through the use of a dependency injection tool that is instructed in instantiation).

A common example of this is AngularJS's module loading syntax, where you have a specification of what your object wants (usually an interface), preceded by a specification of the object that will implement all the methods in the aforementioned interface.
Whilst Javascript doesn't really have a formalised way of defining interfaces, interfaces are an easy way of thinking about why dependency injection is good. Interfaces hide what happens behind the scenes, but guarantees that a subset of behaviour - the behaviour you NEED - will be consistently available and return the things you want it to return, which is all your object should really be thinking about.

If this sort of stuff interests you, I highly recommend you look more into dependency injection; if you're doing software engineering of any sort, I insist you research it. Most modern software stacks expect familiarity with concepts like dependency injection.