Embedded Files
Certainly, all programmers and software developers alike are familiar with the open-source distributed version-control system known as Git. It allows changes in any set of files to be tracked easily, and, although it was originally designed for coordinating work on source code, it can be used on different file formats.
It has appeared in 2005 and its share of users keeps increasing even nowadays. Its architecture, allowing extremely fast – nearly all operations are performed locally, saving the need to communicate with a server and it is written in C - and flexible workflows -with branching and merging operations that can be performed within seconds -, stands out clearly from its competitors; and, being open-source, it is constantly developing and being maintained. It has definitely earned the public appraise.
There are various Git interfaces, depending on the operating system in which it will be used. On Linux and OS X, Git bash is the standard interface, while on Windows, Git CMD is the most common – running on the command line, it uses the same commands as Git Bash. There are also different Graphical User Interface-software (GUI) aimed at users who prefer not to use the command line/bash, like Git Cola and Git for Windows, allowing changes to be made by pressing a button, instead of writing code.
Weighing in its importance, it is our purpose to provide the reader with some basic skills on Git. Hence, it is presented here a brief tutorial on its use: at first, it will focus on Git Bash, and, afterwards, an example of a GUI for Git will be introduced (Git Cola). After completion of the tutorial, the reader should be able to configure a Git Bash/Git Cola installation, to create a new repository or work with an already existing one and to commit, push and pull his own files to a repository.
Git Bash
Git Bash
As was previously mentioned, this first section will deal with the usage of Git Bash, both locally (offline) and remotely (online). The latter presents some very interesting properties and applications, however, in order to have a greater grasp on Git’s functionalities, starting with the local usage of this system is of the essence.
Local usage of Git Bash
Local usage of Git Bash
Configuration
Configuration
Being able to complete and customize Git Bash’s configuration is crucial for the proper use of the system. This can be made in the following levels:
· System level: configuration applies to all users;
· Global level: configuration applies to all the repositories for the current user;
· Local level: configuration applies to the current repository.
Note that, in this paper, most/all of the configurations required will be made at the global level.
As soon as you start using Git Bash it is necessary to define yourself as the user – that is, define your username and e-mail. To do so you should run the following commands:
· git config --global user.name “Your Username”: defines username as “Your username”
· git config --global user.email youremail@domain.com: defines email as “youremail@domain.com”
Note that, whenever the intent is to interact with or utilize Git’s functionalities through the command line there needs to be a way to call it; this is done be starting the command with “git” as is seen in the previous examples. The rest of the presented commands are quite self-explanatory and are written with a syntax similar to the one used in Linux/Unix terminals (with options being preceded by a dash (-) and long options preceded by a double dash (--)). It is also important to remember that, whenever one of the inputs to any of the used commands have spaces between words, as happened with the username, that input must be written in between double quotation marks.
Another useful step for a proper configuration is defining a default editor which will allow the user to read and write the current settings. Obviously, it is first needed to select witch one you might want to set as default; a widely used editor amongst Git users is VSCode (Visual Studio Code) which can be installed for free. The following command sets VSCode as the default creditors:
· git config –global core.editor “code --wait”
The long option “--wait” makes it so that no new commands can be implemented when you are utilizing your editor until the VSCode instance is closed. In case you decide another editor as default, check Git’s documentation for the correspondent input. Naturally, the next step is to be able to open your editor and check the current configurations or even add new ones. This is done with the following command:
· git config --global -e
There is one last important configuration to be made – defining the end of lines. Depending on the operating system you are running, the end of lines might be associated with both carriage return and line feed (\r\n), in the case of Windows, or simply a line feed (\n), in the case of Mac or Linux. This setup is made using the command:
· git config --global core.autocrlf true (on a Windows system);
· git config --global core.autocrlf input (in Linux/Unix based system).
Using repositories
Using repositories
With the configuration completed, the next step is to actually setup a Git repository. To do so you must first locate yourself in the desired directory. The following commands are of use to complete this step:
· cd “directory path”: This command places you in directory you specified. In case you would like to move to the root directory the input “directory path” may be substituted with a tilde (~). You may also substitute “directory path” with a minus sign (-) in case you want to move to the directory in which the current one is located.
· ls: This command lists the folders/files present in the current directory.
· mkdir “directory”: creates a new directory in the current directory.
· git init: Creates/initializes a repository in the current directory. If the process has be done correctly, you will notice that the denotation “master” appears in front of the current directory.
At this point in time, it is important to present three main entities:
· The working directory: the directory in which the repository has been initialized;
· The staging area: this area tracks changes in the files added to it.
· The repository: this is where the various versions of each file are stored.
The typical workflow using Git goes as follows:
A new file is created, for example using the echo command echo Hello World > file1.txt (this command writes “Hello World” in a new file named “file1.txt”)
Using the command git add file1.txt the new file is added to the staging area. This will allow changes made to the added file to be tracked. You may add more than one file/directory at a time to the staging area (git add file1.txt file2.txt) or even add all the files/directories in the working directory (git add .).
At any time, you may check the current status of the staging area using the command git status. By doing so, a list of all the files present in the working directory is shown with the status of each particular file being denoted both by color and text. For example, if file1.txt hasn’t yet been added to the staging area since its creation or since the last modification, its name will appear in red and Git will let you know whether the file is untracked, modified or whichever other status applies. On the other hand, the names of the files that have been properly added to the staging area will appear as green and, similarly to what was described before, a very short description of each file’s status is given.
It might also be of interest to remove a file from the staging area. This can be done with the following commands:
· rm “file to remove”: Removes a file from the working directory, if you check the staging area’s status at this point, git will let you know that the file has been deleted. However, the file deleted file is still in the staging area; in order to finalize its removal, you have to “refresh” its status by using the command git add “file to remove”
· git rm “file to remove”: automatically removes the file both from the working directory and staging area
· git rm --cached “file to remove”: Only removes file from staging area, leaving it intact in the working directory.
Note that, in case you want to remove a directory instead of a file, the presented commands must include the option -r.
The following are some interesting commands that involve the staging area as well as the working directory and commits area:
· git restore “file name”: Each file or directory in the working directory that is being tracked by the staging area is substituted by their respective latest “add”.
· git restore --staged “file name”: Substitutes the latest “add” of each file or directory by the respective latest commit. If for a certain file/directory no commit has yet been made, it will become untracked by the staging area.
· Git clean: Untracked files/directories are deleted from the working directory
Lastly, after properly reviewing the files you’ve added to the staging area, you may commit them using the command git commit -m “short message describing the modifications to the file”. In order to keep your previous version history for each file organized, it is quite important to take advantage of the possibility to associate a message or note with each commit (each time you store a new version). In fact, you may even want to write a bigger and more precise message, to do so use the previous command without the option -m. In this case, the default editor will open up and allow the message to be written. Typically, this type of longer message is made out of two parts (a small description and a bigger one, in this order) separated by a blank line. Note that it is possible to commit a file before adding it to the staging area, however, it’s highly advisable not to do so.
At this moment, it might be of interest to compare the latest staged version of a file/directory with the version in the working directory, or even comparing the version in the latest commit to the latest staged version of that same file/directory. In the first case, one may use the command git diff file/directory; in the second case, the option --staged must be added to the previous command.
We can also check the commit history as well as the author and date of each commit using the command git log or git log --oneline which condenses the most important information into one line. Each commit is given its own “serial number” which is displayed in yellow both in the full and one-line history list. This enables the user to reference a specific commit in commands like git show reference, in which the word reference shall be substituted with the actual reference number. This command shows the changes that were made in that particular version. The list returned by the command git log, with or without the option --oneline, shows commits from the most recent to the oldest, however, this order my be reversed using the option --reverse. Note that the first element of the shown list is denotated with the word “HEAD” which can also be used as reference for all the commits in the list (i.e. the commit right below the HEAD is referenced as HEAD~1, the next as HEAD~2 and so on).
It might also be of interest to check which files/directories were stored in a certain commit. The command that allows users to do so is git ls-tree reference, once again it is necessary to exchange the word reference for the actual reference of the commit.
Lastly, it is obviously very important to be able to restore a certain commit to the file/directory in the working directory. To do so use the command git restore --source=reference file/directory, in which the words reference and file or directory must be exchanged by the actual commit reference and file/directory name.
Remote usage of Git Bash
Remote usage of Git Bash
Creating Repository on Github
Creating Repository on Github
This step can be skipped if you are going to work on an already existing repository.
To work with Git Bash you need to have a Git Repository, or else is pointless to try and use Git Bash. Go to www.github.com, login with your username and password, and create a new repository.
For the sake of this tutorial we are going to use fictitious usernames and repositories. Our username will be JonhDoe123 and our repository "TestRepo".
First Steps
First Steps
Open Git Bash and place yourself on your working directory using the command cd (change directory):
cd /yourDirectory
Example:
cd /TestDirectory/example1
Once you are in your working directory, you will need to initiate your local directory as a git repository.
git init
Then, you want to associate your Git Repository with your local one. For this you will have to go to the github repository look for the repository URL. After that, use the following command:
git remote add origin "url"
Example:
git remote add origin https://github.com/JonhDoe123/TestRepo
If you are working on an already existing git repository you must clone it to your local repository.
git clone "url"
Example:
git clone https://github.com/ownerUsername/alreadyExistingRepo
Creating new files
Creating new files
Find the directory where you created your local repository and create a new .txt file, and give it a suitable name (e.g. tests.txt). Open the file and write something (e.g. Hello World).
On Git Bash, it might be of use to use the command status, as was mentioned in the previous section.
git status
If you've followed this tutorial correctly, after you've used the command above, your .txt file must appear on Git Bash in red, meaning it is still not staged for commit.
Commiting files to Git repository
Commiting files to Git repository
As mentioned on the local usage of Git Bash, before you can commit your files to the Git repository, you will have to stage the changes you want to commit, i.e you must add those files to the list of changes that will be sent to the cloud. For that, we will use the command add.
git add "name_of_file"
or
git add --all
The first command will stage the file with the name specified in the name_of_file field, whereas the second command will stage all changes at once.
Example:
git add tests.txt
To make sure everything is according to plan, you should now execute the status command again. This time, you can see that your file now shows up on Git Bash with green colors, meaning it is already staged and can be commited to the cloud.
Now you have to commit the changes and send them to the Git repository. This is divided in two steps. First you commit and then you push your commits to the cloud.
git commit -m "Commit Message"
git push origin "branch"
Example:
git commit -m "Commiting my first file tests.txt"
git push origin master
If you are working on a shared git repository you must pull the changes made by your colleagues before you push your changes.
git pull origin "branch"
If there are conflicts between the cloud changes and your local changes you will have to manually select which one will prevail, this is called merging.
As Git Bash, Git Cola relies on the same principles and functionalities, but it provides a GUI, instead of the command line. After having learnt the most important concepts with Git bash, Git Cola comes very intuitively, making Git advanced features simple and accessible.
Git Cola
Git Cola
1. Getting Started
1. Getting Started
Download Git Cola.
If you want to contribute to a Git repository, you can clone the project: click the "Clone" button (lower left of the Git Cola's oppening window) and paste the project URL. You can find your desired projects and their URL in your Git host. In this tutorial it will be used Git Hub.
Otherwise, click the"New" Button.
After creating/cloning a repository, there should be a new folder in your computer.
2. Modifying your project
2. Modifying your project
After getting your new folder, you can create new files in it. You can also modify already existing files.
It is recommended to use text based formats when working with Git Cola.
After making a change in your project, click "File" and then "Refresh". The Status panel will say "Untracked" and, below it, the name of the file(s) you've created/changed will appear.
3. Staging Files
3. Staging Files
At this point, you should mark the changes you want to register in the next code commit.
In the Status panel, right click on the file name and then click "Stage Selected". After that, the stage file will be marked with a green triangle next to its name.
If you've changed/created more than one file, you'll need to Stage Select each one you want to register in the commit.
If you've already clicked Stage Select and don't want to register that change, you can right click the file again and just press "Unstage Select"
4. Making a commit
4. Making a commit
Now you'll have to commit your staged changes. A commit represents the registed changes made throughout your project.
In the Commit panel, there are two text boxes: the "Commit summary" and the "Extended description...":
In the section "Commit summary" you should write a brief description about what was modified;
In the section "Extended description..." you should write a detailed description of the commit.
Both sections are visible in the repository's Git log.
Now you just need to click "Commit". After commiting, the Branches panel will be updated with your commit.
5. Publishing: Git Push
5. Publishing: Git Push
By this time, your Git project only exists in your computer. It's common for a Git repository to exist on a server accessible to others.
Firstly, you'll need to "store" your code to then send it to the Git Hub repository. You'll do that with a remote server.
To add/configurate a remote server go to "File", "edit remotes", "+", and then write a remote name and the repositories' URL.
Now you'll just need to push the commits to the repository: click "Actions" and then "Push" (or ctrl+P). Push only sends committed files to the server.
6. Useful Tips
6. Useful Tips
By clicking "File", on the top left of the application, you can set your preferences, like email and username. You don't need a global email to work with Git Cola, only when you push your changes to Git Hub.
When creating a new project, it's advised to end it with .git.
It's conventional for the first remote to be named origin.
When creating a new repository in your Git Host, there will be created a URL for the project.
Just like in Git bash, if you are working on a shared git repository and want to update your project to your colleagues' changes, you should go to "Actions" and click "Pull" (or ctrl + shift + P) before you push your changes.
When making a commit, you can Tag your changes to create versions. Click "Actions" and then "Add Tag".
To see your project history you should go to "View" and click "DAG". In the "Graph" section, each dot represents a commit.
A commit stays forever in Git's history, it can't be deleted. However, you can remove an already commited file by deleting it from your local folder and commiting the changes.
Just like in Git bash, if you are working on a shared git repository and want to update your project to your colleagues' changes, you should go to "Actions" and click "Pull" (or ctrl + shift + P) before you push your changes.
The tutorial has now been completed. By now, the reader should be familiar with the most basic concepts of working with Git software. The commands here presented are simple commands, but allow the reader to begin using Git and may be understood as an introduction to the more advanced functions, which, should they interesse the reader, can be further explored by consulting the references.
References:
https://www.geeksforgeeks.org/working-on-git-bash/
https://git-cola.github.io/
https://git-cola.readthedocs.io/en/latest/git-cola.html
https://git-scm.com/
Page updated
Report abuse