Git and GitHub Tutorial for Beginners (Part 2)

Programming GIT AND GITHUB SERIES Image

    In the last part, we had covered till Git and we had learnt about few Git terminologies. In this blog, we will  explore Github and important Git commands. 

    What is GitHub?

    GitHub is a platform that can be used to host code online. Think of GitHub as a platform that stores the whole codebase in a remote repository. It comes with tools to collaborate on projects of any size.

    By enabling the creation of remote repositories, GitHub allows developers to have a unified source of truth for their source code. This is what makes open source possible.

    To create your repositories on GitHub or contribute to open source projects, you will need to create a personal account on GitHub.

    If your codebase is in a remote repository on GitHub:

    • Every other contributor who wants to work on the project will know that they can get the code from the remote repository.
    • Any updates that they make and then want to share can push those changes to the remote repository instead of sending each contributor the updates one by one; GitHub serves as the project’s single source of truth.
    • Contributors and collaborators can make use of GitHub’s project management and automation tools to make development fast and efficient.

    Get started with Git

    The Git software is a powerful command-line tool that you can install on your machine, whether you use Windows, macOS, or Linux.

    Follow the instructions here to install git (if it's not already installed). Note that for this tutorial we will be using git on the command line only. While there are some great git GUIs (graphical user interfaces), I think it's easier to learn git using git-specific commands first and then to try out a git GUI once you're more comfortable with the command.

    Note: 95% of other online git resources and discussions will also be for the command-line interface. 

    Once you have git installed, you can then run git commands locally. To confirm that Git has been installed successfully, run this command in your terminal:

    git --version

    The output should be the current version of Git installed in the system.

    First time configuration 

    Once you're done with above installation, create a GitHub account here.

    The git config command allows you to set configuration variables that control how git looks and operates. The config command works on different levels:

    • Local-level: This means that all your credentials and configurations are only limited to your project’s directory. By default, git config writes to a local level when no configuration is passed.
    • Global-level: this configuration is specific to a user on the operating system; the configuration values live in the user’s home directory.
    • System-level: These configurations are placed in the system’s root path; it tracks all users and all repos on the operating system.

    The first thing you configure after a successful installation is your email address and username; this will identify our contributions and changes in the project source code. To set up your user name and email, run the following in your command line:

    git config --global user.email "[email protected]"
    
    git config --global user.name "Ashutosh Krishna"

    You can verify that the commands worked by running the following commands:

    git config user.email
    git config user.name

    To see all the configurations currently saved on your working directory, run:

    git config -l
    

    If you run the previous command with a --global flag, your output will only contain configuration settings at the system level.

    Using Git for a new project

    Let’s see how we can set up a new project using Git.

    1. Initializing the repository

    First, create a new directory using the following command:

    mkdir first_project
    

    Next, you need to navigate to the newly created directory:

    cd first_project
    

    To initialize a git repository in this folder, which is now your working directory, run the following command:

    git init
    

    Running this command would initialize an empty Git repository in the current directory. A new subfolder named .git is created which contains several files and more subdirectories that Git will use to keep track of changes in the project.

    Let’s create the first file that we will be tracking using Git. Ensure you are still in the git_started directory on your terminal, then run the following command:

    touch README.md
    

    This will create a file named README with the Markdown extension.

    Note: Markdown is a lightweight markup language with plain-text-formatting syntax.

    Most software used to browse Git repositories visually (by providing a GUI) look for a readme.md file and render the contents on the project’s homepage. You would typically include information about your project such as setup instructions in this file.

    Open the file in your editor and add the following lines to it:

    # first_project
    
    This is your first Git Project. We will be working on this file as we learn more about Git.
    

    Save and close this file. With the file saved, the state of your repository should have changed. You can check this status by running the following command:

    git status
    

    This command doesn’t change or update anything. Instead, it prints out which files are modified, staged, or untracked. An untracked file is one that hasn’t been added to the git index yet, while a file that has been changed since your last commit was made will be seen as modified by git.

    2. Staging Commits

    To start tracking files in your project directory, you will utilize the git add command. This command adds the file(s) you specify to a staging area. Files that have been staged will be added to the next commit.

    A commit is a snapshot of the entire state that your project is in at that moment. Git keeps track of your project through a series, or chain, of commits. The most recent snapshot of your repository is referred to as the HEAD.

    As soon as you create a new commit, it will directly link to the HEAD. However, since the latest commit is now the most recent one, it will be considered the HEAD instead, replacing the previous one.

    Let’s commit our project’s readme file now. First, stage the file by running:

    git add .
    

    Note that this command adds all untracked and modified files to the staging area. If you want to add a specific file instead, specify the filename like this:

    git add README.md
    

    You can also remove files from staging by running the following command:

    git rm --cached [filename] 
    

    Next, you need to make a commit with an accompanying commit message. Commit messages are short descriptive messages describing what changes were made.

    Let’s commit the file that’s currently staged by running the following command:

    git commit -m "add README"
    

    This command saves a new commit with the message “add README”. Now, when you run git status, you will get a message indicating that your working tree is clean (no modified or untracked files).

    3. Ignoring Files

    Sometimes there are untracked files that you would not like to add to your git index. These may be user-specific configuration files, like a .env file, or folders with large files, like the vendor folder for PHP projects or node_modules in JavaScript projects.

    You can instruct git to ignore these files by adding glob patterns to a .gitignore file. This file will live in your project’s root directory and can contain any number of patterns. Any untracked file or folder that matches a pattern specified in the .gitignore file is ignored by git.

    Let’s see what this looks like in practice. Create a file named .gitignore in your current working directory.

    touch .gitignore
    

    Now, open this file and add the following lines to it:

    # Config files
    .env
    .env.local
    /.vscode
    
    # Large folders
    /node_modules
    /vendor
    

    Each line in a .gitignore file specifies a pattern. Lines that begin with a # sign are comments. The patterns here are similar to what you would typically see in a PHP or JavaScript project.

    The following are examples of patterns used in a .gitignore file:

    • *.env matches all files with a .env extension
    • /vendor matches the folder named vendor, as well as its subfolders and files
    • build_output.log would match the .log file named build_output.

    Adding Git to an existing project

    To add git to an already existing project, follow these steps in order:

    1. In your terminal make sure you are in the project directory,
    2. Initialize git using git init
    3. Create a .gitignore file and specify files and folders to be ignored (if this is not necessary, you can skip to step 4)
    4. Stage your files using git add . Commit your changes with an appropriate commit message, for example: git commit -m "first commit"

    1. Working with remotes

    Let’s create a remote repository on GitHub. Once you are logged in and are on the homepage, you will notice a button on the top left side titled ‘New’ (see figure below).

    Once you click on the ‘New’ button, GitHub will redirect you to a different page where you will have to provide a name for the repository. You can also add a description of your repository, but this is optional.

    GitHub allows you to make your repositories either public or private.

    • public repository is accessible to anyone. Anyone is able to see the codebase and clone this repository to their local machine for use.
    • private repository is only visible to people who you have chosen. No other person is able to view it.

    Our project already has a README and .gitignore file, so we can leave the options to initialize with a README and .gitignore unchecked.

    2. Pushing code to GitHub

    Having created the repository, we now need to add the files from our local repository to the remote one on GitHub. To do this, we first have to link to the remote repository from our local project.

    Git provides the remote command to help with this. The git remote command allows Git to track remote repositories and connects local repositories to those remote ones. For example, let’s say we want to add our remote repository to the local one. The command command format is:

    git remote add <remote_name> <remote_url>

    Therefore, the command we will run will be:

    git remote add origin <url_to_remote_repository>

    Note: The name origin is essentially a more human-readable way to link to the remote repository instead of always having to use the actual URL. origin is simply a conventional name, but we can use any other name as well. 

    Once we have added the remote repository URL to our local one, we will want to push or upload our local code and its revision history to the remote repository. This can be done using git push

    The git push command will update the remote repository code with all the updates that were made in the local repository.

    Let’s make use of this command in our project. First, commit the .gitignore file we created earlier.

    git add .
    
    git commit -m "add .gitignore"
    

    Now you can run the following command to push your code to the remote repository:

    git push origin master
    

    And there you have it. You have successfully pushed your code to a remote repository.

    3. Updating the local repository

    To update your local repository from a remote one, you need to run the git pull. This command fetches every change to the remote branch and automatically merges it to your local repository.

    Every change made to your local repository must be committed before a merge can occur.

    Conclusion

    Congratulations on creating your first local and remote Git repository! You will need to have a good grasp of Git and GitHub as many teams utilize these tools in their product development workflows. There’s still a lot to learn. The next things to look into are:

    • Git logs
    • How to undo commits
    • Creating and manipulating branches
    • Resolve merge conflicts
    • Git rebase vs. merging
    • and more

    Cheers and happy learning!

    0 Comments

    To add a comment, please Signup or Login