Learn Git & GitHub Online - Beginner & Intermediate Concepts

Understanding the command line - the terminal / shell / bash

• terminology

  • GUI = graphical user interface

  • CLI = command line interface - command line

    • terminal = text input/output environment; console = physical terminal

      • unix / linux / mac

        • shell / bash / terminal

      • windows

        • command prompt / windows command / cmd / dos prompt

This lecture aims to demystify the terminologies and concepts associated with the terminal, shell, and command line interfaces (CLI). We'll break down:

GUI vs CLI: Understand the difference between a Graphical User Interface (GUI) and a Command Line Interface (CLI), and why learning the latter is crucial for many computing tasks.

Terminal and Console: Clarify the terms 'terminal' and 'console,' and how they differ from each other. Gain insights into how a terminal is a text input/output environment while a console refers to the physical terminal.

Unix/Linux/Mac Environments: Dive into the common terminal-related terminologies used in Unix, Linux, and Mac operating systems, such as 'Shell' and 'Bash.'

Windows Environment: Familiarize yourself with the Windows command prompt, its history, and how it's referred to as CMD or DOS prompt.

By the end of this lecture, you'll have a firm grasp of what these terms mean, how they relate to each other, and what they imply for different operating systems. This knowledge is foundational for anyone aiming to become proficient in programming, system administration, or any field requiring advanced computer skills.

Installing git from git-scm and getting git bash on Window

In this focused lecture, we take a deep dive into the world of terminal, shell, and Bash functionalities on a Windows system. Here's what you'll learn:

• Git SCM for Windows: Understand what Git SCM (Source Code Management) is and how it brings Unix-style terminal functionalities to a Windows environment.

• Installing Git SCM: A step-by-step guide to installing Git SCM, which is crucial for enabling a Unix-like terminal in a Windows setting.

• Terminal vs Shell vs Bash: Learn how these elements differ in a Windows context compared to Unix/Linux systems and how Git SCM ties them together on Windows.

• Commands and Syntax: Introduction to basic commands and syntax you'll use in Git Bash, providing a smoother transition for those used to Unix/Linux command lines.

• Link to Git SCM: We'll walk you through downloading and installing Git SCM from https://git-scm.com/ to set up your terminal environment on Windows.

By the end of this session, you'll know how to effectively use Git SCM to harness the power of terminal, shell, and Bash commands on your Windows machine, thus bridging the gap between Unix/Linux and Windows terminal functionalities.

The essentials of navigating the terminal / shell / bash

• shell / bash commands

  • pwd

  • ls

  • ls -la

    • permissions

      • owner, group, world

      • r, w, x

      • 4, 2, 1

d = directory

rwxrwxrwx = owner, group, world

owner group bytes last modification hidden & name

• cd

• cd ..

• cd ../../..

In this lecture, we'll walk you through the rudimentary yet fundamental commands for navigating the shell or bash environment. Our focus will be on providing you with the essential tools to move efficiently within your file system. The key takeaways include:

• Current Directory Check: Understanding the pwd command to always know where you are within your file system.

• Listing Files: Learning the basics of the ls command to view files and directories in your current location.

• Extended Listing: Expanding on the ls command with the ls -la option to view detailed information, including hidden files.

• Directory Navigation: Master the cd command to switch between directories with ease.

• Navigating Upwards: Use cd .. to move up a level in your directory structure, and understand how to jump multiple levels at once with cd ../../...

By the end of this lecture, you'll have the foundational knowledge needed to navigate the shell or bash terminal with confidence and efficiency. Whether you're a complete beginner or in need of a quick refresher, this lecture has got you covered.

• mkdir

• touch

  • touch temp.txt

• nano temp.txt

• cat temp.txt

• clear

  • command + k

  • clear

• chmod

  • chmod options permissions filename

  • chmod 777 temp.txt

• env

• rm <file or folder name>

  • rm -rf <file or folder name>

here are all of the commands

• pwd

• ls

  • ls -la

• cd

  • cd ..

  • cd ../../..

• mkdir

• touch

  • touch temp.txt

• nano temp.txt

• cat temp.txt

• clear

  • command + k

  • clear

• chmod

  • chmod options permissions filename

  • chmod 777 temp.txt

• env

• rm <file or folder name>

  • rm -rf <file or folder name>

In this video, we dive into a wide array of shell and bash commands that are essential for managing files and folders effectively. Whether you are new to bash or are looking to polish your skills, this lecture covers all you need to know. Here are some of the topics we'll cover:

• Creating Directories: How to use mkdir to create a new directory.

• Creating Files: Utilizing the touch command to create empty files and understanding how to create and edit text files with nano.

• Reading File Content: Introducing the cat command to read the content of a text file.

• Clearing Screen: A look at the clear command and the command + k shortcut to keep your terminal uncluttered.

• File Permissions: Using chmod to change the permissions of files and directories. We'll dive into the options and numerical representation like chmod 777.

• Environment Variables: Briefly touching on the env command to display all your environment variables.

• Removing Files and Folders: Understanding the rm command, and the implications of the -rf option for deletion.

• Quick Recap: A rundown of all the commands covered, from pwd to rm -rf, so you can easily refer back when needed.

By the end of this lecture, you'll have a solid grasp on file and directory management in the shell or bash environment. This knowledge will prove invaluable whether you're coding, scripting, or simply trying to be more efficient at the terminal.

• using the “|” pipe command to pipe output to another function

  • ls -la | grep -i learn

• grep

  • cat temp2.txt | grep enter

  • ls | grep -i documents

• grep --help

• all commands

In the bash terminal, you can access help documentation for various commands and their options using the `man` command, which stands for "manual."

To view the help documentation for the `-i` flag when using the `grep` command, you can follow these steps:

1. Open your terminal.

2. Type the following command and press Enter:

man grep

(note: this doesn’t work for me on gitbash in windows)

3. This will open the manual page for the `grep` command. You can navigate through the manual page using the arrow keys, and you can search for specific terms using the `/` key followed by your search term (in this case, `-i`).

4. Scroll through the manual page to find the information about the `-i` flag, which typically stands for "ignore case" in `grep`. The manual page will provide details about how the flag works and what effect it has on the `grep` command's behavior.

5. To exit the manual page and return to the terminal, press the `q` key.

Remember that the `man` command can be used for other commands as well, not just `grep`. You can access detailed documentation for various Unix-like commands by using `man` followed by the command name. If you're looking for a quick summary of available options without diving into the full manual, you can often use the `--help` flag as well. For example:

grep --help

This will display a brief summary of the available options for the `grep` command without opening the full manual page.

--------

Dive into the powerful capabilities of pipe (|) and grep commands in shell/bash scripting, transforming the way you handle and manipulate data streams. This lecture offers a comprehensive guide to using these tools effectively, focusing on real-world scenarios and examples. Here's a breakdown of what you'll learn:

• The Pipe (|) Command: Learn how to pipe output from one command to another using the | symbol. For example, you'll learn how to use ls -la | grep -i learn.

• Grep Essentials: An in-depth exploration of the grep command for text searching. Know when and how to use grep with commands like cat and ls.

• Case Sensitivity with -i: Using the -i flag to make your grep searches case-insensitive.

• Manual (man) Command: How to leverage the man command to explore detailed documentation of Unix-like commands, including what each flag does. We'll discuss how to use it even if it doesn't work in certain environments like Git Bash on Windows.

• Navigating the Manual: Learn the basics of navigating through the manual pages, including scrolling and searching for specific terms or flags.

• Quick Help with --help: Using the --help flag for a summary of available options when you need a quick reminder.

By the end of this session, you'll have mastered the basics of data filtering and command chaining in the terminal, arming you with powerful tools for text manipulation and data analysis.

• env

• echo $<env name>

Environment variables are a feature of operating systems that allow you to set global variables which can be accessed by any program running on the system. These variables can store configuration settings, file paths, options, and other types of data that may be used by multiple programs.

In Unix-like operating systems such as Linux and macOS, environment variables are often set in shell sessions and can be accessed and modified using shell commands. For instance, the `export` command in the bash shell allows you to set an environment variable:

```bash

export VAR_NAME="value"

```

You can read the value of an environment variable using the `$` symbol:

```bash

echo $VAR_NAME

```

In Microsoft Windows, environment variables can be set and accessed through the system properties dialog box, the Windows command prompt using `set`, or through PowerShell using `Get-EnvironmentVariable` and `Set-EnvironmentVariable`.

Environment variables are widely used for various purposes:

1. Configuration: Many software packages and frameworks use environment variables to store configuration settings. For instance, you might set an environment variable to point to the directory where a particular library is stored.

2. Scripting and Automation: Scripts can use environment variables to store temporary values for use in multiple commands, making the script easier to understand and manage.

3. Inter-Process Communication: While not the most efficient method, some applications use environment variables to pass data between different processes.

4. Security: Sensitive information like API keys or database passwords can be stored in environment variables. However, be aware that this is not the most secure method unless additional security measures are taken.

5. Platform Management: They are used to configure settings that are meant to apply to multiple applications running on the same system.

6. Localization and Internationalization: Settings like language or date formats can be set globally and then accessed by various programs.

Note that environment variables are typically case-sensitive, especially on Unix-like operating systems. They are also typically global, meaning that once set, they are available to all processes, although some can be set to be only available to the current process or its child processes. Therefore, care should be taken to avoid naming conflicts and to manage values responsibly.

-----------

Unlock the power of environment variables in your shell or bash terminal with this in-depth guide. Environment variables are essential tools in the developer's toolkit, allowing you to manage configurations, simplify scripting, and facilitate inter-process communication. Here's what this lecture will cover:

• What Are Environment Variables?: Understand what environment variables are, and why they are crucial in both Unix-like and Windows operating systems.

• Setting Variables: Learn how to set environment variables using the export command in Unix-like systems and set in Windows. Example: export VAR_NAME="value"

• Reading Variables: Get to know how to read the value of an environment variable using commands like echo $VAR_NAME.

• Use Cases: From software configuration to scripting, find out the multitude of purposes that environment variables serve.

• Security Considerations: Understand the security implications when storing sensitive data like API keys as environment variables.

• Global vs. Local Scope: Learn how to set variables that are either globally available to all processes or local to specific ones.

• Case Sensitivity and Naming Conflicts: Tips on how to manage the naming of your variables effectively to avoid potential issues.

By the end of this lecture, you'll have a comprehensive understanding of environment variables and how to use them efficiently in various computing environments.

• env

• echo $<env name>

• nano ~/.bash_profile

  • export MY_VARIABLE="example_value"

• source ~/.bash_profile

Both `.bash_profile` and `.bashrc` are configuration files used in Unix-like operating systems, specifically for the Bash shell. They serve different purposes and are loaded under different circumstances.

.bash_profile

• configure user-specific settings

  • environment variables

  • configure the user's PATH

• Executed when a user logs into a computer, either locally or remotely using SSH.

-----------

In this lecture, you'll get hands-on experience in setting up your bash environment to better suit your development needs. Understanding .bash_profile, .bashrc, and environment variables can streamline your workflow and make you a more efficient developer. In this session, you'll learn:

• Environment Variables and 'env' Command: Begin with the basics as you learn how to list all environment variables using the env command and how to read specific variables with echo $<env name>.

• The Role of .bash_profile: Understand what .bash_profile is, when it gets executed, and how to edit it using text editors like nano.

• Exporting Variables: Discover the export command to set environment variables that will be available to other processes. Example: export MY_VARIABLE="example_value".

• Reloading .bash_profile: Learn how to apply your changes immediately without needing to log out and back in by using source ~/.bash_profile.

• .bashrc vs .bash_profile: Get a grasp on the differences between .bashrc and .bash_profile, their specific use-cases, and when each file is loaded.

• Best Practices: Round up the session with guidelines on setting user-specific configurations and managing your PATH.

By the end of this lecture, you'll have a robust understanding of how to set, read, and manage environment variables and will be familiar with the crucial .bash_profile and .bashrc files.

.bashrc

• configure the bash shell itself.

  • set up aliases

  • define functions

  • customize the shell prompt (PS1)

  • configure other shell-specific behaviors.

• executed each time an interactive shell session is started.

To ensure that the settings in `.bashrc` are also applied when you log in, you can source the `.bashrc` file from within your `.bash_profile`. This way, the settings from `.bashrc` will be loaded with the settings from `.bash_profile`

1. Open `.bash_profile` file using a text editor.

```bash

nano ~/.bash_profile

```

2. Add the following line at the end of your `.bash_profile` file to source (execute) the `.bashrc` file:

```bash

source ~/.bashrc

```

Alternatively, you can use the shorthand notation for sourcing:

```bash

. ~/.bashrc

```

3. Save and exit the text editor.

Now, when you log in or start a new shell session, the `.bashrc` settings will be applied in addition to the settings defined in `.bash_profile`.

Keep in mind that some systems might have slightly different configurations or use a different shell. Always consult your system's documentation or consult with an administrator if you're unsure about the best way to set up your shell environment.

• in .bashrc

  • PS1="\W$ "

To change the prompt displayed in the Bash terminal, modify the `PS1` environment variable. The `PS1` variable controls the format of the prompt you see before entering commands.

1. Open a terminal window.

2. To see your current prompt configuration, you can simply echo the value of the `PS1` variable:

```bash

echo $PS1

```

This will give you an idea of what the current prompt looks like.

3. To change the prompt, set the `PS1` variable to your desired format. For example, you can set it to something like:

```bash

PS1="\[\e[32m\]\u@\h \[\e[34m\]\w\[\e[0m\]\$ "

```

In this example, the prompt will display the username (`\u`), hostname (`\h`), and current working directory (`\w`) in different colors.

The `\[` and `\]` around color codes are used to indicate non-printable characters so that the terminal can properly calculate the prompt's length.

4. To make the changes take effect, either enter the modified `PS1` command directly in your terminal session, or add it to your shell configuration file (like `~/.bashrc` or `~/.bash_profile`) so that it's applied each time you start a new terminal session.

5. If you've made changes to a configuration file, you can either restart your terminal or execute the following command to apply the changes immediately without restarting:

```bash

source ~/.bashrc

```

ESCAPED CHARACTERS

Yes, there are several escaped characters that you can use to display various information in your Bash prompt. These escaped characters are surrounded by `\[` and `\]` to ensure proper formatting and prevent issues with cursor positioning. Here are some commonly used escaped characters for customizing your Bash prompt:

• \u username

• \h hostname

• \w current working directory

• \W basename of current working directory

• \d current date in the format "Weekday Month Day"

• \t current time in the format "HH:MM:SS".

• \n newline (line break).

• \$: displays a $ for regular users or # for root user (super user)

• \\ a literal backslash

• \e an escape character (useful for adding color codes)

Here's an example of how you might use some of these escaped characters to create a custom prompt:

```bash

PS1="\u@\h [\w]\$ "

```

This prompt would display something like:

```

username@hostname [/path/to/current/directory]$

```

You can mix and match these escaped characters to create a prompt that suits your preferences and provides the information you find most useful.

ENVIRONMENT VARIABLE

You can include an environment variable in your Bash prompt by referencing the variable within the `PS1` environment variable setting. Here's how you can do it:

Let's say you have an environment variable named `MY_VARIABLE` and you want to include its value in your Bash prompt. You can modify your `PS1` setting like this:

```bash

PS1="\u@\h [\w] \[$MY_VARIABLE\]\$ "

```

In this example, `\[$MY_VARIABLE\]` is where the value of the `MY_VARIABLE` environment variable will be inserted into the prompt. The `\[` and `\]` around it are used to properly handle the variable expansion and formatting in the prompt.

When you use this `PS1` configuration, your prompt will look like:

```

username@hostname [/path/to/current/directory] my_variable_value$

```

Just replace `my_variable_value` with the actual value of your `MY_VARIABLE` environment variable.

COLORS

• Black \[\e[30m\]

• Red \[\e[31m\]

• Green \[\e[32m\]

• Yellow \[\e[33m\]

• Blue \[\e[34m\]

• Magenta \[\e[35m\]

• Cyan \[\e[36m\]

• White \[\e[37m\]

• Light Gray \[\e[90m\]

• Light Red \[\e[91m\]

• explore established settings for git-bash

  • /C/Program Files/git/etc/profile.d

    • cat bash_profile.sh

    • cat git-prompt.sh

• the files we created run after the git profile files

  • ~/.bash_profile

  • ~/.bashrc

• start a new bash

  • old files should load

Files with the `.sh` extension are typically shell script files. These scripts are written for a shell, or command-line interpreter, such as `bash` (Bourne-Again SHell), `sh` (Bourne SHell), or `dash` (Debian Almquist Shell). Shell scripts are used to automate tasks, perform file manipulations, execute commands, and more.

Here is a very simple example of a shell script that prints "Hello, world!" to the console:

```bash

#!/bin/bash

echo "Hello, world!"

```

The first line, `#!/bin/bash`, is known as the shebang. It specifies the interpreter for the script, which in this case is `bash`. After that, any commands you put in the script will be executed in order when the script is run.

You can make a `.sh` file executable by running the `chmod` command on it:

```bash

chmod +x my_script.sh

```

Then you can run it like this:

```bash

./my_script.sh

```

Keep in mind that shell scripts are generally platform-specific. They're commonly used on Unix-like operating systems like Linux and macOS but are generally not directly compatible with Windows (though there are workarounds, such as using a Unix-like environment like WSL, Cygwin, or Git Bash on Windows).

• shasum /path/to/file

Hash Algorithm

A hash algorithm, also known as a hash function, is a mathematical function that

• takes an input (often a message or a file) and produces a fixed-size output, usually in the form of a hash value or digest.

• The output, known as the hash code or hash value, is unique to the input data. Hash functions are designed to be fast and efficient to compute, and even a small change in the input data will result in a significantly different hash value.

Commonly used hash algorithms include MD5, SHA-1, SHA-256, and SHA-3. However, it's important to note that some older hash algorithms like MD5 and SHA-1 are no longer considered secure due to vulnerabilities that have been discovered over time. In modern applications, it's recommended to use stronger hash algorithms like SHA-256 or SHA-3.

Hash algorithms are used for various purposes, including data integrity verification, digital signatures, password hashing, and more.

For data integrity verification, the hash value of a file can be calculated before and after transmission, and the recipient can compare the received hash value to the original hash value to ensure that the file has not been tampered with during transmission.

Checksum

A checksum is a value derived from a set of data, often by performing a mathematical operation on the data. Checksums are commonly used in error detection in digital communication and storage systems.

The idea is that the sender calculates a checksum based on the data they're sending and includes it in the transmission. The recipient can then independently calculate a checksum based on the received data and compare it to the checksum sent by the sender. If the checksums match, it suggests that the data was received correctly.

Checkums can be as simple as a sum of all the bytes in a data block or more complex algorithms that involve bitwise operations. They're often used in networking protocols, file transfers, and storage systems to ensure that data hasn't been corrupted during transmission or storage.

A hash can be used as a checksum. While hash algorithms and checksums serve slightly different purposes, there is some overlap in how they can be used. In some cases, a hash value generated using a hash algorithm can function effectively as a checksum to detect errors or changes in data.

For this hands-on exercise, practice the following terminal commands:

• pwd

• ls

• ls -la

• cd

• cd ..

• cd ../../..

• mkdir

• touch temp.txt

• nano temp.txt

• cat temp.txt

• cat temp2.txt | grep enter

• clear

• command + k

• clear

• env

• echo $PATH

• rm

• rm -rf

• shasum

• shasum -h

• shasum -a 256

commands at the terminal

• git

• git version

• git help

• EBNF

all commands will be highlighted in yellow the first time - for ease of reference

Extended Backus–Naur Form (EBNF) is a way to describe the grammar of a programming language, a file format, or any structured text. It helps you specify the "rules" for what sequences of symbols are valid in that language or format. EBNF is an extension of the original Backus–Naur Form (BNF), and it includes some additional notation to make it easier to write grammars.

Simple EBNF Elements

1. Terminal Symbols: These are the actual symbols of the language you're describing. They are usually in quotes. For example, `"a"` represents the letter a.

2. Non-terminal Symbols: These are placeholders for patterns of terminal symbols. They are usually written in angle brackets like `<expression>`.

3. Sequence: Writing two elements side-by-side indicates they should appear in sequence.

<letter> <digit>

4. Choice: The pipe (`|`) symbol allows for choices between different elements.

"a" | "b"

5. Repetition: Curly braces `{}` indicate zero or more repetitions of an element.

{ <digit> }

6. Optional: Square brackets `[]` indicate the element is optional.

[ <whitespace> ]

7. Grouping: Parentheses `()` are used for grouping elements.

( "a" | "b" ) "c"

Simple Example

Let's say we want to describe a simplified grammar for a calculator that can add and multiply numbers. The EBNF might look something like this:

<expression> ::= <term> { ("+" | "-") <term> }

<term> ::= <factor> { ("*" | "/") <factor> }

<factor> ::= <number> | "(" <expression> ")"

<number> ::= <digit> { <digit> }

<digit> ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"

Here, each rule defines what makes a valid `<expression>`, `<term>`, `<factor>`, `<number>`, or `<digit>`.

- `<expression>` is made up of one or more `<term>`s separated by either a `+` or `-`.

- `<term>` is made up of one or more `<factor>`s separated by either a `*` or `/`.

- `<factor>` could either be a `<number>` or another `<expression>` enclosed in parentheses.

- `<number>` is one or more `<digit>`s.

- `<digit>` is any single numeral from 0 to 9.

So, according to this simple grammar, "1+2", "3*4+2", and "(1+2)*3" are valid expressions.

remote repository

stash

local repository

staging area

local folder: .git folder, your files, subfolders

• your repository is your REPOSITORY of all of your file versions, aka, commits

• git init

• staging allows you to group files for a commit

  • illustration

    • add this to the stage

    • add that to the stage

    • don’t add this other one

    • take this one off the stage

  • staging allows you to group code you want to commit in one commit

    • shipping analogy - staging christmas presents

      • I have a room full of presents

      • let me use my kitchen table as a stage

        • add presents going to family in Portland

          • get them all on the table - they’re all staged

          • now ship them off (commit them)

        • add presents going to family in Hawaii

          • ….

• git init

• .git folder added

  • “.” is a hidden folder

  • files & folders of note:

    • config file

      • local

        • .git/config

      • global

        • windows

          • C:\Users\UserName\.gitconfig

        • mac

          • ~/.gitconfig or $HOME/.gitconfig

  • .git/head

    • what is the HEAD pointing to?

  • .git/refs/heads/

    • what is that HEAD shasum?

• YOU CAN DELETE THIS .git FOLDER AND START ALL OVER AT ANY TIME - TOTALLY FINE!

• add

  • git add <filename>

  • git add .

  • git add --all

• status

  • git status

• commit

  • git commit -m “<some message>”

• log

  • git log

  • git log --oneline

The command "git add ." is used to stage changes for commit. The dot (" . ") in this command is a shorthand notation that represents the current directory and all its contents.

• git commit

now you write your message in an editor like vs code first line is main message; subsequent lines show up with git log # are comments

best practice: make your commit message descriptive: short, concise, evocative.

For this hands-on exercise, practice the following Git commands:

• git config --list

• git config --global user.name "John Doe"

• git config --global user.email "johndoe@example.com"

• git config --global user.email "8296040+GoesToEleven@users.noreply.github.com"

• git

• git version

• git help

• git init

• git status

• git add --all

• git commit -m “some message”

• git log

• git log --oneline

• git log

• git log --oneline

  • git log --oneline -N

where N is the number of commits you want shown

CHECKSUM commit ID

• space or f

• b

• ⬆⬇

• q

• git log --author=”Todd”

• git log --grep=”Happy”

grep = "Global Regular Expression Print"

• git log <treeish>..<treeish>

from..to

example: git log <treeish>..HEAD

• git log <filename>

• git log -p

shows every commit and the changes

• git log --stat

The `-p` option in the `git log` command stands for "patch." When you use `git log -p`, you'll not only see the commit history, but you'll also get the patch output (i.e., the differences) for each commit. This makes it easier to understand what changes were introduced in each commit.

Normally, `git log` just shows you a summary line for each commit: the commit hash, the author, the date, and the commit message.

The `-p` option expands on this by also showing the differences (in diff format) between each commit and its parent.

This can be very useful for code reviews or when you're trying to understand the history of a project. The diff output helps to highlight what was changed in the source code for each commit.

The `git log --stat` command displays the commit history along with some basic statistics for each commit, indicating which files were modified and how many lines were added or deleted.

The `--stat` option shows a diffstat of what each commit changes. This makes it easier to understand the impact of each commit in terms of files and lines without showing the actual line-by-line changes (as you'd get with `git log -p`).

This format can be very helpful for quickly scanning through the commit history to understand the breadth and impact of each commit without needing to see the detailed changes.

• git log --after=”4 weeks ago” --before=”2 days ago”

shows every commit and the changes

The `--after` and `--before` options in the `git log` command filter the commit history based on the specified time range. Git is quite flexible in the time periods it accepts. You can use a variety of formats to specify the time, and yes, you can use minutes and hours as well.

Here are some examples of different time periods you can use:

- `--after="5 minutes ago"`

- `--before="3 hours ago"`

- `--after="2 days ago"`

- `--before="6 months ago"`

- `--after="1 year 2 months 3 days 4 hours ago"`

You can also use specific dates in a variety of formats:

- `--after="2021-01-01"`

- `--before="2021-12-31 23:59"`

You can even combine them:

- `git log --after="2 days ago" --before="3 hours ago"`

The flexibility allows you to narrow down your search quite effectively, making it easier to browse through the commit history.

Here's a more comprehensive list of units you can use:

- Minutes: `minutes` or `minute`

- Hours: `hours` or `hour`

- Days: `days` or `day`

- Weeks: `weeks` or `week`

- Months: `months` or `month`

- Years: `years` or `year`

Remember that you can combine them into a single statement like "1 year 2 months 3 days 4 hours ago" to be even more precise.

• git log --format=short

oneline | short | medium (default) | full | fuller | email | raw

• git log --oneline

• useful for branches

• git log --graph

for branches

• git log --graph --all --oneline --decorate

For this hands-on exercise, create a repo then clone it to your computer.

For this hands-on exercise, practice using the following git commands:

• git log

  • git log --oneline

  • git log --oneline -N

    • where N is the number of commits you want shown

• navigating

  • space or f

  • b

  • ⬆⬇

  • q

• git log -p

  • Normally, `git log` just shows you a summary line for each commit: the commit hash, 24 the author, the date, and the commit message. The `-p` option expands on this by also showing the differences (in diff format) between each commit and its parent.

• git log --stat

  • The `git log --stat` command displays the commit history along with some basic statistics for each commit, indicating which files were modified and how many lines were added or deleted.

• git log --after=”4 weeks ago” --before=”2 days ago”

• git log --format=short

  • oneline | short | medium (default) | full | fuller | email | raw

  • git log --oneline

• useful for branches

  • git log --graph

  • git log --graph --all --oneline --decorate

• git ls-tree <treeish>

• git help ls-tree

A TREE is a directory structure with sub-directories and files

In git, a "tree" refers to a fundamental data structure that represents the state of a directory at a specific point in time. It's essentially a snapshot of the directory's contents, including subdirectories and files, along with their metadata such as names, permissions, and pointers to the corresponding blobs (file content) or subtrees (subdirectory contents).

A tree object in git contains the following information for each entry in the directory:

1. Mode: Specifies whether the entry is a regular file, executable file, subdirectory, etc.

2. Type: Specifies whether the entry is a "blob" (file content) or a "tree" (subdirectory content).

3. Object Hash: The unique SHA-1 hash of the corresponding blob or subtree object.

4. Name: The name of the file or subdirectory.

Trees are an integral part of git's internal data structure that enables it to efficiently store and track changes to the contents of a repository. When you make a commit, git creates a new tree object that represents the state of the directory at that commit, linking to the appropriate blobs for file contents and subtrees for subdirectories. This structure allows git to maintain a complete history of changes while minimizing duplication of content.

To visualize it:

```

Tree Object:

- Mode: 100644 (file)

- Type: blob

- Object Hash: a1b2c3... (SHA-1 hash of file content)

- Name: example.txt

- Mode: 040000 (directory)

- Type: tree

- Object Hash: d4e5f6... (SHA-1 hash of subtree)

- Name: subdirectory

```

Internally, git uses a linked list architecture for its internal implementation of version control. The fundamental data structure in git is a directed acyclic graph (DAG) composed of commits. Each commit points to its parent commit or commits, forming a linked list-like structure.

It's important to note that git's internal representation is not a traditional linked list in the sense of a single chain of nodes. Instead, it's a more complex graph structure. Each commit in git has a unique hash (SHA-1 or a more secure hash function in recent versions of git) that acts as its identifier. Each commit points to one or more parent commits, forming a history of changes.

This graph structure allows git to efficiently represent branching and merging, which are core features of version control. When you create a new branch or perform a merge, git creates new commits with multiple parent references, forming a graph that shows how different branches and changes have evolved over time.

https://chat.openai.com/share/aa542aa4-b854-4fb3-b23c-941e9137dccb

In git, "treeish" references are ways to specify a specific state of the project's directory structure. They're typically used to refer to different snapshots of your repository's content. Here are some specific examples of treeish references:

1. Commit Hash: A commit hash uniquely identifies a specific commit. You can use the full or abbreviated hash to refer to the tree of that commit. For example:

```

git diff abc1234 # Diff against the commit with hash abc1234

git show def5678 # Show the changes in commit def5678

```

2. Branch Name: Branches in git point to specific commits. When you use a branch name as a treeish reference, git uses the latest commit in that branch's history. For example:

```

git diff main # Diff against the latest commit on the 'main' branch

git log feature/xyz # Show commit history on the 'feature/xyz' branch

```

3. Tag Name: Tags also point to specific commits. Using a tag name as a treeish reference will refer to the commit associated with that tag. For example:

```

git show v1.0.0 # Show the changes in the commit tagged as v1.0.0

```

4. Ancestry Notations: git provides notations for specifying commit ancestry. For instance, `^` and `~` can be used to reference parent commits and grandparent commits, respectively. For example:

```

git diff HEAD^ # Diff against the parent commit of the current commit

git diff HEAD~2 # Diff against the grandparent commit of the current commit

```

5. Relative Refs: You can use relative references to specify commits relative to a starting point. For instance, `HEAD~n` refers to the nth ancestor of the current commit. Also, you can use the caret (^) to move upwards in the commit hierarchy. For example:

```

git diff HEAD~3..HEAD~2 # Diff between the 3rd and 2nd ancestors of the current commit

git diff HEAD^^^..HEAD~2 # Same as above using caret notation

```

6. Commit Ranges: You can specify a range of commits using double-dot notation. This will include all the commits reachable from the second commit but exclude those reachable from the first commit. For example:

```

git log commit1..commit2 # Show commits reachable from commit1 exclusive to commit2 inclusive

```

7. File Revisions: You can also use treeish references to specify the state of a single file in a specific commit. For instance:

```

git show commit:path/to/file.txt # Show the content of 'file.txt' in the specified commit

```

These are just a few examples of treeish references in git. They allow you to navigate and work with different snapshots of your repository's content using various forms of references.

• git show <treeish>

• git log

  • view the history of commits in a repository branch

• git show

  • display info about a specific commit, including changes in that commit.

`git log` and `git show` are both commands in the git version control system, but they serve different purposes and provide different kinds of information about the commit history.

1. git log:

The `git log` command is used to display the commit history in a repository branch. When you run `git log`, it shows a list of commits in reverse chronological order (newest to oldest), with each commit's hash, author, date, and commit message. By default, it displays a concise version of the commit information.

You can use various options and flags with `git log` to customize the output. For example:

git log -p Shows the commit history along with the diff introduced by each commit.

git log --oneline Shows a simplified one-line representation of each commit.

git log --author=<author> Filters the log to show commits made by a specific author.

git log <branch> Shows the commit history of a specific branch.

2. git show:

The `git show` command is used to display detailed information about a specific commit, including the commit's changes, author, date, and commit message. When you run `git show <commit_hash>`, it shows information about that specific commit. The commit hash can be obtained from the `git log` output.

The `git show` command also displays the diff of the changes introduced by the commit, making it useful for reviewing the exact changes made in that commit. Additionally, you can specify options to control the display of information, such as `git show --stat` to show a summary of the changes.

commit - parent - grandparent - great grandparent ….

this way

or this way

• git show <treeish>^

• git show head ^^

• git show head ^^^

• git show <treeish>~1

• git show head~2

• git show head~3

• git show head~4

or use any reference to any treeish other than head, such as a checksum

• git ls-tree <treeish>

• git ls-tree <treeish>^

• git ls-tree <treeish> <path>

• git ls-tree <treeish> <path>/

In this hands-on exercise, practice using the following Git commands to get information:

• git ls-tree <commit>

  • git ls-tree <commit>^^

  • git ls-tree <commit>^^^

• git show <commit>

  • git show head ^^

  • git show head ^^^