one. Routine usage

Equally mentioned in the outset chapter, there are three conceptual areas in Git: the development area, the staging area and the commit repository. The routine usage is depicted in the effigy below. When we want to save a file from the development area on our computer to the commit repository, we'll always have to add together information technology to the staging expanse get-go, before nosotros tin can commit information technology. The usual routine looks like this:

These commands will subsequently add the file <file> to the staging expanse and and so commit it to the commit repository. If we wouldn't pass forth the -m-message parameter, Git would have opened the editor request to write the commit message there. It's skillful practice to write a short, merely powerful commit message that helps your future self to determine what has changed in this commit.

The final step is to take these commits, essentially representing the folder with all the committed files, and button them to GitHub. Uptil now we kept rail of our code locally on our computer. Why practise we desire to store this project and all of its files on GitHub? Imagine that you lose your computer at present, you've likewise lost your project (and all the files in it). A scrap less drastical, if you would only similar to testify your project to your colleagues or with the whole world, nosotros demand to publish it somewhere on the internet. And that is exactly what GitHub does for usa. Here's how it looks like (once everything is set) when we would use the appropriate commands on GitHub.

            git add <file> git commit -m "some text that explains what has changed" git push button

That'southward all you lot need to know: add together-commit-push 10 echo. This repetition represent 90% of how we interact with Git & GitHub.

Before we tin can kickoff calculation, committing and pushing, we have to start a version controlled project/repository. There are 2 ways of initializing a new Git repository which only has to be performed in one case right at the beginning:

  • Clone a GitHub repository (from GitHub): run across Section 2
  • Initialize Git on a folder on your computer: see Section four
    Both options volition work simply fine and it depends on your preferences or maybe the situation of the project which one is preferable. The first choice can be used if you're about to start a new projection, the second option can be used when you already have some files in a project which you at present want to start version controlling.

two. Create a new repository from GitHub

Become to your GitHub homepage and click on the '+' icon in the upper right corner and select 'New repository'. The following screen will pop up.

Nosotros already filled in a repository name and an optional description. You lot can choose to already publish your repository, all the same as this is a meaningless repository, we volition choose not to. When you're about to start a new projection, there are three things to consider:

  • For a new repository, information technology'southward a skilful exercise to initialize the repository with a README file. This file volition eventually include a (general) description about the project, what others can expect to observe in the project and how they can use information technology.
  • Adding an .ignore file is something we will cover afterwards, however for now it suffices to know that the .ignore file volition incorporate some code which tells git to exclude certain files from tracking and avoids uploading them to GitHub.
  • Adding a license makes sense when your projection becomes public. It defines under which license the content is fabricated available. More than information on licenses is available hither.

In our example, we will initialize the repository with a README file and click 'Create repository', which will so look like this:

This is the dwelling page of our GitHub repository. From hither we can already practise a lot, like changing or uploading files. We initialized a GitHub repository with a README file and we tin can see that we take only 1 file in this repository: a README.doc file. Past default the text in this README file is the title of the repository and the clarification that we created here higher up. Observe that it's a Markdown-file as we tin see by the .doctor extension, like to an ordinary text file on your computer with a .txt extension. Markdown is enriched text allowing us to create formatted text using plain-text. More than data related to markdown can be accessed from the Github guides here.

Now that we created the repository in GitHub, nosotros want to work on it on our computer. Therefore we demand to download it, i.east. nosotros have to clone information technology to our computer. Click on the green button 'Clone' and cull any of the options:

  • Clone: with https link or with SSH. This volition download the repository and all its contents, keeping the link to the GitHub repository.
  • Open with GitHub Desktop (this might be interesting for you at a later stage).
  • Download: volition download all of the contents in a zipped file, however loses the connection to the repository.

With the Git Fustigate (or Last), navigate with cd to the folder where you lot want to go on your project folder and type the following:

with <link> being the link from GitHub that will look something like this for SSH: git@github.com:username/repository-name.git. This command is but used once in the first and creates a new folder on your estimator with all the contents from GitHub (the README file).

Exercise i

Create a new GitHub repository, give information technology a name and initialize it with a README-file. Upload this file to the repository on GitHub. What is GitHub asking you to do? Which stage is omitted when uploading a file directly to GitHub?

Clone the repository to your computer. How many files are there in your local repository?

Solution

Click on upload files and drag the file into the screen. GitHub is asking to add a commit bulletin which defines the changes that you'll do to your repository. In this case nosotros'll add the very brief Upload R script message. Notice that there is no staging area when you upload a file directly on GitHub.

Click on 'Commit changes' and discover the 2 files: README.medico and example.R in your repository. Now, we can detect the clone link via the green 'Clone' push. In our Concluding we blazon the post-obit command to start using the repository locally on our figurer:

in which you alter <link> to the link that you copied from GitHub. There should exist two files in your local repository likewise.
On a Windows computer we have a folder that contains the post-obit files:

three. Our get-go commit

Our local copy (clone) of the GitHub repository is at present able to communicate with the GitHub repository. Every change inside this repository is traceable, whether it is a new file or changes to a file. When we make changes in our local repository (e.thou. create a new file), yous have to add together the file to the staging area showtime (git add together) and then commit it (git commit) before pushing it (git push) to GitHub.

3.1 Staging

Let's add a new file to our folder on our computer locally. Download this file and add together information technology in the folder where likewise the plot1.R file is located. Information technology contains some R lawmaking for plotting a new figure.

The first thing we will have to practise at present, is to stage the file into the staging area. Remember that this is an intermediate surface area before committing the file to the repository. In a next section nosotros volition acquire why this staging expanse can be useful.

At present we have two options, depending on the situation:

  1. git add <file> : will add together a specific file to the staging area
  2. git add . : will add all the changed or new files to the staging area

In this case, we can choose either of both options every bit we have simply added one file. As this is a new file, git add volition not just add it to the staging area, but information technology will besides tell Git that it needs to continue track of changes that happen in this file.

3.2 Committing

Our new file is now in the staging area, ready to be committed. For this, nosotros have to use the following command:

            git commit -m "some descriptive withal short message"

We added a parameter -m (message) to the command followed by a descriptive text. This text informs our futurity selves or our colleagues of what changes were done. In this case it could exist: "added plot2.R script". We make this message as explanatory as possible, yet as short as possible. Some tips and general best practices in writing commit messages are described in this link.

Question

Which of the post-obit commit messages would be most appropriate for a hypothetical commit made to our README.medico file?

  • "Update README file"
  • "Added line 'We use this repository as an example' to README.dr."
  • "Added purpose description to the README file"
Solution

One can fence on the appropriatness of commit letters every bit it is subjective. In this case however, the tertiary options seems near ideal. It'due south both not too generic and not too specific.

Question

What has happened after committing?

  • We saved a version of the file which is now visible on GitHub.com
  • We saved a version of the file which is now stored in our commit repository
Solution

Nosotros've been working locally uptil now and didn't push the commits to the GitHub repository, hence it's still in our commit repository.

Question

What would take happened if nosotros forgot most the message statement when committing a file (-m)

Solution

If the -k parameter was not added, git will launch a text editor and ask to write a message. Nosotros can not make a commit without providing a message.

3.iii Button commits to GitHub

Recall that when we added the first file on GitHub (exercise 1), it was immediately committed and showed up right away in the GitHub repository. When we change or add together files on our computer and commit them, GitHub doesn't know this yet. Hence, we have to practise one last step:

Have a wait in the GitHub repository and verify that the new file is now in our repository.

3.four Stage-commit-push

Nosotros've learned how to brand a GitHub repository, clone information technology to our computer, add a file, commit it and push information technology back to GitHub. This is everything you need to know for a routine usage of Git(Hub) on 1 of your projects. In society to grasp this concept a fleck better, we'll echo it past making changes on both files in the next exercise.

Exercise 2

Add a championship to both files ("# Title plot ane" and "# Title plot 2"). You tin cull how you do this: e.thousand. open the files in a text editor and add together the line on superlative of the file. Follow the routine steps to push button your changes to our GitHub repository, however to make it a bit more than difficult, y'all need to shop the changes of both files in separate commits.

Solution

After adding the titles, utilise the following commands

                  git add plot1.R git commit -thousand "Added a championship to plot1.R files" git add plot2.R git commit -thou "Added a title to plot2.R files" git push button

We first added the changes of plot1.R in the staging surface area, then we commit those changes in a given commit. Afterwards, we add together the changes of plot2.R in the staging expanse and subsequently commit them. Finally, we use push to push all the latest commits together towards GitHub.

three.v Commit all tracked files at once

One affair we oasis't really said until now is that Git actually keeps track of the changes that you make to files as before long every bit you have told Git to do so. The kickoff thing you have to do when y'all add together a new file, is to tell Git to keep rails of changes fabricated in this file. If you exercise not do this, Git will know that at that place is a new file, but it will classify it every bit untracked. Later on calculation information technology to the staging area a first time, it volition always keep track of the changes in this file.

On the premise that Git is already keeping track of the files, you tin can simply do git commit -a -g "some informative text" in which -a stands for add all changes in all files to the staging area and commit them at once.

iv. Create a new repository from your estimator

Equally discussed hither above, you tin can also create a Git repository from your estimator. This is peculiarly useful when we already have a project with a bunch of files which we now want to showtime version controlling. The first thing that we will practise is initialize Git on this binder. Alternatively, make a new folder which will contain the files of an imaginary project in instance you don't take one yet. In Git Bash (Windows) or in your Terminal (Mac, Linux), move to the project folder with cd and use the following control:

Unfortunately, it is non possible to create a GitHub repository from our computer. Hence, we need to open GitHub and create a new repository and Exercise NOT initialize it with a README.md, .gitignore or a license. It is of import that information technology is empty in the first. Nosotros can add those files after.

One time created, GitHub will seggest commands that you lot might desire to apply on the Terminal to push our kickoff changes to this GitHub repository.

Nosotros already initialized Git in our folder, so we can skip this step:

THe following steps basically ask us to commit our first changes. Given that we edited the README file:

            git add together README.doctor git commit -g "first commit"

Here comes the tricky part. We will learn about branches in Chapter five, however it suffises for now to understand that each branch carries a name and the default one is now called principal where information technology earlier was called master. The following command will overwrite the name of the branch to main.

Then, nosotros demand to link the repository on our calculator to the one on GitHub with:

            git remote add origin git@github.com:tmuylder/testtt.git

And finally push our commit to GitHub. The argument -u or --set-upstream will set the remote equally upstream (see later):

Question

What if we want to create a new folder inside the folder which we are using for version controlling? Do we need to initialize Git inside this subfolder equally well?

Solution

Information technology is of import to note that git init will proceed rail of all the subdirectories and their files that are in the folder. Thus, you don't need to create a git repository for each binder or subdirectory. Git repositories can interfere with each other if they are "nested": the outer repository volition try to version-control the inner repository. This will lead to errors.

Question

How can we know whether a folder is already initialized with Git, significant that we are already version controlling the project?

Solution

If we utilize ls -al we go a listing of all files and directories, including the subconscious ones. A .git folder is nowadays when the project is being version controlled. Git uses this special directory to store all the information about the projection like the history of all commits. If we ever delete the .git sub-directory, we will lose the project'due south history.

Another possibility is to use the git status command which results in fatal: not a git repository… if the projection is not existence version controlled.

Earlier starting with the next exercise we likewise desire to stress the importance of not uploading data to GitHub. It's good practice to accept links to data, withal not the data itself. GitHub is not your side by side deject storage instance.

Practice iii

Observe a folder on your estimator with some files that you lot want to version command, initialize Git on that binder and go far (privately) available on GitHub.

Solution

See the steps in Section 4.

5. The strength of the staging area

Now you're probably wondering why it'southward useful to have that many steps to save a file (add, commit, push). We will give a practical instance based on the figure below:

Imagine that you're working on a projection with multiple Python scripts and you're working on all of them. In this case your folder in your development area contains the files scriptA.py, scriptB.py and scriptC.py. The changes that you fabricated in script A and script C are somehow related, just script B is not. It's skilful practice to brand commits in which changes that are related to each other are bundled. Hence, in this case we want to make ane commit with the changes from file A and C. At present we can simply add scripts A and C to the staging expanse and commit it. The changes in script B will remain unsaved until we commit the changes in a separate commit.

Information technology'southward always better to have more commits; in instance you want to remove part of your work in a later phase, or y'all desire to start your piece of work again from a specific commit.

6. Pull

Imagine that you modify something in a file on GitHub, or upload a new file online via GitHub. We would want to include these changes or that file in the folder on our computer as well. For this we need to use the pull command to pull in the changes from GitHub.

Permit'southward get back to our repository on GitHub. Nosotros will brand a change in the repository on GitHub then pull these changes back into the repository on our computer (i.e. the project folder on our computer).

Click on the README.md file in the list of files and click the pencil icon on the upper right. The file will open in an editor mode and we tin can change the title from introduction-github to Introduction GitHub or we tin can add some more descriptive text. Note that a README file is by default a markdown-file. Markdown is a text file with lay-outing options. If yous haven't heard of it before, it's worth some further reading.

Save the changes by committing them as depicted here below:

GitHub is at present one commit alee of our local repository. Hence, we have to pull this commit into our local repository. We can practice this by using the following command:

Open the file README.md and cheque whether the changes take merged in.

Allow's go to the side by side session!