If you want one technical skill that every employer looks for, it's experience using source control. They specifically look for experience with:
- git, an application that you use to track and manage changes to code
- a remote cloud service that lets you store git repositories (repos) on the Internet for backup and easy access by your team and the client
Versions of git exist for Linux, Windows, and MacOS.
The most popular remote services are github, Bitbucket and GitLab. Numerous comparisons of the three exist. Be sure to look at recent comparisons, as services compete and change features frequently. Also, be skeptical of comparisons that come down strongly on one side, since all three services are good for different situations.
In my classes, I use github because it's very stable, easy to manage for classes, and private repositories are not a major requirement.
There are many tutorials on using Github.
Tips and Warnings
Use the command line to manage a git repository.
There are a number of graphical user interfaces for Git. My experience has been that (1) most git commands are not complicated enough to need that, and (2) when things do get complicated, the GUI can hide details you need to know.
The exception for me has been the Git push and pull commands in VS Code. I find that user interface promotes committing frequently and writing better commit messages.
Use .gitignore
There are many artifacts that modern programming platforms like React generate that should not be tracked in the repository. node_modules for example will contain thousands of files, none of which should be pushed to Github or elsewhere. .gitignore lists all the files that should not be tracked, i.e., not kept in the history of changes, and not pushed to a remote repository.
Tools like create-react-app will create a .gitignore file that will catch many cases, but there are also files and directories specific to your editor and packages such as Firebase that are best untracked. These needed to be added manually.
Keep your.gitignore file up to date. See
this list of .gitignore templates for things
to add.
Pull often.
Don't work with out of date code.
Branch briefly, push often.
Keep branches to a day or so. Otherwise, you will have integration problems at the worst possible time, when you're trying to deliver to the client or end users.
Never push untested code.
Break big scary changes into harmless little ones.
For example, adding the ability for users to have multiple email addresses by replacing an "email" column in the user table with a new "user email" table. This is a classic scary change to database structure that can break a lot of your code. But you can easily make the changes in a series of safe, non-disruptive, testable substeps, any one of which could be rolled back easily. Remember to pull often.
- Add the new table, but change no existing code, remove no columns. Run existing tests and push.
- Write code to copy data from existing column to new table. Still change no existing code or columns. Write tests to verify data matches. Run tests and push.
- Change existing code that updates existing column to also update new table. Run tests and push.
- Change existing code that reads existing column to instead read new table. Run tests and push.
- Drop existing column. Run tests and push.
For some more good tips, see Alyson La's 5 GitHub tips for new coders.