Practice 2: Git configuration, moving data on the repository
By the end of this practice, you will have:
- Configured your Git installation
- Created Git aliases
- Learned to create and clone repositories
- Learned to stage, reset, commit, remove files
Reminder: UNIX command line
In these practical sessions, you are encouraged to use Git Bash to run Git commands. Git Bash opens a command line window that allows you to interact with your Windows file system with UNIX commands. Here is a reminder on some of the commands that you might need in this course. If you can find your way around the file system of a computer using the UNIX command line already, feel free to skip this section.
PWD
PWD ("print working directory") shows you the path of the directory you are currently located in.
LS
LS ("list") shows the contents of the directory you are in, like dir in Windows command line.
To get more information, like last modified date and permissions for each file and directory, use the argument "l".
By default, hidden files and directories (with names starting with a period) are hidden. To show them, use the "a" argument.
Arguments are entered after the command, prefixed with a dash ("-"). So in order to show the full information about all the files, you can use:
$ ls -la
CD
CD ("change directory") moves you to another directory ("folder"). Use cd .. to go to the parent directory of the directory that you are in.
$ cd path/to/new/directory
MV
MV ("move") is used to move or rename a file. It takes the form:
$ mv oldname newname
As the result, the file "oldname" is moved to the location "newname".
CP
CP ("copy") copies a file to another location.
$ cp file newfile
RM
RM ("remove") is used to delete files. Note: it cannot delete directories, for this purpose use rmdir.
$ rm file
Configuring your Git
User credentials
In the last session, you already did some configuration - you added your name and e-mail address to the globa configuration file.
$ git config --global user.name "User Name"
Use the git config command to check that the global configuration still contains your name and e-mail address.
Editor
Another very important thing to configure in every Git installation is the default editor. Git will use this application to edit commit messages; hunks and more.
The default editor is configured by the core.editor variable. Modigfy your global (user-specific) configuration file either with a code editor or the git configure command to point to the executable of your editor of choice. For example, if you're using Microsoft Visual Studio Code, use code, the command-line tool that opens the editor. If you're using Atom, use the atom command in your core.editor. If you don't want to use an IDE/code editor, you can just use notepad to open the Windows Notepad.
For other code editing software, first try googling if it is being installed with a command line tool, e.g. "launch *editor* from windows command line". If not, find the main exe file of the application and use it's path in configuration.
Aliases
As demonstrated in lecture, aliases are very useful for people who use Git regularly. Find some useful aliases and add them to your global configuration file. Take inspiration from the examples shown on the lecture slides or search online. Make sure that you understand what commands the aliases are for and what they're used for.
Repository creation
In today's session, we will create a repository from the command line.
- Create a new directory (hint:
mkdir directory-name) and create a new BARE Git repository in it. Note the path of the repository (hint:pwd) - Clone that repository somewhere else on your computer. When cloning local repositories, you don't have to specify a domain name or IP address of the machine, just the path is enough.
- What remotes does the new repository have?
- Save the contents of your global configuration file in a file called
config.txt, stage and commit the file to the repository and push it to the remote. - We want to be able to back up the repository elsewhere. Log into your GitHub account and create a new repository. During repository creation, choose to include a .gitignore file for a programming language, development environment or framework you're familiar with.
- After the repository is created, look at the .gitignore file that was made for you. Try to research and understand why some files are being ignored when the language/framework you chose is used.
- Add the address of the repository as a new remote to your repository (hint:
git remote add remote_name remote_address). Name the new remote "github".
- What remotes does the repository have now?
- Push the contents of the repository to the "github" remote. You should get an error saying the remote repository has work that you do not have. Pull from the "github" remote, merge the changes and try to push again.
NOTE: if Git is giving you an error message about "refusing to merge unrelated histories", it is because we created the .gitignore file on the GitHub web interface and the config.txt on our own machine and now the two repositories (local and GitHub) have two separate initial states. To work around this, run git pull like this git pull --allow-unrelated-histories. This forces Git to attempt to merge the two repositories even if their beginning are different and in our case the merge works, because there is no conflict in files. Please don't remember that as a good fix to similar probolems, though, we will look into troubleshooting in a future lecture :)
- Edit config.txt - delete your name and add a short explanation about one of the files in your .gitignore to the end of the file (e.g. "__pycache__/ contains the bytecode of the compiled python program")
- Now assume we have two tasks - "remove name" and "explain file". Make a separate commit for each one. Use
git add -pto stage only the hunk that you need, make a commit and then repeat the process for the next task. You may need to split or edit hunks. - Push the changes to the GitHub repository.
- Use the
git rmcommand to remove config.txt, commit the changes and push them to GitHub