“How can I get experience, if now one will hire me so that I can get the experience?”
-Literally every new person in tech
I hear this a lot, and to a certain extent, it has some validity. It’s not easy to understand what you do not know. I’m reminded of the 1987 Michael J. Fox movie, “The Secret of My Success”, where a young guy graduates college and moves to the big city and goes through what seems like a hundred interviews. Every interview ends with,
“I’m sorry, but we are looking for someone with more experience.”
“I really like you, but you this position require 5 years experience.”
So what does Michael J Fox’s character do? He creates his own experience.
Yes, learning a new technology or programming can be tough. Add on top of that the difficulty in breaking into the field of software development when you have no actual experience working as a developer. But, it’s important to remember that companies aren’t looking for typists. If anyone can sit at a keyboard and type the program up, they could hire anyone to do the job. They are looking for thinkers, problem solvers, someone who is going to attack a problem from every angle until they find the solution. What better way to show them that you are one of those people, than to create your own experience of useful skills in preparation of landing that job?
One of the most talked about skills when learning any kind of software development is Git.
Now most people have learned the famous sequence of:
git add .
git status
git commit -m “this is my commit”
git push
These are really important, just like it’s really important to “Save Often”
Yes, these are very important to a developer, but the ability to understand the best ways to work through merge conflicts with other developers is something that would cause interviewers to perk up, look up from their screens, and take notice.
When working with a team, you are typically going to be working on different aspects of a project, but those are going to crossover and there are going to be times where you have conflicts when trying to merge your pull requests.
To begin, when divvying up the work on a project, and creating branches within Git, the immediate inclination is to have branches named ‘Jacob’, ‘Andy’, ‘Michael’. Resist this urge. If Andy is working on the index page, but there is a feature that Michael wants to add to it, Andy is going to pass this branch to Michael. Do we then rename the branch to Michael? Do we name it Andy-Michael? What then when Michael passes it back to Andy. It’s a better idea to name the branches after features. With a feature-based branch naming system, anyone can work on any feature and you can merge the pull requests together and work through the conflicts.
To do this:
First we need to identify to two relevant branches that we want to merge. Let’s call them ‘main’ and ‘feature-branch’. Sidenote:
Navigate to the VSCode terminal and do ‘git branch’. It is important to make sure that you have ‘main’ and ‘feature-branch’ downloaded locally. If you are missing one or both locally, you need to view the specific names with ‘git branch -r’. Then you will ‘git checkout branch-name’ for each branch that you are missing.
Run ‘git checkout main’ and then you run ‘git pull’. This will get the most recent remote version. Next, do this for ‘feature-branch’.
Run ‘git checkout feature-branch’ if you are not already on it. Now run ‘git merge main’. This is going to merge the current version of ‘main’ into your ‘feature-branch’.
Run ‘git status’. This will now show you where each of your merge conflicts are because say ‘both modified: filename’.
‘git status’ is something that you should use often in this process. It gets a little tricky when you are navigating in and out of branches, and ‘git status’ kind of acts like your navigator pointing you in the right direction by telling you where your issues still are. Don’t be afraid to run ‘git status’ often.
Now, while in VSCode, navigate to each merge conflict. ‘HEAD’ refers to the ‘feature-branch’. We merged ‘main’ into ‘feature-branch’. ‘feature-branch’ is the “current” branch, while ‘main’ is the “incoming” branch.
Each time you have a merge conflict, you are going to have to choose whether to accept current (‘feature-branch’), incoming (‘main’), or both. Now remember that if you choose both, you are going to have to alter your code with extra changes in order to be able to merge. This will take some extra work, but it can be done.
Once you have resolved all of the merge conflicts, return to our favorite ‘git status’ as a way to sanity check yourself. This will let you know if you are good to proceed.
Then we will run ‘git add .’
‘git commit -m “This is a message about my merge conflict commit”’
‘git status’ Because we still aren’t in the clear yet and ‘git status’ will let us know if there are any issues.
‘git push’ will update the remote version of ‘feature-branch’ in GitHub.
Navigate to the pull request in GitHub. The merge conflict should be automatically resolved.
Click the “Merge” button to merge ‘feature-branch’ into ‘main’.
Now in your terminal, run ‘git checkout main’ and run ‘git pull’ to get the latest, most recently updated version of ‘main’.
If you are anything like me, you hate losing your code, and you absolutely don’t want to lose someone else’s code. Take a little time and create a repository and throw some code in there, make some branches, make different changes to the branches and practice this process of merging them. Once you go through this process a couple times, you will feel much more comfortable resolving merge conflicts while working as a team.
In addition to being able to work through issues amongst your team’s projects, you also have an added skill that might set you apart from the other candidates in your next job interview.
Keep Learning
Big High Five Dev 