Continuing from the previous guide
, I will demonstrate how to create a repository and manage it, apply changes to it, make certain files and folders exempt from tracking, and how to handle remote servers. In this guide, I will show you an example of such actions being performed by creating a very small website. I will also create a copy on a remote computer
that will be used as a backup in case the main repo is ever damaged, or lost.
For the sake of this guide, I will create a very basic webpage with a little styling. There will be three files to start with (index.html, dynamic.js, and style.css).
Once I have created the files I want to begin with, I will now run ‘git init’ to turn the current working directory into a git repository.
Next thing we need to do is register these files using ‘git add‘ so that git can start keeping tracks of their changes.
The files are ready to be committed using ‘git commit‘. Running this will bring up a text editor (be it nano, emacs, vim, or whatever is set in the configuration). This is to write some information about a particular commit. The message ideally should give a general idea of what was done to the project.
There is a short-hand method of adding modified files to be committed and committing. It is using ‘-a’ parameter to add all of the files not yet marked for commit.
The ‘-m’ parameter can be used to give a short commit message in the command instead of opening a text editor.
If ‘git commit‘ wants you to “Tell me who you are”, follow the instructions to setup the user for either all repositories (with the ‘–global’ parameter) or just for the current one (without ‘–global’). For the sake of this guide, just use your username and computer name in the parameters.
You can have git ignore certain files and folders in your copy of the repository that you would rather not have in the main repo. For example, you generally won’t want to include files that contain settings specific to your IDE. Android Studio is a good example of an IDE that has IDE specific configuration in files in your repo that you don’t want in another person’s copy. Fortunately, it takes care of such git ignore configurations for you.
What if you want to specify what files to ignore yourself? The solution is simple: create a file in whichever directory you want the files to be ignored called ‘.gitignore’ (it will be hidden), open a text editor to put in what you want to ignore.Note that this will only work on untracked files. To remove a file from being tracked, run ‘git rm –cached <file>…’.
Example of a .gitignore
A typical .gitignore file will specify a list of files and folders to ignore. Some of these can contain wildcards. These wildcards are often used to include, or exclude multiple files in as few lines as possible. The best example is the asterisk (*) to specify all matching. Other examples include escaping spaces (“\ “), hashes (used to begin a comment), and exclamation marks (used for negation). More information can be found in the Git documentation
You can have more than one place to store your repository using remote copies. One reason to use ‘git remote’ is to keep a backup of your repository. So that if your main location goes offline for whatever reason, be it maintenance or a fire, then you will have at least one backup. Yes, you can have more than one remote copy. Use ‘git remote -v’ to list all of the remote locations.
To add a remote location, use ‘git remote add <name> <url>’ to reference a location. You will need to make sure that a copy of your repository exists in said location before attempting to push changes there. You can push to an empty repository, but this will be covered in the next tutorial. To remove a location, run ‘git remote remove <name>’.
Before attempting to push any changes to a remote location, you must specify an upstream branch. Otherwise, it will complain that one is not set.
Run the command that it tells you to run and try again. You may also want to set the push.default value as well (see screenshot above).
You have created a brand new repository, filled it with files, and created a copy of it elsewhere. In the next guide, we will cover troubleshooting for certain situations like merge conflicts, and more.