├── .gitignore ├── 00_getting_started ├── 01_configuring_git │ ├── crlf.md │ └── readme.md ├── 02_getting_help │ └── readme.md └── readme.md ├── 01_creating_snapshots ├── 01_initilizing_a_git │ └── readme.md ├── 02_staging_a_files │ └── readme.md ├── 03_committing_changes │ └── readme.md ├── 04_skipping_the_staging_area │ └── readme.md ├── 05_removing_files │ └── readme.md ├── 06_renaming_or_removing_files │ └── readme.md ├── 07_ignoring_files │ └── readme.md ├── 08_short_status │ └── readme.md ├── 09_viewing_staged_and_unstaged_changes │ └── readme.md ├── 10_visual_diff_tools │ └── readme.md ├── 11_viewing_a_commit_history │ └── readme.md ├── 12_viewing_a_commit_exactly │ └── readme.md ├── 13_unstaging_files │ └── readme.md ├── 14_discard_local_changes │ └── readme.md ├── 15_restoring_a_file_to_an_earlier_version │ └── readme.md ├── 16_creating_snapshots_with_vscode │ └── readme.md ├── 17_summary_of_commands │ └── Summary.pdf ├── 18_exercise_of_question │ └── Exercises.pdf └── readme.md ├── 03_browsing_history ├── 01_getting_a_repository │ ├── Venus.zip │ └── readme.md ├── 02_viewing_the_history │ └── readme.md ├── 03_filtering_the_history │ └── readme.md ├── 04_formatting_the_log_output │ └── readme.md ├── 05_alias │ └── readme.md ├── 06_viewing_a _commit │ └── readme.md ├── 07_viewing_the_changes_across_two_commits │ └── readme.md ├── 08_checking_out_to_a_commit │ └── readme.md ├── 09_finding_bug_using_bisect │ └── readme.md ├── 10_finding_contributors_using_shortlog │ └── readme.md ├── 11_viewing_the_history_of_a_file │ └── readme.md ├── 12_restoring_a_deleted_file │ └── readme.md ├── 13_finding_the_author_of_a_line_using_blame │ └── readme.md ├── 14_tagging │ └── readme.md ├── 15_browsing_a_history_using_vs_code │ └── readme.md ├── 16_summary │ └── Summary.pdf ├── 17_exercise │ └── Exercises.pdf └── readme.md ├── 04_branching ├── 01_introduction │ └── readme.md ├── 02_What_are_branches │ └── readme.md ├── 03_getting_a_repository │ ├── Venus.zip │ └── readme.md ├── 04_working_with_branches │ └── readme.md ├── 05_comparing_branches │ └── readme.md ├── 06_stashing │ └── readme.md ├── 07_merging │ ├── 01_fast_forward_merges │ │ └── readme.md │ ├── 02_three_way_merges │ │ └── readme.md │ └── readme.md ├── 08_viewing_merge_and_unmerge_branches │ └── readme.md ├── 09_merge_conflicts │ └── readme.md ├── 10_graphical_merge_tool │ └── readme.md ├── 11_aborting_a_merge │ └── readme.md ├── 12_undoing_faulty_merge │ └── readme.md ├── 13_squash_merge │ └── readme.md ├── 14_rebasing │ └── readme.md ├── 15_cherry_picking │ └── readme.md ├── 16_picking_a_file_into_another_branch │ └── readme.md ├── 17_summaries │ └── Summary.pdf ├── 18_exercises │ └── Exercises.pdf └── readme.md ├── 05_collaboration ├── 01_workflow │ └── readme.md ├── 02_creating_a_github_repository │ └── readme.md ├── 03_adding_collaborators │ └── readme.md ├── 04_cloning_a_repository │ └── readme.md ├── 05_fetching_repository │ └── readme.md ├── 06_pulling │ └── readme.md ├── 07_pushing │ └── readme.md ├── 08_storing_credentials │ └── readme.md ├── 09_sharing_tags │ └── readme.md ├── 10_releases │ └── readme.md ├── 11_sharing_branches │ └── readme.md ├── 12_collaborating_workflow │ └── readme.md ├── 13_pull_requests │ └── readme.md ├── 14_resolving_conflicts │ └── readme.md ├── 15_issues │ └── readme.md ├── 16_custom_labels │ └── readme.md ├── 17_milestone │ └── readme.md ├── 18_forked_repository_up_to_date │ └── readme.md ├── 19_summary │ └── readme.md ├── 20_exercises │ └── readme.md └── readme.md ├── 06_rewriting_history ├── 01_why_rewriting_commit_history │ └── readme.md ├── 02_golden_rule_of_rewriting_history │ └── readme.md ├── 03_getting_bad_history_repository │ └── Mercury.zip ├── 04_undoing_commits │ └── readme.md ├── 05_reverting_commits │ └── readme.md ├── 06_recovering_lost_commits │ └── readme.md ├── 07_amending_the_last_commits │ └── readme.md ├── 08_amending_an_earlier_commit │ └── readme.md ├── 09_dropping_commits │ └── readme.md ├── 10_rewording_commits_messages │ └── readme.md ├── 11_reordering_commits │ └── readme.md ├── 12_squashing_commits │ └── readme.md ├── 13_splitting_commits │ └── readme.md ├── 14_summary │ └── Summary.pdf └── readme.md ├── 07_setting-up[oh-my-posh] ├── 1.Create bash_profile.PNG ├── 2.Open bash_profile in vs code.png ├── 3.Save json file.PNG ├── 4.Carriage return and line feed.png ├── 4.Configure oh my posh.PNG ├── 5.Final Result.PNG ├── iterm2.omp.json └── readme.md ├── 08_quiz └── readme.md ├── LISENCE ├── README.md └── commands.txt /.gitignore: -------------------------------------------------------------------------------- 1 | logs/ 2 | bin/ -------------------------------------------------------------------------------- /00_getting_started/01_configuring_git/crlf.md: -------------------------------------------------------------------------------- 1 | # Table of Contents 📑 2 | 1. [What is CRLF in Git?](#what-is-crlf-in-git-) 3 | 2. [Drawbacks of CRLF in Git ⚠️](#drawbacks-of-crlf-in-git-) 4 | 3. [Understanding `autocrlf` Settings 🔧](#understanding-autocrlf-settings-) 5 | 4. [When to Set `autocrlf`](#when-to-set-autocrlf-) 6 | 5. [Example: Handling Line Endings in Git 📂](#example-handling-line-endings-in-git-) 7 | 6. [Summary 📝](#summary-) 8 | 9 | 10 | ## What is CRLF in Git? ❓ 11 | 12 | **CRLF** stands for **Carriage Return** (`\r`) plus **Line Feed** (`\n`). These two characters together signify the end of a line and the start of a new one. Different operating systems use different line endings: 13 | 14 | - **Windows**: Uses CRLF (`\r\n`). 15 | - **Unix/Linux/macOS**: Uses only LF (`\n`). 16 | 17 | 18 | ## Drawbacks of CRLF in Git ⚠️ 19 | 20 | When working across different operating systems, differences in CRLF and LF can lead to several issues: 21 | 22 | 1. **Code Conflicts**: If one team member uses Windows and another uses Linux, the differing line endings can cause problems with Git diffs and merges. 23 | 2. **Version Control Issues**: Incorrect line endings can result in unnecessary changes being shown, making it difficult to identify actual code changes. 24 | 3. **Script Errors**: Scripts that expect specific line endings may throw errors if the line endings are incorrect. 25 | 26 | 27 | ## Understanding `autocrlf` Settings 🔧 28 | 29 | Git uses the `core.autocrlf` setting to manage line endings. There are three options: 30 | 31 | 1. **`true`**: Recommended for Windows users. Git stores LF in the repository and converts to CRLF when checking out files. 32 | 2. **`input`**: Recommended for Unix/Linux/macOS users. Git stores LF in the repository and does not perform any conversion when checking out files. 33 | 3. **`false`**: Git does not perform any conversion. The line endings in your files are stored as-is in the repository. 34 | 35 | 36 | ## When to Set `autocrlf` 📅 37 | 38 | - **Windows Users**: Set `core.autocrlf=true` to ensure that LF is stored in the repository while CRLF is used in the working directory. 39 | ```bash 40 | git config --global core.autocrlf true 41 | ``` 42 | - **Unix/Linux/macOS Users**: Set `core.autocrlf=input` to store LF in the repository and keep LF in the working directory. 43 | ```bash 44 | git config --global core.autocrlf input 45 | ``` 46 | 47 | 48 | ## Example: Handling Line Endings in Git 📂 49 | 50 | Let's create a simple text file and see how Git handles line endings. 51 | 52 | ### 1. Create a Text File 📝 53 | - **File Name**: `example.txt` 54 | - **Content**: 55 | ``` 56 | Hello World 57 | This is a Git example. 58 | ``` 59 | 60 | ### 2. Configure Git 🛠️ 61 | 62 | - **On Windows**: 63 | ```bash 64 | git config --global core.autocrlf true 65 | ``` 66 | - **On Linux/macOS**: 67 | ```bash 68 | git config --global core.autocrlf input 69 | ``` 70 | 71 | ### 3. Add and Commit the File 📥 72 | ```bash 73 | git add example.txt 74 | git commit -m "Add example text file" 75 | ``` 76 | 77 | ### 4. Line Endings in the Repository 🗃️ 78 | Regardless of the operating system, the repository stores line endings as LF (`\n`). 79 | 80 | ### 5. Line Endings Upon Checkout 📤 81 | 82 | - **On Windows**: When checking out the file, Git automatically converts LF to CRLF (`\r\n`). 83 | ``` 84 | Hello World\r\n 85 | This is a Git example.\r\n 86 | ``` 87 | - **On Unix/Linux/macOS**: When checking out the file, Git retains LF (`\n`). 88 | ``` 89 | Hello World\n 90 | This is a Git example.\n 91 | ``` 92 | 93 | 94 | ## Summary 📝 95 | 96 | Managing CRLF and LF line endings is crucial for cross-platform development. Git’s `core.autocrlf` setting simplifies this process: 97 | 98 | - **Windows**: Set `autocrlf=true` to handle CRLF conversions. 99 | - **Unix/Linux/macOS**: Set `autocrlf=input` to maintain LF line endings. 100 | -------------------------------------------------------------------------------- /00_getting_started/01_configuring_git/readme.md: -------------------------------------------------------------------------------- 1 | # 🛠️ Configuring Git on Windows 2 | 3 | This guide will help you configure Git with essential settings for Windows. Configuration can be done at three levels: **System**, **Global**, and **Local**. Let's dive in! 🚀 4 | 5 | ## 📑 Table of Contents 6 | 7 | 1. [**Git Configuration Levels**](#-git-configuration-levels) 🔧 8 | 2. [**Settings for the Global Level**](#-settings-for-the-global-level) 🌐 9 | - [1. Set Your Username](#-1-set-your-username) 👤 10 | - [2. Set Your Email](#-2-set-your-email) 📧 11 | - [3. Set Your Default Editor](#-3-set-your-default-editor) 📝 12 | - [4. View Your Global Configuration](#-4-view-your-global-configuration) 👀 13 | - [5. Configure Line Endings](#-5-configure-line-endings) 🔄 14 | - [6. Additional Line Ending Configuration (Optional)](#-6-additional-line-ending-configuration) ⚙️ 15 | 3. [**Common Mistake to Avoid**](#-common-mistake-to-avoid) ❌ 16 | 17 | 18 | ## 🔧 Git Configuration Levels 19 | 20 | Git configurations can be applied at three different levels, each with its own scope: 21 | 22 | - **System** 🖥️: Applies to all users on the system and all repositories. 23 | - **Global** 🌐: Applies to all repositories for the current user. 24 | - **Local** 📂: Applies only to the current repository. 25 | 26 | Understanding these levels helps in managing settings effectively across different projects and environments. 27 | 28 | 29 | ## 🌐 Settings for the Global Level 30 | 31 | Configuring Git at the global level sets preferences that apply to all repositories for the current user. Here are the essential settings you should configure: 32 | 33 | ### 👤 1. Set Your Username 34 | 35 | To set your username for all repositories of the current user: 36 | 37 | ```sh 38 | git config --global user.name "Muhammad Hashim" 39 | ``` 40 | 41 | *Note: Use double quotes because the name contains spaces.* 42 | 43 | ### 📧 2. Set Your Email 44 | 45 | To set your email address for all repositories of the current user: 46 | 47 | ```sh 48 | git config --global user.email hashiimtahir@gmail.com 49 | ``` 50 | 51 | *Note: Double quotes are not necessary here as there are no spaces.* 52 | 53 | ### 📝 3. Set Your Default Editor 54 | 55 | To set Visual Studio Code as your default editor: 56 | 57 | ```sh 58 | git config --global core.editor "code --wait" 59 | ``` 60 | 61 | *Note: The `--wait` option tells Git to wait until you close the editor before it continues processing.* 62 | 63 | ### 👀 4. View Your Global Configuration 64 | 65 | To view and edit the global configuration settings in Visual Studio Code: 66 | 67 | ```sh 68 | git config --global -e 69 | ``` 70 | 71 | *This command opens the global Git configuration file in VS Code.* 72 | 73 | ### 🔄 5. Configure Line Endings **[Read About CRLF](./crlf.md)** 74 | 75 | To avoid conflicts between different operating systems by normalizing line endings: 76 | 77 | ```sh 78 | git config --global core.autocrlf true 79 | ``` 80 | 81 | *Explanation: This setting converts line endings to `CRLF (\r\n)` on checkout and back to `LF (\n)` on commit. This helps in maintaining consistent line endings across different environments, particularly when working with Windows.* 82 | 83 | ### ⚙️ 6. Additional Line Ending Configuration 84 | 85 | If you are working across multiple platforms, you might consider using: 86 | 87 | ```bash 88 | git config --global core.autocrlf input 89 | ``` 90 | 91 | *Explanation: This setting converts `CRLF` to `LF` on commit but leaves files with `LF` in your working directory, which is typically the format used on Unix-based systems.* 92 | 93 | 94 | ## ❌ Common Mistake to Avoid 95 | 96 | - **Do not set `core.autocrlf` to `false` on Windows** unless you are certain that your team consistently uses `LF` line endings across all platforms. Setting it to `false` can cause inconsistencies in line endings, leading to potential issues when collaborating with developers on different operating systems. 97 | 98 | Regards, 99 | **Muhammad Hashim** 👨‍💻 100 | -------------------------------------------------------------------------------- /00_getting_started/02_getting_help/readme.md: -------------------------------------------------------------------------------- 1 | # 🛠️ Git Configuration Guide 2 | 3 | ## 📑 Table of Contents 4 | 5 | 1. [**Getting Help**](#-getting-help) 🆘 6 | 2. [**Checking Git Configurations**](#-checking-git-configurations) 🔍 7 | 3. [**Summary**](#-summary) 📝 8 | 9 | 10 | ## 🆘 Getting Help 11 | 12 | Need assistance with Git commands? Git provides built-in help options to guide you through various commands and their usages. Here's how you can access them: 13 | 14 | ### 🔍 Detailed Help 15 | 16 | To get comprehensive information about any Git command, use: 17 | 18 | ```bash 19 | git config --help 20 | ``` 21 | 22 | *This command provides detailed documentation, including descriptions of options and examples.* 23 | 24 | ### ⚡ Short Summary 25 | 26 | If you prefer a concise overview, use: 27 | 28 | ```bash 29 | git config --h 30 | ``` 31 | 32 | *This provides a brief summary of the command and its options.* 33 | 34 | ### 📜 Navigating Help Pages 35 | 36 | When viewing help pages, you can navigate using: 37 | - **Spacebar**: Move to the next page. 38 | - **'q'**: Quit the help view. 39 | 40 | ```bash 41 | git config --help 42 | git config --h 43 | ``` 44 | 45 | 46 | ## 🔍 Checking Git Configurations 47 | 48 | Keeping track of your Git configurations ensures that your environment is set up correctly. Here's how you can check your current settings: 49 | 50 | ### 📋 List All Configurations 51 | 52 | To view all the configurations set in your Git environment, use: 53 | 54 | ```bash 55 | git config -l 56 | ``` 57 | 58 | *This command lists all the configurations, including your username, email, editor preferences, and more.* 59 | 60 | 61 | ## 📝 Summary 62 | 63 | - **Get Detailed Help**: Use `git config --help` to access comprehensive documentation for Git commands. 64 | - **Get a Short Summary**: Use `git config --h` for a brief overview of Git commands and options. 65 | - **Check Current Configurations**: Use `git config -l` to list all your current Git settings. 66 | 67 | Regards 68 | **Muhammad Hashim** 👨‍💻 -------------------------------------------------------------------------------- /00_getting_started/readme.md: -------------------------------------------------------------------------------- 1 | # 🛠️ Git Installation and Configuration Guide 2 | 3 | Welcome to the **Git Installation and Configuration Guide**! 🚀 This document will walk you through the steps to install Git, configure it for your use, and access help when needed. Follow these instructions to get Git up and running on your system smoothly. 💻🔧 4 | 5 | ## 📑 Table of Contents 6 | 7 | 1. [**Step 1: Installing Git**](#step-1-installing-git) 🖥️ 8 | - [**Windows**](#-windows) 🪟 9 | - [**macOS**](#-macos) 🍎 10 | - [**Linux**](#-linux) 🐧 11 | 2. [**Step 2: Configuring Git**](#-step-2-configuring-git) ⚙️ 12 | - [**Set Your Username**](#-set-your-username) 👤 13 | - [**Set Your Email Address**](#-set-your-email-address) 📧 14 | - [**Verify Your Configuration**](#-verify-your-configuration) ✔️ 15 | 3. [**Step 3: Getting Help**](#-step-3-getting-help) 📚 16 | - [**Basic Help Command**](#-basic-help-command) 🆘 17 | - [**Alternative Help Commands**](#-alternative-help-commands) 🔄 18 | - [**Git Documentation**](#-git-documentation) 📄 19 | 4. [**Summary**](#-summary) 📝 20 | 21 | 22 | ## 🖥️ Step 1: Installing Git 23 | 24 | ### 🪟 Windows 25 | 26 | 1. **Download the Git Installer** 🖱️: 27 | - Visit the [Git for Windows](https://git-scm.com/download/win) website. 28 | - Download the latest version of the Git installer. 29 | 30 | 2. **Run the Installer** 🔄: 31 | - Double-click the downloaded `.exe` file to launch the installer. 32 | - Follow the prompts in the Git Setup wizard. It's recommended to use the default settings unless you have specific requirements. 33 | 34 | 3. **Verify the Installation** ✅: 35 | - Open the **Command Prompt** and type: 36 | ```sh 37 | git --version 38 | ``` 39 | - You should see the Git version number displayed, indicating that Git is installed successfully. 40 | 41 | ### 🍎 macOS 42 | 43 | 1. **Using Homebrew (Recommended)** 🏡: 44 | - If you don't have Homebrew installed, install it by running the following command in the **Terminal**: 45 | ```sh 46 | /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" 47 | ``` 48 | - Once Homebrew is installed, install Git by running: 49 | ```sh 50 | brew install git 51 | ``` 52 | 53 | 2. **Verify the Installation** ✅: 54 | - Open the **Terminal** and type: 55 | ```sh 56 | git --version 57 | ``` 58 | - You should see the Git version number displayed, indicating that Git is installed successfully. 59 | 60 | ### 🐧 Linux 61 | 62 | 1. **Using a Package Manager** 📦: 63 | - For **Debian-based** distributions (e.g., Ubuntu), run: 64 | ```sh 65 | sudo apt-get update 66 | sudo apt-get install git 67 | ``` 68 | - For **RPM-based** distributions (e.g., Fedora), run: 69 | ```sh 70 | sudo dnf install git 71 | ``` 72 | 73 | 2. **Verify the Installation** ✅: 74 | - Open the **Terminal** and type: 75 | ```sh 76 | git --version 77 | ``` 78 | - You should see the Git version number displayed, indicating that Git is installed successfully. 79 | 80 | 81 | ## ⚙️ Step 2 Configuring Git 82 | 83 | After installing Git, you need to configure it with your personal information. This information will be used for your commits. 📝 84 | 85 | ### 👤 Set Your Username 86 | 87 | ```sh 88 | git config --global user.name "Your Name" 89 | ``` 90 | 91 | *Replace `"Your Name"` with your actual name.* 92 | 93 | ### 📧 Set Your Email Address 94 | 95 | ```sh 96 | git config --global user.email "your.email@example.com" 97 | ``` 98 | 99 | *Replace `"your.email@example.com"` with your actual email address.* 100 | 101 | ### ✔️ Verify Your Configuration 102 | 103 | To verify your configuration, use the following command: 104 | 105 | ```sh 106 | git config --list 107 | ``` 108 | 109 | This command will display the current configuration, including your username and email. 📋 110 | 111 | 112 | ## 📚 Step 3: Getting Help 113 | 114 | Git provides a built-in help system to assist you with commands and their usage. Let's explore how to access and utilize these resources. 🆘 115 | 116 | ### 🆘 Basic Help Command 117 | 118 | To get help about any Git command, use: 119 | 120 | ```sh 121 | git help 122 | ``` 123 | 124 | *For example, to get help with the `commit` command:* 125 | 126 | ```sh 127 | git help commit 128 | ``` 129 | 130 | ### 🔄 Alternative Help Commands 131 | 132 | You can also use the following commands to access help: 133 | 134 | ```sh 135 | git --help 136 | ``` 137 | 138 | or 139 | 140 | ```sh 141 | git -h 142 | ``` 143 | 144 | *These alternatives provide the same assistance as the basic help command.* 145 | 146 | ### 📄 Git Documentation 147 | 148 | For comprehensive documentation, visit the [official Git documentation](https://git-scm.com/doc). 📖 Here, you'll find detailed guides, tutorials, and references to master Git's capabilities. 149 | 150 | 151 | ## 📝 Summary 152 | 153 | You have now successfully **installed Git**, **configured it** with your personal information, and **learned how to access help**. 🎉 You're ready to start using Git for version control in your projects, enabling efficient tracking and collaboration. Happy coding! 💻✨ 154 | 155 | 156 | Regards, 157 | **Muhammad Hashim** 👨‍💻 158 | -------------------------------------------------------------------------------- /01_creating_snapshots/01_initilizing_a_git/readme.md: -------------------------------------------------------------------------------- 1 | # 🛠️ Initializing a Git Repository 2 | 3 | This guide will help you initialize a Git repository in your project directory, setting the foundation for effective version control and collaboration. 🚀 4 | 5 | ## 📑 Table of Contents 6 | 7 | 1. [**1. Create a New Directory**](#-1-create-a-new-directory) 📁 8 | 2. [**2. Navigate to the Directory**](#-2-navigate-to-the-directory) 🔄 9 | 3. [**3. Initialize Git**](#-3-initialize-git) 🐙 10 | 4. [**Summary**](#-summary) 📝 11 | 12 | ## 📁 1. Create a New Directory 13 | 14 | First, create a new directory for your project. You can name it whatever you like. For example, let's create a directory named "Mars." 🌌 15 | 16 | ```bash 17 | mkdir Mars 18 | ``` 19 | 20 | *Example:* 21 | 22 | ```bash 23 | mkdir Mars 24 | ``` 25 | 26 | ## 🔄 2. Navigate to the Directory 27 | 28 | Navigate into the newly created directory using the `cd` (change directory) command. This moves you into the project folder where you'll initialize Git. 🛤️ 29 | 30 | ```bash 31 | cd Mars 32 | ``` 33 | 34 | *Example:* 35 | 36 | ```bash 37 | cd Mars 38 | ``` 39 | 40 | ## 🐙 3. Initialize Git 41 | 42 | Initialize a Git repository within the directory using the `git init` command. This command creates a hidden `.git` folder that tracks all changes and version history for your project. 📂 43 | 44 | ```bash 45 | git init 46 | ``` 47 | 48 | *Example:* 49 | 50 | ```bash 51 | git init 52 | ``` 53 | 54 | *What Happens Next:* 55 | - A new subdirectory named `.git` is created in your project directory. 56 | - This subdirectory contains all of your necessary repository files — a Git repository skeleton. 57 | - At this point, nothing in your project is tracked yet. You'll need to add files to start tracking changes. 58 | 59 | ## 📝 Summary 60 | 61 | - **Create a Directory**: Use `mkdir` to create a new project folder. 62 | - **Navigate to the Directory**: Use `cd` to move into your project folder. 63 | - **Initialize Git**: Use `git init` to set up a new Git repository. 64 | 65 | 🎉 **That's it!** 🎉 Your project directory is now a Git repository, and you can start tracking changes and collaborating with others using Git. 🛠️✨ 66 | 67 | Regards, 68 | **Muhammad Hashim** 👨‍💻 69 | -------------------------------------------------------------------------------- /01_creating_snapshots/02_staging_a_files/readme.md: -------------------------------------------------------------------------------- 1 | # 📂 Staging Files in Git 2 | 3 | ## 📑 Table of Contents 4 | 5 | 1. [**1. Create Files**](#-1-create-files) 📝 6 | 2. [**2. Check Status**](#-2-check-status) 🔍 7 | 3. [**3. Stage Files**](#-3-stage-files) ➕ 8 | 4. [**4. Verify Staging**](#-4-verify-staging) ✔️ 9 | 5. [**Summary**](#-summary) 📝 10 | 11 | 12 | ## 📝 1. Create Files 13 | 14 | First, create the files you want to stage. For example, let's create two text files named `file1.txt` and `file2.txt`. 🖊️ 15 | 16 | ```bash 17 | echo hello > file1.txt 18 | echo hello > file2.txt 19 | ``` 20 | 21 | *Example:* 22 | 23 | ```bash 24 | echo hello > file1.txt 25 | echo hello > file2.txt 26 | ``` 27 | 28 | *What This Does:* 29 | - **`echo hello > file1.txt`**: Creates a file named `file1.txt` with the content `hello`. 30 | - **`echo hello > file2.txt`**: Creates a file named `file2.txt` with the content `hello`. 31 | 32 | 33 | ## 🔍 2. Check Status 34 | 35 | Check the status of your working directory and staging area using the `git status` command. This helps you understand which changes are staged, unstaged, or untracked. 📊 36 | 37 | ```bash 38 | git status 39 | ``` 40 | 41 | *Example Output:* 42 | 43 | ``` 44 | On branch main 45 | Untracked files: 46 | (use "git add ..." to include in what will be committed) 47 | file1.txt 48 | file2.txt 49 | ``` 50 | 51 | *Explanation:* 52 | - **Untracked files**: Files that are not yet tracked by Git. They appear in red. 53 | 54 | 55 | ## ➕ 3. Stage Files 56 | 57 | Stage the files you want to include in the next commit using the `git add` command. Staging allows you to prepare specific changes for a commit. 📦 58 | 59 | ```bash 60 | git add *.txt # Stage all .txt files in the directory 61 | git add file1.txt # Stage a specific file 62 | git add . # Stage all changes in the current directory 63 | ``` 64 | 65 | *Examples:* 66 | 67 | 1. **Stage All `.txt` Files:** 68 | 69 | ```bash 70 | git add *.txt 71 | ``` 72 | 73 | *This command stages all files with the `.txt` extension in the current directory.* 74 | 75 | 2. **Stage a Specific File:** 76 | 77 | ```bash 78 | git add file1.txt 79 | ``` 80 | 81 | *This command stages only `file1.txt`.* 82 | 83 | 3. **Stage All Changes:** 84 | 85 | ```bash 86 | git add . 87 | ``` 88 | 89 | *This command stages all changes in the current directory, including new, modified, and deleted files.* 90 | 91 | *Tip:* Use `git add -A` to stage all changes across the entire repository. 92 | 93 | 94 | ## ✔️ 4. Verify Staging 95 | 96 | To verify that the files are staged, you can use `git status` again. This ensures that only the intended changes are prepared for the next commit. 🔍 97 | 98 | ```bash 99 | git status 100 | ``` 101 | 102 | *Example Output:* 103 | 104 | ``` 105 | On branch main 106 | Changes to be committed: 107 | (use "git restore --staged ..." to unstage) 108 | new file: file1.txt 109 | new file: file2.txt 110 | ``` 111 | 112 | *Explanation:* 113 | - **Changes to be committed**: Files listed here are staged and ready to be committed. They appear in green. 114 | 115 | 116 | ## 📝 Summary 117 | 118 | - **Create Files**: Use `echo` or your preferred method to create the files you want to stage. 119 | - **Check Status**: Use `git status` to view the current state of your working directory and staging area. 120 | - **Stage Files**: Use `git add` followed by the file name or pattern to stage specific files or all changes. 121 | - **Verify Staging**: Use `git status` again to ensure that the correct files are staged for the next commit. 122 | 123 | 124 | 🎉 **Great Job!** 🎉 You've successfully learned how to stage files in your Git repository. Staging is a crucial step in managing your commits effectively, allowing you to control which changes are included in each snapshot of your project. 🚀 125 | 126 | Regards, 127 | **Muhammad Hashim** 👨‍💻 128 | -------------------------------------------------------------------------------- /01_creating_snapshots/03_committing_changes/readme.md: -------------------------------------------------------------------------------- 1 | 2 | # ✍️ Committing Changes in Git 3 | ## 📑 Table of Contents 4 | 5 | 1. [**1. Commit with a Message Inline**](#-1-commit-with-a-message-inline) 📝 6 | 2. [**2. Commit with a Detailed Message**](#-2-commit-with-a-detailed-message) 🗒️ 7 | 3. [**Summary**](#-summary) 📝 8 | 9 | 10 | ## 📝 1. Commit with a Message Inline 11 | 12 | You can commit changes and add a commit message inline using the `-m` flag with the `git commit` command. This is a quick way to record changes with a concise message. 🚀 13 | 14 | ### 📌 Syntax 15 | 16 | ```bash 17 | git commit -m "Your commit message here" 18 | ``` 19 | 20 | ### 🛠️ Example 21 | 22 | ```bash 23 | git commit -m "Initial Commit" 24 | ``` 25 | 26 | ### 📝 Explanation 27 | 28 | - **`git commit`**: Records the staged changes in the repository. 29 | - **`-m "Initial Commit"`**: Adds a commit message inline. The message should briefly describe the changes made. 30 | 31 | *Best Practice:* Keep your commit messages clear and descriptive to make it easier to understand the history of your project. 32 | 33 | 34 | ## 🗒️ 2. Commit with a Detailed Message 35 | 36 | If you prefer to provide a detailed commit message along with a description, you can use `git commit` without the `-m` flag. This method opens a default text editor (usually Vim or Nano) where you can write a more comprehensive message. 🖋️ 37 | 38 | ### 📌 Syntax 39 | 40 | ```bash 41 | git commit 42 | ``` 43 | 44 | ### 🛠️ Example 45 | 46 | ```bash 47 | git commit 48 | ``` 49 | 50 | ### 📝 Steps 51 | 52 | 1. **Run the Commit Command**: Executing `git commit` without the `-m` flag will open your default text editor. 53 | 54 | 2. **Write Your Commit Message**: 55 | - **Subject Line**: Start with a brief summary of the changes (50 characters or less). 56 | - **Blank Line**: Leave a blank line after the subject. 57 | - **Detailed Description**: Provide a more detailed explanation of the changes, including the why and how. 58 | 59 | ``` 60 | Add user authentication feature 61 | 62 | Implemented user login and registration functionality. 63 | Added JWT token-based authentication. 64 | Updated the user model and authentication routes. 65 | ``` 66 | 67 | 3. **Save and Close the Editor**: 68 | - **Vim**: 69 | - Press `i` to enter insert mode. 70 | - Type your message. 71 | - Press `Esc`, then type `:wq` and hit `Enter` to save and quit. 72 | - **Nano**: 73 | - Type your message. 74 | - Press `Ctrl + O` to save, then `Ctrl + X` to exit. 75 | 76 | ### 📝 Explanation 77 | 78 | - **Detailed Commit Messages**: Providing a detailed message helps in understanding the context and reasoning behind changes, which is invaluable for future reference and collaboration. 79 | 80 | *Tip:* Use the imperative mood in your commit messages (e.g., "Add feature" instead of "Added feature") to maintain consistency. 81 | 82 | 83 | ## 📝 Summary 84 | 85 | - **Commit with a Brief Message Inline**: 86 | - Use `git commit -m "message"` to quickly commit changes with a concise message. 87 | - Ideal for small, straightforward changes. 88 | 89 | - **Commit with a Detailed Message**: 90 | - Use `git commit` to open an editor and add a comprehensive commit message. 91 | - Best for complex changes that require more explanation. 92 | 93 | 94 | 🎉 **Great Job!** 🎉 You've successfully learned how to commit changes in your Git repository with both brief and detailed messages. Committing thoughtfully is essential for maintaining a clear and understandable project history. 🚀 95 | 96 | 97 | **Regards,** 98 | **Muhammad Hashim** 👨‍💻 99 | -------------------------------------------------------------------------------- /01_creating_snapshots/04_skipping_the_staging_area/readme.md: -------------------------------------------------------------------------------- 1 | # 🚀 Skipping the Staging Area and Committing Changes 2 | 3 | ## 📑 Table of Contents 4 | 5 | 1. [**1. Make Changes to Files**](#-1-make-changes-to-files) ✏️ 6 | 2. [**2. Commit Changes Directly**](#-2-commit-changes-directly) 💾 7 | 3. [**Important Notes**](#-important-notes) ⚠️ 8 | 4. [**Summary**](#-summary) 📝 9 | 10 | 11 | ## ✏️ 1. Make Changes to Files 12 | 13 | First, make the necessary changes to the files in your working directory. For example, let's append the word "python" to `file1.txt`. 🖊️ 14 | 15 | ```bash 16 | echo python >> file1.txt 17 | ``` 18 | 19 | *Example:* 20 | 21 | ```bash 22 | echo python >> file1.txt 23 | ``` 24 | 25 | *What This Does:* 26 | - **`echo python >> file1.txt`**: Appends the word "python" to the end of `file1.txt`. If the file doesn't exist, it will be created with the content "python". 27 | 28 | 29 | ## 💾 2. Commit Changes Directly 30 | 31 | To skip the staging area and commit all modified files directly, you can use the `-a` flag with `git commit`. This will automatically stage any tracked files that have been modified and commit them with the provided message. 📦✍️ 32 | 33 | ### 📌 Syntax 34 | 35 | ```bash 36 | git commit -am "Your commit message here" 37 | ``` 38 | 39 | ### 🛠️ Example 40 | 41 | ```bash 42 | git commit -am "Add python to file1.txt" 43 | ``` 44 | 45 | ### 📝 Explanation 46 | 47 | - **`git commit`**: Records the changes in the repository. 48 | - **`-a`**: Automatically stages files that have been modified and deleted. New files (untracked) are **not** staged. 49 | - **`-m "Add python to file1.txt"`**: Adds a commit message inline describing the changes. 50 | 51 | *Best Practice:* Use this method for quick commits when you're certain about the changes you're committing. It streamlines the process but bypasses the opportunity to review changes before committing. 52 | 53 | 54 | ## ⚠️ Important Notes 55 | 56 | - **Use with Caution**: Only use this approach when you're certain that you don't need to review the changes before committing. It's convenient for quickly committing changes, but it bypasses the opportunity to review individual changes. 🛑 57 | 58 | - **For Tracked Files Only**: This command will **only** commit changes to tracked files. **Untracked files** will **not** be committed. To include new files, you need to stage them first using `git add`. 📂➡️📦 59 | 60 | 61 | ## 📝 Summary 62 | 63 | - **Make Changes to Files**: Modify your files as needed in the working directory. 64 | - **Commit Changes Directly**: Use `git commit -am "message"` to skip the staging area and commit all modified **tracked** files directly. 65 | - **Use with Caution**: Ensure you're comfortable with the changes being committed without prior review. 66 | - **Understand Limitations**: Only tracked files are affected; untracked files require explicit staging. 67 | 68 | 69 | 🎉 **Great Job!** 🎉 You've successfully learned how to skip the staging area and commit changes directly in your Git repository. This method is a powerful way to streamline your workflow when managing tracked files. 🚀 70 | 71 | **Regards,** 72 | **Muhammad Hashim** 👨‍💻 73 | -------------------------------------------------------------------------------- /01_creating_snapshots/05_removing_files/readme.md: -------------------------------------------------------------------------------- 1 | # 🗑️ Removing Files in Git 2 | 3 | Effectively managing your project's files is crucial for maintaining a clean and organized repository. This guide will walk you through the steps to remove files from both your directory and Git repository. 🚀 4 | 5 | ## 📑 Table of Contents 6 | 7 | 1. [**1. Remove File from Directory**](#-1-remove-file-from-directory) 🧹 8 | 2. [**2. Check Staging Area**](#-2-check-staging-area) 🔍 9 | 3. [**3. Remove from Staging Area**](#-3-remove-from-staging-area) ❌ 10 | 4. [**4. Commit Changes**](#-4-commit-changes) ✍️ 11 | 5. [**5. Check Staging Area Again**](#-5-check-staging-area-again) 🔄 12 | 6. [**6. Using `git rm` Command**](#-6-using-git-rm-command) 🛠️ 13 | 7. [**Summary**](#-summary) 📝 14 | 15 | 16 | ## 🧹 1. Remove File from Directory 17 | 18 | First, remove the file from your directory using the appropriate system command. For example, to remove `file2.txt`, you can use the `rm` command. 🗑️ 19 | 20 | ```bash 21 | rm file2.txt 22 | ``` 23 | 24 | *Example:* 25 | 26 | ```bash 27 | rm file2.txt 28 | ``` 29 | 30 | *What This Does:* 31 | - **`rm file2.txt`**: Deletes the `file2.txt` file from your working directory. 32 | 33 | *⚠️ Note:* Be cautious when using the `rm` command, as it permanently deletes files from your system. 34 | 35 | 36 | ## 🔍 2. Check Staging Area 37 | 38 | After removing the file, check the status of your repository to verify that the file is staged for deletion. This helps ensure that Git recognizes the removal. 📋 39 | 40 | ```bash 41 | git status 42 | ``` 43 | 44 | *Example Output:* 45 | 46 | ``` 47 | On branch main 48 | Changes to be committed: 49 | (use "git restore --staged ..." to unstage) 50 | deleted: file2.txt 51 | ``` 52 | 53 | *Explanation:* 54 | - **Deleted Files**: The output indicates that `file2.txt` is staged for deletion. 55 | 56 | 57 | ## ❌ 3. Remove from Staging Area 58 | 59 | If you decide not to delete the file after all, you can remove it from the staging area using the `git add` command. This will unstage the file without restoring it in the working directory. 🛑 60 | 61 | ```bash 62 | git add file2.txt 63 | ``` 64 | 65 | *Example:* 66 | 67 | ```bash 68 | git add file2.txt 69 | ``` 70 | 71 | *What This Does:* 72 | - **`git add file2.txt`**: Removes `file2.txt` from the staging area, effectively canceling the deletion. 73 | 74 | *Tip:* To restore the deleted file in your working directory, use `git restore file2.txt`. 75 | 76 | 77 | ## ✍️ 4. Commit Changes 78 | 79 | Once you're satisfied with the changes staged in your repository, commit them with an appropriate commit message. This records the removal in your project's history. 📝 80 | 81 | ```bash 82 | git commit -m "Remove file2.txt" 83 | ``` 84 | 85 | *Example:* 86 | 87 | ```bash 88 | git commit -m "Remove file2.txt" 89 | ``` 90 | 91 | *Explanation:* 92 | - **`git commit`**: Records the staged changes in the repository. 93 | - **`-m "Remove file2.txt"`**: Adds a commit message describing the change. 94 | 95 | *Best Practice:* Use clear and descriptive commit messages to make it easier to understand the project's history. 96 | 97 | 98 | ## 🔄 5. Check Staging Area Again 99 | 100 | After committing, verify that the file is no longer staged for deletion by listing the files in the staging area. This ensures that the removal has been successfully recorded. 🔄 101 | 102 | ```bash 103 | git ls-files 104 | ``` 105 | 106 | *Example Output:* 107 | 108 | ``` 109 | README.md 110 | file1.txt 111 | ``` 112 | 113 | *Explanation:* 114 | - **`git ls-files`**: Lists all files currently tracked by Git. `file2.txt` should no longer appear in the list. 115 | 116 | 117 | ## 🛠️ 6. Using `git rm` Command 118 | 119 | Alternatively, you can streamline the removal process by using the `git rm` command. This command removes the file from both the working directory and the staging area in one step. ⚡ 120 | 121 | ```bash 122 | git rm file2.txt 123 | ``` 124 | 125 | *Example:* 126 | 127 | ```bash 128 | git rm file2.txt 129 | ``` 130 | 131 | *What This Does:* 132 | - **`git rm file2.txt`**: Deletes `file2.txt` from your working directory and stages the deletion for the next commit. 133 | 134 | *⚠️ Note:* Ensure that you really want to delete the file, as this action is irreversible unless you have backups or the file exists in previous commits. 135 | 136 | *Committing the Removal:* 137 | 138 | After using `git rm`, don't forget to commit the change: 139 | 140 | ```bash 141 | git commit -m "Remove file2.txt using git rm" 142 | ``` 143 | 144 | 145 | ## 📝 Summary 146 | 147 | - **Remove the File from Directory**: Use system commands like `rm` to delete the file. 148 | - **Check Staging Area**: Use `git status` to verify that the file is staged for deletion. 149 | - **Remove from Staging Area (If Needed)**: Use `git add ` to unstage the file. 150 | - **Commit the Changes**: Use `git commit -m "message"` to record the removal. 151 | - **Check Staging Area Again**: Use `git ls-files` to ensure the file is no longer tracked. 152 | - **Alternatively, Use `git rm`**: Use `git rm ` to remove the file from both the directory and staging area in one step, then commit the change. 153 | 154 | **Regards,** 155 | **Muhammad Hashim** 👨‍💻 156 | -------------------------------------------------------------------------------- /01_creating_snapshots/06_renaming_or_removing_files/readme.md: -------------------------------------------------------------------------------- 1 | # 🔄 Renaming or Moving Files in Git 📁➡️📂 2 | Effectively managing your project's file structure is essential for maintaining an organized and efficient repository. This guide will walk you through the steps to **rename** or **move** files in your Git repository using both standard Unix commands and Git-specific commands. 🚀🛠️ 3 | 4 | ## 📑 Table of Contents 5 | 6 | 1. [**1. Rename or Move File Using Standard Unix Command**](#-1-rename-or-move-file-using-standard-unix-command) 🖋️🔄 7 | 2. [**2. Check Status**](#-2-check-status) 🔍📊 8 | 3. [**3. Stage Renamed File**](#-3-stage-renamed-file) ➕📂 9 | 4. [**4. Using `git mv` Command (Optional)**](#-4-using-git-mv-command-optional) 🛠️⚡ 10 | 5. [**Summary**](#-summary) 📝✅ 11 | 12 | 13 | ## 🖋️🔄 1. Rename or Move File Using Standard Unix Command 14 | Use the `mv` command to rename or move a file in your working directory. This method utilizes standard Unix commands and is effective for simple file operations. 🌟💻 15 | 16 | ### 📌 Syntax 17 | 18 | ```bash 19 | mv 20 | ``` 21 | 22 | ### 🛠️ Example 23 | 24 | Let's rename `file1.txt` to `main.js`: 25 | 26 | ```bash 27 | mv file1.txt main.js 28 | ``` 29 | 30 | ### 📝 Explanation 31 | 32 | - **`mv file1.txt main.js`**: This command renames the file `file1.txt` to `main.js`. If you specify a different directory in ``, it will move the file to that directory instead of renaming it. 📂➡️📁 33 | 34 | *⚠️ Note:* This method renames or moves the file in your working directory but does **not** automatically stage the change in Git. You'll need to manually stage the renamed or moved file. 🛑 35 | 36 | 37 | ## 🔍📊 2. Check Status 38 | After renaming or moving a file, it's essential to check the status of your repository to verify that Git recognizes the changes. 📋✅ 39 | 40 | ### 📌 Command 41 | 42 | ```bash 43 | git status 44 | ``` 45 | 46 | ### 🛠️ Example 47 | 48 | ```bash 49 | git status 50 | ``` 51 | 52 | ### 📝 Example Output 53 | 54 | ``` 55 | On branch main 56 | Changes not staged for commit: 57 | (use "git add ..." to update what will be committed) 58 | (use "git restore ..." to discard changes in working directory) 59 | renamed: file1.txt -> main.js 60 | ``` 61 | 62 | ### 📝 Explanation 63 | 64 | - **Renamed Files**: Git detects that `file1.txt` has been renamed to `main.js` but hasn't staged the change yet. 🔄📝 65 | - **Next Steps**: To include this change in your next commit, you need to stage the renamed file. 📂➡️📦 66 | 67 | 68 | ## ➕📂 3. Stage Renamed File 69 | Stage the renamed or moved file to prepare it for committing. This ensures that Git tracks the change correctly. 📂✍️ 70 | 71 | ### 📌 Command 72 | 73 | ```bash 74 | git add 75 | ``` 76 | 77 | ### 🛠️ Example 78 | 79 | ```bash 80 | git add main.js 81 | ``` 82 | 83 | ### 📝 Explanation 84 | 85 | - **`git add main.js`**: This command stages the renamed file `main.js`, indicating to Git that you want to include this change in your next commit. 📦✅ 86 | - **Why Stage?**: Staging allows you to review changes before committing, providing control over what gets recorded in your project's history. 🔍📜 87 | 88 | *💡 Tip:* You can also use `git add -A` to stage all changes, including renames, modifications, and deletions. 📋✨ 89 | 90 | 91 | ## 🛠️⚡ 4. Using `git mv` Command (Optional) 92 | Alternatively, you can use the `git mv` command to rename or move a file. This command simplifies the process by handling both the renaming/moving and staging in one step. ⚡🚀 93 | 94 | ### 📌 Syntax 95 | 96 | ```bash 97 | git mv 98 | ``` 99 | 100 | ### 🛠️ Example 101 | 102 | Let's rename `main.js` back to `file1.txt` using `git mv`: 103 | 104 | ```bash 105 | git mv main.js file1.txt 106 | ``` 107 | 108 | ### 📝 Explanation 109 | 110 | - **`git mv main.js file1.txt`**: This command renames `main.js` to `file1.txt` and stages the change simultaneously. 🔄📦 111 | - **Advantages**: 112 | - **Efficiency**: Combines renaming/moving and staging into a single command. ⚡🔧 113 | - **Clarity**: Makes it clear that the file has been moved or renamed within the context of Git. 📂➡️📁 114 | 115 | *⚠️ Note:* Ensure that the target name (`file1.txt` in this case) does not already exist in the directory to avoid conflicts. ❌📂 116 | 117 | ### 📝 Committing the Removal 118 | 119 | After using `git mv`, don't forget to commit the change: 120 | 121 | ```bash 122 | git commit -m "Rename main.js back to file1.txt using git mv" 123 | ``` 124 | 125 | *📢 Best Practice:* Use clear and descriptive commit messages to make it easier to understand the project's history. 📝🔍 126 | 127 | 128 | ## 📝✅ Summary 129 | - **Rename or Move Using Unix Commands**: 130 | - Use `mv` to rename or move files in your working directory. 131 | - *Example*: `mv file1.txt main.js` 🖋️🔄 132 | 133 | - **Check Repository Status**: 134 | - Use `git status` to verify that Git recognizes the renaming or moving. 🔍📊 135 | 136 | - **Stage the Changes**: 137 | - Use `git add ` to stage the renamed or moved file. ➕📂 138 | 139 | - **Alternatively, Use `git mv`**: 140 | - Use `git mv` to rename or move and stage the file in one step. 141 | - *Example*: `git mv main.js file1.txt` 🛠️⚡ 142 | 143 | - **Commit the Changes**: 144 | - Use `git commit -m "message"` to record the renaming or moving in your project's history. ✍️📦 145 | 146 | By following these steps, you can effectively **rename** or **move** files in your Git repository, ensuring that changes are accurately tracked and maintained in your project's history. 🔄📚 147 | 148 | 149 | **Regards,** 150 | **Muhammad Hashim** 👨‍💻🖥️ -------------------------------------------------------------------------------- /01_creating_snapshots/07_ignoring_files/readme.md: -------------------------------------------------------------------------------- 1 | # 🚫 Ignoring Files in Git 2 | 3 | Effectively managing which files Git tracks is crucial for maintaining a clean and efficient repository. This guide will walk you through the steps to **ignore** specific files and directories in your Git repository using a `.gitignore` file. 📂🔒 4 | 5 | ## 📑 Table of Contents 6 | 7 | 1. [**1. Create Directory and Files**](#-1-create-directory-and-files) 📁📝 8 | 2. [**2. Check Status**](#-2-check-status) 🔍📊 9 | 3. [**3. Create `.gitignore` File**](#-3-create-gitignore-file) 🗒️✏️ 10 | 4. [**4. Stage and Commit `.gitignore`**](#-4-stage-and-commit-gitignore) ➕✅ 11 | 5. [**5. Adjust `.gitignore` (Optional)**](#-5-adjust-gitignore-optional) 🛠️🔄 12 | 6. [**6. Update `.gitignore` and Remove from Staging**](#-6-update-gitignore-and-remove-from-staging) 📝🔄 13 | 7. [**7. Verify Changes**](#-7-verify-changes) ✔️🔍 14 | 8. [**Summary**](#-summary) 📝📋 15 | 16 | --- 17 | 18 | ## 📁📝 1. Create Directory and Files 19 | 20 | Start by creating directories and files that you want Git to ignore. For example, let's create a `logs` directory with a `dev.log` file, and a `bin` directory with an `app.bin` file. 🗃️📂 21 | 22 | ```bash 23 | mkdir logs 24 | echo Hello > logs/dev.log 25 | 26 | mkdir bin 27 | echo Hello > bin/app.bin 28 | ``` 29 | 30 | *What This Does:* 31 | - **`mkdir logs`**: Creates a new directory named `logs`. 32 | - **`echo Hello > logs/dev.log`**: Creates a file named `dev.log` inside the `logs` directory with the content `Hello`. 33 | - **`mkdir bin`**: Creates a new directory named `bin`. 34 | - **`echo Hello > bin/app.bin`**: Creates a file named `app.bin` inside the `bin` directory with the content `Hello`. 35 | 36 | --- 37 | 38 | ## 🔍📊 2. Check Status 39 | 40 | Check the status of your repository to see untracked files. This helps you identify which files are not being tracked by Git and might need to be ignored. 📋🔍 41 | 42 | ```bash 43 | git status 44 | ``` 45 | 46 | *Example Output:* 47 | 48 | ``` 49 | On branch main 50 | Untracked files: 51 | (use "git add ..." to include in what will be committed) 52 | bin/ 53 | logs/ 54 | ``` 55 | 56 | *Explanation:* 57 | - **Untracked files**: Files and directories that Git is not currently tracking. They appear in red and are listed under "Untracked files". 58 | 59 | --- 60 | 61 | ## 🗒️✏️ 3. Create `.gitignore` File 62 | 63 | Create a `.gitignore` file in your repository's root directory and specify the names of files or directories you want Git to ignore. 📝🚫 64 | 65 | ### 📌 Command 66 | 67 | ```bash 68 | echo logs/ > .gitignore 69 | ``` 70 | 71 | *Example:* 72 | 73 | ```bash 74 | echo logs/ > .gitignore 75 | ``` 76 | 77 | *What This Does:* 78 | - **`echo logs/ > .gitignore`**: Creates a `.gitignore` file and adds the `logs/` directory to it, instructing Git to ignore all files within the `logs` directory. 79 | 80 | *💡 Tip:* You can manually create a `.gitignore` file using a text editor and add multiple files or directories to ignore. 81 | 82 | --- 83 | 84 | ## ➕✅ 4. Stage and Commit `.gitignore` 85 | 86 | After creating the `.gitignore` file, stage and commit it to apply the ignore rules to your repository. 📂✅ 87 | 88 | ### 📌 Commands 89 | 90 | ```bash 91 | git add .gitignore 92 | git commit -m "Add .gitignore to ignore logs and bin directories" 93 | ``` 94 | 95 | *Example:* 96 | 97 | ```bash 98 | git add .gitignore 99 | git commit -m "Add .gitignore to ignore logs and bin directories" 100 | ``` 101 | 102 | *What This Does:* 103 | - **`git add .gitignore`**: Stages the `.gitignore` file for committing. 104 | - **`git commit -m "Add .gitignore to ignore logs and bin directories"`**: Commits the staged `.gitignore` file with a descriptive commit message. 105 | 106 | *📝 Explanation:* Committing the `.gitignore` file ensures that the ignore rules are part of your repository's history, making it easier for collaborators to maintain consistency. 107 | 108 | --- 109 | 110 | ## 🛠️🔄 5. Adjust `.gitignore` (Optional) 111 | 112 | If you accidentally committed a file before ignoring it, you can update the `.gitignore` file and remove the file from the repository's history. 🛠️📝 113 | 114 | ### 📌 Command 115 | 116 | ```bash 117 | echo bin/ >> .gitignore 118 | ``` 119 | 120 | *Example:* 121 | 122 | ```bash 123 | echo bin/ >> .gitignore 124 | ``` 125 | 126 | *What This Does:* 127 | - **`echo bin/ >> .gitignore`**: Appends the `bin/` directory to the existing `.gitignore` file, instructing Git to ignore all files within the `bin` directory. 128 | 129 | *💡 Tip:* Ensure that each entry in the `.gitignore` file is on a new line for clarity and effectiveness. 130 | 131 | --- 132 | 133 | ## 📝🔄 6. Update `.gitignore` and Remove from Staging 134 | 135 | Update the `.gitignore` file and remove the ignored files from the staging area using `git rm --cached`. This ensures that Git stops tracking these files while keeping them in your working directory. 📂🚫 136 | 137 | ### 📌 Commands 138 | 139 | ```bash 140 | git add .gitignore 141 | git rm --cached -r bin/ 142 | ``` 143 | 144 | *Example:* 145 | 146 | ```bash 147 | git add .gitignore 148 | git rm --cached -r bin/ 149 | ``` 150 | 151 | *What This Does:* 152 | - **`git add .gitignore`**: Stages the updated `.gitignore` file. 153 | - **`git rm --cached -r bin/`**: Removes the `bin/` directory from the staging area without deleting it from your local filesystem. 154 | 155 | *📝 Explanation:* The `--cached` flag tells Git to remove the files from tracking without deleting them from your system. The `-r` flag is used to remove directories recursively. 156 | 157 | --- 158 | 159 | ## ✔️🔍 7. Verify Changes 160 | 161 | Ensure that the ignored files are no longer staged by listing the files currently tracked by Git. ✅🔍 162 | 163 | ### 📌 Command 164 | 165 | ```bash 166 | git ls-files 167 | ``` 168 | 169 | *Example Output:* 170 | 171 | ``` 172 | .gitignore 173 | README.md 174 | file1.txt 175 | ``` 176 | 177 | *Explanation:* 178 | - **`git ls-files`**: Lists all files that are currently tracked by Git. The `bin/` directory should no longer appear in this list, indicating that it's successfully ignored. 179 | 180 | *💡 Tip:* Use `git status` to double-check that the ignored files no longer appear as untracked or staged changes. 181 | 182 | --- 183 | 184 | ## 📝📋 Summary 185 | 186 | - **Create Directory and Files**: Use system commands to create directories and files you want to ignore. 187 | - **Check Status**: Use `git status` to identify untracked files and directories. 188 | - **Create `.gitignore` File**: Specify files or directories to ignore by adding them to a `.gitignore` file. 189 | - **Stage and Commit `.gitignore`**: Apply the ignore rules by staging and committing the `.gitignore` file. 190 | - **Adjust `.gitignore` (Optional)**: Update the `.gitignore` file if you need to ignore additional files or directories. 191 | - **Update `.gitignore` and Remove from Staging**: Use `git rm --cached` to stop tracking files that should be ignored. 192 | - **Verify Changes**: Ensure that the ignored files are no longer tracked by Git using `git ls-files`. 193 | 194 | By following these steps, you can effectively **ignore** specific files and directories in your Git repository, keeping your project clean and free from unnecessary files. 🧹🔒 195 | -------------------------------------------------------------------------------- /01_creating_snapshots/09_viewing_staged_and_unstaged_changes/readme.md: -------------------------------------------------------------------------------- 1 | # 🔍 **Viewing Staged and Unstaged Changes in Git** 📂🔄 2 | 3 | Understanding the differences between staged and unstaged changes is crucial for effective version control. This guide explains how to view these changes in your repository using `git diff`, complete with explanations and examples. 🚀🛠️ 4 | 5 | ## 📑 Table of Contents 6 | 7 | 1. [**1. View Staged Changes**](#-1-view-staged-changes) 📝🔍 8 | 2. [**2. Compare Staging Copy with Last Commit**](#-2-compare-staging-copy-with-last-commit) 🔄📊 9 | 3. [**3. View Unstaged Changes**](#-3-view-unstaged-changes) 📝✏️ 10 | 4. [**4. Compare Untracked or Unstaged Changes**](#-4-compare-untracked-or-unstaged-changes) 🔍📂 11 | 5. [**Summary**](#-summary) 📝📋 12 | 13 | --- 14 | 15 | ## 📝🔍 1. View Staged Changes 16 | 17 | To see the differences between the last commit and the files currently staged for the next commit, use the `git diff --staged` command. This provides a clear view of what will be included when you make your next commit. 📂✅ 18 | 19 | ### 📌 Command 20 | 21 | ```bash 22 | git diff --staged 23 | ``` 24 | 25 | ### 🛠️ Example 26 | 27 | ```bash 28 | git diff --staged 29 | ``` 30 | 31 | ### 📝 Explanation 32 | 33 | - **`git diff --staged`**: Compares the staged changes with the last commit, showing what is ready to be committed. 34 | - **Use Case**: Ideal for reviewing changes before finalizing a commit to ensure accuracy and completeness. 35 | 36 | ### 📋 Example Output 37 | 38 | ```diff 39 | diff --git a/moon/main.js b/moon/main.js 40 | index e69de29..d95f3ad 100644 41 | --- a/moon/main.js 42 | +++ b/moon/main.js 43 | @@ -0,0 +1 @@ 44 | +console.log("Hello, Git!"); 45 | ``` 46 | 47 | - **`+`**: Lines added to the file. 48 | - **`-`**: Lines removed from the file. 49 | 50 | --- 51 | 52 | ## 🔄📊 2. Compare Staging Copy with Last Commit 53 | 54 | The `git diff --staged` command allows you to compare the version of the file in the staging area with the version in the last commit. This helps in understanding the exact changes that are staged for the next commit. 📈🔍 55 | 56 | ### 📌 Command 57 | 58 | ```bash 59 | git diff --staged 60 | ``` 61 | 62 | ### 🛠️ Example 63 | 64 | ```bash 65 | git diff --staged 66 | ``` 67 | 68 | ### 📝 Explanation 69 | 70 | - **Purpose**: To verify that the staged changes align with your intended modifications. 71 | - **Benefit**: Helps in catching any unintended changes before committing, ensuring a clean and accurate project history. 72 | 73 | ### 📋 Example Output 74 | 75 | ```diff 76 | diff --git a/moon/main.js b/moon/main.js 77 | index e69de29..d95f3ad 100644 78 | --- a/moon/main.js 79 | +++ b/moon/main.js 80 | @@ -0,0 +1 @@ 81 | +console.log("Hello, Git!"); 82 | ``` 83 | 84 | - **Interpretation**: The output shows that a new line has been added to `main.js`, which will be included in the next commit. 85 | 86 | --- 87 | 88 | ## 📝✏️ 3. View Unstaged Changes 89 | 90 | To view the differences between your working directory and the staging area, use the `git diff` command. This shows modifications that have not yet been staged for commit. 📂🔄 91 | 92 | ### 📌 Command 93 | 94 | ```bash 95 | git diff 96 | ``` 97 | 98 | ### 🛠️ Example 99 | 100 | ```bash 101 | git diff 102 | ``` 103 | 104 | ### 📝 Explanation 105 | 106 | - **`git diff`**: Displays changes that have been made to tracked files but are not yet staged. 107 | - **Use Case**: Useful for reviewing changes before deciding to stage them for commit. 108 | 109 | ### 📋 Example Output 110 | 111 | ```diff 112 | diff --git a/moon/main.js b/moon/main.js 113 | index d95f3ad..f3d2e1b 100644 114 | --- a/moon/main.js 115 | +++ b/moon/main.js 116 | @@ -1 +1 @@ 117 | -console.log("Hello, Git!"); 118 | +console.log("Hello, Python!"); 119 | ``` 120 | 121 | - **`+` and `-`**: Indicates lines added and removed, respectively. 122 | - **Interpretation**: Shows that the log message has been changed from "Hello, Git!" to "Hello, Python!". 123 | 124 | --- 125 | 126 | ## 🔍📂 4. Compare Untracked or Unstaged Changes 127 | 128 | Running `git diff` without any additional arguments compares the untracked or unstaged changes in the working directory with the version in the staging area. This helps in identifying what has been modified or added without being staged. 🆕 129 | 130 | ### 📌 Command 131 | 132 | ```bash 133 | git diff 134 | ``` 135 | 136 | ### 🛠️ Example 137 | 138 | ```bash 139 | git diff 140 | ``` 141 | 142 | ### 📝 Explanation 143 | 144 | - **Purpose**: To identify changes that have not been staged, including both modifications to tracked files and the addition of new untracked files. 145 | - **Benefit**: Enables you to decide which changes to stage and commit, maintaining control over your project's history. 146 | 147 | ### 📋 Example Output 148 | 149 | ```diff 150 | diff --git a/moon/main.js b/moon/main.js 151 | index d95f3ad..f3d2e1b 100644 152 | --- a/moon/main.js 153 | +++ b/moon/main.js 154 | @@ -1 +1 @@ 155 | -console.log("Hello, Git!"); 156 | +console.log("Hello, Python!"); 157 | ``` 158 | 159 | - **Untracked Files**: New files that have been created but not yet added to the staging area will appear under "Untracked files" when you run `git status`, but they won't appear in the `git diff` output unless you explicitly add them. 160 | 161 | --- 162 | 163 | ## 📝📋 Summary 164 | 165 | - **1. View Staged Changes**: 166 | - **Command**: `git diff --staged` 167 | - **Purpose**: Shows differences between the last commit and the staging area. 168 | - **Use Case**: Review changes before committing. 169 | 170 | - **2. Compare Staging Copy with Last Commit**: 171 | - **Command**: `git diff --staged` 172 | - **Purpose**: Understand exact changes staged for the next commit. 173 | - **Benefit**: Ensure accuracy in your commits. 174 | 175 | - **3. View Unstaged Changes**: 176 | - **Command**: `git diff` 177 | - **Purpose**: Displays modifications not yet staged. 178 | - **Use Case**: Review changes before deciding to stage them. 179 | 180 | - **4. Compare Untracked or Unstaged Changes**: 181 | - **Command**: `git diff` 182 | - **Purpose**: Identifies both modified and untracked changes. 183 | - **Benefit**: Helps in managing what to stage and commit. 184 | -------------------------------------------------------------------------------- /01_creating_snapshots/10_visual_diff_tools/readme.md: -------------------------------------------------------------------------------- 1 | # 🖥️🔍 Visual Diff Tools in Git 2 | 3 | Enhancing your Git workflow with visual diff tools can significantly improve your ability to compare and understand changes. This guide outlines the process of configuring and using Visual Diff Tools, with **VS Code** as an example, for comparing files side by side. 🚀🔧 4 | 5 | ## 📑 Table of Contents 6 | 7 | 1. [**1. Configure Global Diff Tool**](#-1-configure-global-diff-tool) 🛠️🌐 8 | 2. [**2. Set VS Code as Diff Tool**](#-2-set-vs-code-as-diff-tool) 🖥️✏️ 9 | 3. [**3. Open Global Git Configuration for Editing**](#-3-open-global-git-configuration-for-editing) 📂🔄 10 | 4. [**4. Use Visual Diff Tool for Unstaged Changes**](#-4-use-visual-diff-tool-for-unstaged-changes) 🔍📁 11 | 5. [**5. Compare Staged Changes**](#-5-compare-staged-changes) 📊🗂️ 12 | 6. [**Summary**](#-summary) 📝✅ 13 | 14 | --- 15 | 16 | ## 🛠️🌐 1. Configure Global Diff Tool 17 | 18 | Start by setting the default visual diff tool globally. This ensures that Git uses your preferred tool across all repositories. In this example, we'll configure **VS Code** as the default diff tool. 🖥️✨ 19 | 20 | ### 📌 Command 21 | 22 | ```bash 23 | git config --global diff.tool vscode 24 | ``` 25 | 26 | ### 🛠️ Example 27 | 28 | ```bash 29 | git config --global diff.tool vscode 30 | ``` 31 | 32 | ### 📝 Explanation 33 | 34 | - **`git config --global diff.tool vscode`**: Sets **VS Code** as the default diff tool for all Git repositories on your system. You can replace `vscode` with any other diff tool name if you prefer a different one. 🌟 35 | 36 | *💡 Tip:* Ensure that your chosen diff tool is installed and properly configured on your system to avoid any conflicts or issues. 37 | 38 | --- 39 | 40 | ## 🖥️✏️ 2. Set VS Code as Diff Tool 41 | 42 | Next, configure **VS Code** specifically as the diff tool by defining the command Git should use to launch it. This command tells Git how to open the two versions of a file side by side in **VS Code**. 📂🔍 43 | 44 | ### 📌 Command 45 | 46 | ```bash 47 | git config --global difftool.vscode.cmd "code --wait --diff $LOCAL $REMOTE" 48 | ``` 49 | 50 | ### 🛠️ Example 51 | 52 | ```bash 53 | git config --global difftool.vscode.cmd "code --wait --diff $LOCAL $REMOTE" 54 | ``` 55 | 56 | ### 📝 Explanation 57 | 58 | - **`git config --global difftool.vscode.cmd "code --wait --diff $LOCAL $REMOTE"`**: Configures **VS Code** to open in diff mode, comparing the local (current) and remote (previous) versions of a file. The `--wait` flag ensures that Git waits for you to close **VS Code** before proceeding. 🔄💻 59 | 60 | *💡 Tip:* The placeholders `$LOCAL` and `$REMOTE` represent the file paths for the versions you are comparing. Ensure these are correctly referenced in your environment. 61 | 62 | --- 63 | 64 | ## 📂🔄 3. Open Global Git Configuration for Editing 65 | 66 | Sometimes, you may need to manually edit the global Git configuration file to make further adjustments or verify settings. This command opens the global Git configuration file in your default editor (now configured as **VS Code**). 📝🔧 67 | 68 | ### 📌 Command 69 | 70 | ```bash 71 | git config --global -e 72 | ``` 73 | 74 | ### 🛠️ Example 75 | 76 | ```bash 77 | git config --global -e 78 | ``` 79 | 80 | ### 📝 Explanation 81 | 82 | - **`git config --global -e`**: Opens the global Git configuration file (`~/.gitconfig`) in your default editor (**VS Code**, as configured). Here, you can manually edit settings, add new configurations, or verify existing ones. 📂🔍 83 | 84 | *💡 Tip:* Familiarize yourself with the Git configuration file structure to make effective and error-free edits. 85 | 86 | --- 87 | 88 | ## 🔍📁 4. Use Visual Diff Tool for Unstaged Changes 89 | 90 | To compare unstaged changes in your working directory with the staging area, use the `git difftool` command. This opens the configured visual diff tool (**VS Code**) to display differences side by side. 🔄🖥️ 91 | 92 | ### 📌 Command 93 | 94 | ```bash 95 | git difftool 96 | ``` 97 | 98 | ### 🛠️ Example 99 | 100 | ```bash 101 | git difftool 102 | ``` 103 | 104 | ### 📝 Explanation 105 | 106 | - **`git difftool`**: Launches the configured visual diff tool to compare unstaged changes in your working directory with the staging area. This helps you visually inspect modifications before staging or committing them. 🖼️🔍 107 | 108 | *💡 Tip:* You can use `git difftool ` to compare a specific file rather than all changes. 109 | 110 | --- 111 | 112 | ## 📊🗂️ 5. Compare Staged Changes 113 | 114 | To view differences for changes that have been staged but not yet committed, use the `git difftool --staged` command. This allows you to review what exactly will be included in your next commit. 📝📋 115 | 116 | ### 📌 Command 117 | 118 | ```bash 119 | git difftool --staged 120 | ``` 121 | 122 | ### 🛠️ Example 123 | 124 | ```bash 125 | git difftool --staged 126 | ``` 127 | 128 | ### 📝 Explanation 129 | 130 | - **`git difftool --staged`**: Opens the visual diff tool to compare staged changes with the last commit. This ensures that you are aware of all modifications that are about to be committed. 🔍📂 131 | 132 | *💡 Tip:* Regularly reviewing staged changes helps maintain a clean and accurate commit history. 133 | 134 | --- 135 | 136 | ## 📝✅ Summary 137 | 138 | - **1. Configure Global Diff Tool**: 139 | - **Command**: `git config --global diff.tool vscode` 🛠️🌐 140 | - **Purpose**: Sets **VS Code** as the default visual diff tool globally. 141 | 142 | - **2. Set VS Code as Diff Tool**: 143 | - **Command**: `git config --global difftool.vscode.cmd "code --wait --diff $LOCAL $REMOTE"` 🖥️✏️ 144 | - **Purpose**: Defines how **VS Code** should be launched for diff operations. 145 | 146 | - **3. Open Global Git Configuration for Editing**: 147 | - **Command**: `git config --global -e` 📂🔄 148 | - **Purpose**: Opens the global Git configuration file in your default editor for manual adjustments. 149 | 150 | - **4. Use Visual Diff Tool for Unstaged Changes**: 151 | - **Command**: `git difftool` 🔍📁 152 | - **Purpose**: Compares unstaged changes using the configured visual diff tool. 153 | 154 | - **5. Compare Staged Changes**: 155 | - **Command**: `git difftool --staged` 📊🗂️ 156 | - **Purpose**: Compares staged changes with the last commit to review before committing. 157 | 158 | -------------------------------------------------------------------------------- /01_creating_snapshots/11_viewing_a_commit_history/readme.md: -------------------------------------------------------------------------------- 1 | # 📜 Viewing Commit History in Git 🔍✨ 2 | 3 | Understanding your project's commit history is essential for tracking changes, collaborating effectively, and maintaining a clear project timeline. This guide explains how to view the commit history of a Git repository using various options of the `git log` command, complete with explanations and examples. 🚀🛠️ 4 | 5 | ## 📑 Table of Contents 6 | 7 | 1. [**1. Comprehensive Commit History**](#-1-comprehensive-commit-history) 📚🔍 8 | 2. [**2. Shortened Commit History**](#-2-shortened-commit-history) 📝📄 9 | 3. [**3. Shortened Commit History in Reverse Order**](#-3-shortened-commit-history-in-reverse-order) 🔄🕰️ 10 | 4. [**Summary**](#-summary) 📝✅ 11 | 12 | --- 13 | 14 | ## 📚🔍 1. Comprehensive Commit History 15 | 16 | To view a detailed commit history, use the `git log` command. This command displays comprehensive information about each commit, including the commit hash, author, date, and commit message. 📋🔎 17 | 18 | ### 📌 Command 19 | 20 | ```bash 21 | git log 22 | ``` 23 | 24 | ### 🛠️ Example 25 | 26 | ```bash 27 | git log 28 | ``` 29 | 30 | ### 📝 Explanation 31 | 32 | - **`git log`**: Displays the full commit history of the current branch. 33 | - **Details Shown**: 34 | - **Commit Hash**: A unique identifier for each commit. 35 | - **Author**: The name and email of the person who made the commit. 36 | - **Date**: When the commit was made. 37 | - **Commit Message**: A description of the changes introduced in the commit. 38 | 39 | ### 📋 Example Output 40 | 41 | ``` 42 | commit e1a2b3c4d5e6f7g8h9i0j1k2l3m4n5o6p7q8r9s0 43 | Author: Jane Doe 44 | Date: Mon Aug 30 14:22:35 2023 -0400 45 | 46 | Implement user authentication feature 47 | ``` 48 | 49 | - **Interpretation**: 50 | - **Commit Hash**: `e1a2b3c4d5e6f7g8h9i0j1k2l3m4n5o6p7q8r9s0` 51 | - **Author**: Jane Doe 52 | - **Date**: August 30, 2023 53 | - **Commit Message**: Implement user authentication feature 54 | 55 | --- 56 | 57 | ## 📝📄 2. Shortened Commit History 58 | 59 | For a more concise view of the commit history, use the `--oneline` option with `git log`. This displays each commit as a single line with an abbreviated commit hash and commit message. 📃✂️ 60 | 61 | ### 📌 Command 62 | 63 | ```bash 64 | git log --oneline 65 | ``` 66 | 67 | ### 🛠️ Example 68 | 69 | ```bash 70 | git log --oneline 71 | ``` 72 | 73 | ### 📝 Explanation 74 | 75 | - **`git log --oneline`**: Provides a streamlined view of the commit history. 76 | - **Details Shown**: 77 | - **Abbreviated Commit Hash**: A shortened version of the full commit hash. 78 | - **Commit Message**: A brief description of the changes. 79 | 80 | ### 📋 Example Output 81 | 82 | ``` 83 | e1a2b3c Implement user authentication feature 84 | d4e5f6g Fix bug in payment processing 85 | a7b8c9d Update README with installation instructions 86 | ``` 87 | 88 | - **Interpretation**: 89 | - **`e1a2b3c`**: Abbreviated commit hash. 90 | - **Commit Messages**: Brief summaries of each commit. 91 | 92 | *💡 Tip:* This format is ideal for quickly scanning through the commit history without the clutter of detailed information. 93 | 94 | --- 95 | 96 | ## 🔄🕰️ 3. Shortened Commit History in Reverse Order 97 | 98 | To view the commit history starting from the oldest commits first, combine the `--oneline` and `--reverse` options. This displays a shortened commit history in reverse chronological order. ⏪🔄 99 | 100 | ### 📌 Command 101 | 102 | ```bash 103 | git log --oneline --reverse 104 | ``` 105 | 106 | ### 🛠️ Example 107 | 108 | ```bash 109 | git log --oneline --reverse 110 | ``` 111 | 112 | ### 📝 Explanation 113 | 114 | - **`git log --oneline --reverse`**: Shows the commit history in a compact form, starting from the earliest commits. 115 | - **Use Case**: Useful for understanding the chronological progression of a project from its inception. 116 | 117 | ### 📋 Example Output 118 | 119 | ``` 120 | a7b8c9d Update README with installation instructions 121 | d4e5f6g Fix bug in payment processing 122 | e1a2b3c Implement user authentication feature 123 | ``` 124 | 125 | - **Interpretation**: 126 | - The commits are listed from the oldest (`a7b8c9d`) to the newest (`e1a2b3c`). 127 | 128 | *💡 Tip:* Combining these options helps in presenting the commit history in a logical and easy-to-follow sequence. 129 | 130 | --- 131 | 132 | ## 📝✅ Summary 133 | 134 | - **1. Comprehensive Commit History**: 135 | - **Command**: `git log` 📚🔍 136 | - **Purpose**: Displays detailed information about each commit. 137 | - **Use Case**: Ideal for in-depth analysis of commit details. 138 | 139 | - **2. Shortened Commit History**: 140 | - **Command**: `git log --oneline` 📝📄 141 | - **Purpose**: Provides a concise overview of commits. 142 | - **Use Case**: Perfect for quick scans of commit history. 143 | 144 | - **3. Shortened Commit History in Reverse Order**: 145 | - **Command**: `git log --oneline --reverse` 🔄🕰️ 146 | - **Purpose**: Shows commits starting from the oldest first in a brief format. 147 | - **Use Case**: Useful for understanding the project's development timeline. 148 | 149 | -------------------------------------------------------------------------------- /01_creating_snapshots/13_unstaging_files/readme.md: -------------------------------------------------------------------------------- 1 | # 🔄 Unstaging Files in Git 🗂️❌ 2 | 3 | Managing your staging area effectively is crucial for maintaining a clean and organized commit history. This guide explains how to **undo staging changes** and **restore files to the unstaged state** using the `git restore --staged` command. 🚀🛠️ 4 | 5 | ## 📑 Table of Contents 6 | 7 | 1. [**1. Make Changes to a File**](#-1-make-changes-to-a-file) ✏️📄 8 | 2. [**2. Add Changes to Staging Area**](#-2-add-changes-to-staging-area) ➕📂 9 | 3. [**3. Undo Staging Changes**](#-3-undo-staging-changes) 🔄❌ 10 | 4. [**Summary**](#-summary) 📝📋 11 | 12 | --- 13 | 14 | ## ✏️📄 1. Make Changes to a File 15 | 16 | Start by making changes to a file in your working directory. This could involve modifying existing content or adding new content. 🖋️✨ 17 | 18 | ### 📌 Command 19 | 20 | ```bash 21 | echo fishes >> moon/main.js 22 | ``` 23 | 24 | ### 🛠️ Example 25 | 26 | ```bash 27 | echo fishes >> moon/main.js 28 | ``` 29 | 30 | ### 📝 Explanation 31 | 32 | - **`echo fishes >> moon/main.js`**: Appends the word "fishes" to the end of the `main.js` file located in the `moon` directory. If the file doesn't exist, it will be created with the content "fishes". 33 | 34 | *💡 Tip:* Regularly saving changes helps in tracking progress and maintaining an accurate history of modifications. 35 | 36 | --- 37 | 38 | ## ➕📂 2. Add Changes to Staging Area 39 | 40 | After modifying the file, add the changes to the staging area. This prepares the changes to be included in the next commit. 📥✅ 41 | 42 | ### 📌 Command 43 | 44 | ```bash 45 | git add moon/main.js 46 | ``` 47 | 48 | ### 🛠️ Example 49 | 50 | ```bash 51 | git add moon/main.js 52 | ``` 53 | 54 | ### 📝 Explanation 55 | 56 | - **`git add moon/main.js`**: Stages the changes made to `main.js`, indicating to Git that these changes should be included in the next commit. 57 | 58 | *💡 Tip:* Use `git add .` to stage all changes in the current directory and its subdirectories. 59 | 60 | --- 61 | 62 | ## 🔄❌ 3. Undo Staging Changes 63 | 64 | If you decide that you do not want to include the staged changes in your next commit, you can **undo staging** and move the changes back to the unstaged state. This allows you to modify or discard changes before committing. 🔄🛑 65 | 66 | ### 📌 Command 67 | 68 | ```bash 69 | git restore --staged moon/main.js 70 | ``` 71 | 72 | ### 🛠️ Example 73 | 74 | ```bash 75 | git restore --staged moon/main.js 76 | ``` 77 | 78 | ### 📝 Explanation 79 | 80 | - **`git restore --staged moon/main.js`**: Removes `main.js` from the staging area, moving the changes back to the unstaged state. The file remains modified in your working directory. 81 | 82 | *⚠️ Note:* This command does not discard your changes; it simply unstages them. Your modifications remain intact and can be re-staged or discarded as needed. 83 | 84 | *💡 Tip:* To discard the unstaged changes and revert the file to its last committed state, use: 85 | 86 | ```bash 87 | git restore moon/main.js 88 | ``` 89 | 90 | --- 91 | 92 | ## 📝📋 Summary 93 | 94 | - **1. Make Changes to a File**: Modify or add content to your files using commands like `echo`. 95 | 96 | - *Example*: `echo fishes >> moon/main.js` ✏️📄 97 | 98 | - **2. Add Changes to Staging Area**: Stage the modified files to prepare them for commit. 99 | 100 | - *Command*: `git add moon/main.js` ➕📂 101 | 102 | - **3. Undo Staging Changes**: Remove files from the staging area to move changes back to unstaged state. 103 | 104 | - *Command*: `git restore --staged moon/main.js` 🔄❌ 105 | 106 | -------------------------------------------------------------------------------- /01_creating_snapshots/15_restoring_a_file_to_an_earlier_version/readme.md: -------------------------------------------------------------------------------- 1 | # 🔄 Restoring a File to an Earlier in Git 📂✨ 2 | 3 | Sometimes, you may need to revert a file to its previous state due to mistakes or changes that are no longer needed. This guide explains how to **restore a file to an earlier version** in your Git repository using the `git restore` command, complete with explanations and examples. 🚀🛠️ 4 | 5 | ## 📑 Table of Contents 6 | 7 | 1. [**1. Remove the File from the Repository**](#-1-remove-the-file-from-the-repository) 🗑️🚫 8 | 2. [**2. Commit the Changes**](#-2-commit-the-changes) ✍️📁 9 | 3. [**3. View Help Information for Restore**](#-3-view-help-information-for-restore) ❓🛠️ 10 | 4. [**4. Restore File to an Earlier Version**](#-4-restore-file-to-an-earlier-version) 🔄📂 11 | 5. [**Summary**](#-summary) 📝📋 12 | 13 | --- 14 | 15 | ## 🗑️🚫 1. Remove the File from the Repository 16 | 17 | Before restoring a file to an earlier version, you may need to remove it from the repository. This step ensures that the file is deleted from both the working directory and the staging area. 🛠️❌ 18 | 19 | ### 📌 Command 20 | 21 | ```bash 22 | git rm moon/file.js 23 | ``` 24 | 25 | ### 🛠️ Example 26 | 27 | ```bash 28 | git rm moon/file.js 29 | ``` 30 | 31 | ### 📝 Explanation 32 | 33 | - **`git rm moon/file.js`**: Removes the file `file.js` from the `moon` directory in both the working directory and the staging area. 34 | 35 | *What This Does:* 36 | - **Working Directory**: Deletes the physical file from your local machine. 37 | - **Staging Area**: Marks the file for removal in the next commit. 38 | 39 | *💡 Tip:* Ensure that you truly want to remove the file before executing this command, as it will delete the file from your working directory. 40 | 41 | --- 42 | 43 | ## ✍️📁 2. Commit the Changes 44 | 45 | After removing the file, you need to commit the change to update the repository's history. This records the removal of the file in the project's commit history. 📂✅ 46 | 47 | ### 📌 Command 48 | 49 | ```bash 50 | git commit -m "Remove file.js" 51 | ``` 52 | 53 | ### 🛠️ Example 54 | 55 | ```bash 56 | git commit -m "Remove file.js" 57 | ``` 58 | 59 | ### 📝 Explanation 60 | 61 | - **`git commit -m "Remove file.js"`**: Commits the staged changes with the message "Remove file.js". 62 | 63 | *What This Does:* 64 | - **Commit Message**: Clearly documents the removal of `file.js`, aiding in future reference and collaboration. 65 | 66 | *💡 Tip:* Use clear and descriptive commit messages to maintain an understandable project history. 67 | 68 | --- 69 | 70 | ## ❓🛠️ 3. View Help Information for Restore 71 | 72 | Familiarize yourself with the `git restore` command by viewing its help information. This provides details on available options and usage patterns. 📚🔍 73 | 74 | ### 📌 Command 75 | 76 | ```bash 77 | git restore -h 78 | ``` 79 | 80 | ### 🛠️ Example 81 | 82 | ```bash 83 | git restore -h 84 | ``` 85 | 86 | ### 📝 Explanation 87 | 88 | - **`git restore -h`**: Displays the help information for the `git restore` command, outlining its various options and usage scenarios. 89 | 90 | *What This Does:* 91 | - **Help Documentation**: Provides a summary of commands and flags available for `git restore`, assisting in effective usage. 92 | 93 | *💡 Tip:* Reviewing help information is a good practice to understand the capabilities and syntax of Git commands. 94 | 95 | --- 96 | 97 | ## 🔄📂 4. Restore File to an Earlier Version 98 | 99 | Finally, restore the file to its state from a previous commit using the `git restore` command. This brings back the file as it was at the specified commit. 🖥️🔄 100 | 101 | ### 📌 Command 102 | 103 | ```bash 104 | git restore --source=HEAD~1 moon/file.js 105 | ``` 106 | 107 | ### 🛠️ Example 108 | 109 | ```bash 110 | git restore --source=HEAD~1 moon/file.js 111 | ``` 112 | 113 | ### 📝 Explanation 114 | 115 | - **`git restore --source=HEAD~1 moon/file.js`**: Restores the file `file.js` in the `moon` directory to its state from one commit before the current HEAD. 116 | 117 | *What This Does:* 118 | - **`--source=HEAD~1`**: Specifies the commit from which to restore the file. `HEAD~1` refers to the immediate parent commit of the current HEAD. 119 | - **File Restoration**: Reverts `file.js` to how it existed in the specified commit, effectively undoing changes made in subsequent commits. 120 | 121 | *⚠️ Warning:* Restoring files to earlier versions can overwrite current changes. Ensure that you do not need the latest modifications before performing this action. 122 | 123 | *💡 Tip:* To restore multiple files or entire directories, specify their paths accordingly or use wildcards as needed. 124 | 125 | --- 126 | 127 | ## 📝📋 Summary 128 | 129 | - **1. Remove the File from the Repository**: 130 | - **Command**: `git rm moon/file.js` 🗑️🚫 131 | - **Purpose**: Deletes `file.js` from both the working directory and staging area. 132 | 133 | - **2. Commit the Changes**: 134 | - **Command**: `git commit -m "Remove file.js"` ✍️📁 135 | - **Purpose**: Records the removal of the file in the commit history. 136 | 137 | - **3. View Help Information for Restore**: 138 | - **Command**: `git restore -h` ❓🛠️ 139 | - **Purpose**: Displays help information for the `git restore` command. 140 | 141 | - **4. Restore File to an Earlier Version**: 142 | - **Command**: `git restore --source=HEAD~1 moon/file.js` 🔄📂 143 | - **Purpose**: Reverts `file.js` to its state from one commit prior, restoring previous content. 144 | 145 | -------------------------------------------------------------------------------- /01_creating_snapshots/17_summary_of_commands/Summary.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HashimThePassionate/learn-git-mastery/cb2e79c89c470d5d8ab5d6a525a4a1494e11c2bb/01_creating_snapshots/17_summary_of_commands/Summary.pdf -------------------------------------------------------------------------------- /01_creating_snapshots/18_exercise_of_question/Exercises.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HashimThePassionate/learn-git-mastery/cb2e79c89c470d5d8ab5d6a525a4a1494e11c2bb/01_creating_snapshots/18_exercise_of_question/Exercises.pdf -------------------------------------------------------------------------------- /03_browsing_history/01_getting_a_repository/Venus.zip: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HashimThePassionate/learn-git-mastery/cb2e79c89c470d5d8ab5d6a525a4a1494e11c2bb/03_browsing_history/01_getting_a_repository/Venus.zip -------------------------------------------------------------------------------- /03_browsing_history/01_getting_a_repository/readme.md: -------------------------------------------------------------------------------- 1 | # **Extracting and Using "venus.zip"** 📂✨ 2 | 3 | To set up the necessary files for learning about browsing history, follow these instructions step by step. We'll ensure everything is clear and organized for you. 🚀 4 | 5 | ## 📖 Table of Contents 6 | 1. [🔍 Navigate to the Directory](#-navigate-to-the-directory) 7 | 2. [📂 Locate the File](#-locate-the-file) 8 | 3. [📦 Extract the File](#-extract-the-file) 9 | 4. [✅ Ready for Use](#-ready-for-use) 10 | 11 | ## 1. 🔍 Navigate to the Directory 12 | 13 | Start by moving to the **"03_browsing_history"** directory. This directory contains all resources related to browsing history. 14 | 15 | ### 💻 Command: 16 | ```bash 17 | cd 03_browsing_history 18 | ``` 19 | 20 | ## 2. 📂 Locate the File 21 | 22 | Inside **"03_browsing_history"**, look for the **"01_getting_a_repository"** directory. Once there, locate the file named **"venus.zip"**. 23 | 24 | ### 💻 Command: 25 | ```bash 26 | cd 01_getting_a_repository 27 | ls 28 | ``` 29 | 30 | This command will display all files and confirm the presence of **venus.zip**. 31 | 32 | ## 3. 📦 Extract the File 33 | 34 | After finding **"venus.zip"**, extract its contents to access the necessary files. 35 | 36 | ### 💻 Command: 37 | ```bash 38 | unzip venus.zip 39 | ``` 40 | 41 | If the `unzip` utility is not available, you can use: 42 | 43 | - On Linux: 44 | ```bash 45 | sudo apt install unzip 46 | ``` 47 | - On macOS: 48 | ```bash 49 | brew install unzip 50 | ``` 51 | - On Windows: Use a file extraction tool like **WinRAR** or **7-Zip**. 52 | 53 | ## 4. ✅ Ready for Use 54 | 55 | Once extracted, you'll see the contents of **venus.zip**, which are ready for you to explore and learn more about browsing history. 56 | -------------------------------------------------------------------------------- /03_browsing_history/05_alias/readme.md: -------------------------------------------------------------------------------- 1 | # 📂 **Creating Git Alias** 🔧✨ 2 | 3 | Welcome to the **ultimate guide** on **Creating Git Aliases**! 🚀 Whether you're a seasoned developer or just starting with Git, this README is crafted to provide you with **detailed explanations**, **practical examples**, and **valuable insights** to help you streamline your Git workflow by creating custom aliases. Let’s get started! 🏊‍♂️💻 4 | 5 | ## 📑 Table of Contents 6 | 7 | 1. [🔍 Introduction](#-introduction) 8 | 2. [🛠️ Creating Alias](#-creating-alias) 9 | - [1. Define Alias](#1-define-alias) 10 | - [2. Using the Alias](#2-using-the-alias) 11 | 3. [📝 Conclusion](#-conclusion) 12 | 13 | ## 🔍 Introduction 14 | 15 | Git aliases allow you to **create shortcuts** for frequently used or complex commands, making your Git workflow more **efficient** and **productive**. 🏃‍♂️💨 By defining custom aliases, you can simplify long commands, reduce the risk of errors, and tailor Git to better fit your personal or team preferences. This guide demonstrates how to **create an alias** for the `git log` command with a **custom format**, enhancing both readability and functionality. Let’s dive into the world of Git aliases! 🕵️‍♂️🔧 16 | 17 | 18 | ## 🛠️ Creating Alias 19 | 20 | Creating Git aliases involves defining shortcut commands that execute longer or more complex Git commands. This section walks you through the steps to **define** and **use** a Git alias effectively. 21 | 22 | ### 1. Define Alias 23 | 24 | **Description:** 25 | Creates a **global alias** named `lg` for the `git log` command with a **custom format**. 26 | 27 | **Command:** 28 | ```bash 29 | git config --global alias.lg "log --pretty=format:'%Cgreen %an%Creset committed %h - %s'" 30 | ``` 31 | 32 | **Features:** 33 | - **🔑 Global Alias (`--global`):** Makes the alias available across all repositories on your machine. 34 | - **🖌️ Custom Format:** Formats the log output to display the author's name in green, followed by the abbreviated commit hash and the commit message. 35 | - **📜 `--pretty=format`:** Allows customization of the log output format. 36 | 37 | **Detailed Explanation:** 38 | The above command sets up a Git alias named `lg`. When you type `git lg`, it executes the `git log` command with a specified format: 39 | 40 | - **`%Cgreen %an%Creset`:** Colors the author's name green for better visibility. 41 | - **`%h`:** Displays the abbreviated commit hash. 42 | - **`%s`:** Shows the commit message. 43 | 44 | This customization makes the commit history more **readable** and **visually appealing**, allowing you to quickly grasp essential information at a glance. 🎨👀 45 | 46 | **Example Command:** 47 | ```bash 48 | git config --global alias.lg "log --pretty=format:'%Cgreen %an%Creset committed %h - %s'" 49 | ``` 50 | 51 | **Use Cases:** 52 | - **Enhanced Readability:** Quickly identify authors and commit messages with color-coded output. 53 | - **Efficiency:** Reduce the need to type long `git log` commands repeatedly. 54 | - **Customization:** Tailor the log output to highlight the information most relevant to your workflow. 55 | 56 | 57 | ### 2. Using the Alias 58 | 59 | **Description:** 60 | Executes the `git log` command with the custom format defined by the `lg` alias. 61 | 62 | **Command:** 63 | ```bash 64 | git lg 65 | ``` 66 | 67 | **Features:** 68 | - **🚀 Quick Access:** Shortens the command to access customized log outputs effortlessly. 69 | - **🌈 Colorized Output:** Displays the author's name in green, making it stand out. 70 | - **🔍 Concise Information:** Shows the abbreviated commit hash and commit message for each commit. 71 | 72 | **Detailed Explanation:** 73 | After defining the alias, using `git lg` runs the `git log` command with your specified format. This command will output the commit history in a **concise and visually enhanced** manner. Here's what each part of the output represents: 74 | 75 | - **`%Cgreen %an%Creset`:** The author's name appears in green. 76 | - **`%h`:** Shows the abbreviated commit hash for quick reference. 77 | - **`%s`:** Displays the commit message, summarizing the changes made. 78 | 79 | **Example Command:** 80 | ```bash 81 | git lg 82 | ``` 83 | 84 | **Example Output:** 85 | ``` 86 | Muhammad Hashim committed 0673527 - Added user authentication feature 87 | Jane Doe committed a9b8c6d - Fixed bug in payment processing 88 | John Smith committed z1y2x3w - Updated README documentation 89 | ``` 90 | *(In the terminal, "Muhammad Hashim", "Jane Doe", and "John Smith" would appear in green color.)* 91 | 92 | **Use Cases:** 93 | - **Daily Workflow:** Use the alias regularly to view commit history in a preferred format. 94 | - **Team Collaboration:** Share the alias configuration with your team to maintain consistency in log outputs. 95 | - **Documentation:** Include the alias in project documentation to guide new team members on viewing commit history effectively. 96 | 97 | 98 | ## 📝 Conclusion 99 | 100 | Creating Git aliases allows you to **simplify complex commands** and **customize Git's behavior** according to your preferences. The `lg` alias created in this example provides a **more concise** and **visually appealing** format for viewing commit history. 🌟 By incorporating specific details and **colorization**, you can tailor the log output to suit your **workflow** or the **requirements** of your project or team. -------------------------------------------------------------------------------- /03_browsing_history/06_viewing_a _commit/readme.md: -------------------------------------------------------------------------------- 1 | # 📂 **Viewing a Commit** 🕵️‍♂️✨ 2 | 3 | Welcome to the **comprehensive guide** on **Viewing a Commit** using the `git show` command in Git! 🚀 Whether you're a seasoned developer or just starting with Git, this README is designed to provide you with **detailed explanations**, **practical examples**, and **valuable insights** to help you effectively inspect and understand specific commits in your repository. Let’s dive in! 🏊‍♂️💻 4 | 5 | ## 📑 Table of Contents 6 | 7 | 1. [🔍 Introduction](#-introduction) 8 | 2. [🛠️ Viewing Commit Details](#-viewing-commit-details) 9 | - [1. `git show HEAD~2` 📄](#-1-git-show-head~2-) 10 | - [2. `git show HEAD~2 --name-only` 👤](#2-git-show-head~2--name-only-👤) 11 | - [3. `git show HEAD~2 --name-status` 🗂️](#3-git-show-head~2--name-status-🗂️) 12 | 3. [📝 Conclusion](#-conclusion) 13 | 14 | ## 🔍 Introduction 15 | 16 | Git provides the `git show` command to **display detailed information** about a specific commit. 🖥️ By using `git show`, you can **inspect the commit message**, **author details**, **date**, and the **changes introduced** in the commit. This is invaluable for understanding the evolution of your project, debugging issues, and conducting thorough code reviews. 📖 This guide demonstrates how to view a commit and its changes using different options to suit various needs. Let’s explore how! 🕵️‍♂️🔧 17 | 18 | ## 🛠️ Viewing Commit Details 19 | 20 | The `git show` command offers various options to **customize** the information displayed about a specific commit. 📊 Below are the most commonly used `git show` commands, along with **detailed explanations**, **example commands**, and **example outputs** to help you utilize them effectively. 21 | 22 | ### 1. `git show HEAD~2` 📄 23 | 24 | **Description:** 25 | Displays **detailed information** about the commit located **two steps before the current HEAD** (HEAD~2). This includes the commit message, author, date, and the changes introduced in the commit. 26 | 27 | **Features:** 28 | - **🔍 Commit Details:** Provides the full commit message, author, and date. 29 | - **🛠️ Changes Introduced:** Shows the actual code changes made in the commit. 30 | 31 | **Detailed Explanation:** 32 | The `HEAD~2` notation refers to the commit that is two steps behind the current `HEAD`. Using `git show HEAD~2` allows you to **inspect** that specific commit in detail. This is useful when you want to review or debug changes made a few commits ago. 33 | 34 | **Example Command:** 35 | ```bash 36 | git show HEAD~2 37 | ``` 38 | 39 | **Example Output:** 40 | ``` 41 | commit 06735275dd31d9d3e20a608bcf821fc3a93550c5 42 | Author: Muhammad Hashim <*****@gmail.com> 43 | Date: Tue Apr 30 12:47:34 2024 +0500 44 | 45 | Added user authentication feature 46 | 47 | diff --git a/src/Auth.js b/src/Auth.js 48 | index e69de29..0d1d7fc 100644 49 | --- a/src/Auth.js 50 | +++ b/src/Auth.js 51 | @@ -0,0 +1,10 @@ 52 | +// Authentication module 53 | +import React from 'react'; 54 | + 55 | +function Auth() { 56 | + // Authentication logic 57 | +} 58 | + 59 | +export default Auth; 60 | ``` 61 | 62 | **Use Cases:** 63 | - **Detailed Review:** Examine the changes introduced in a specific commit. 64 | - **Debugging:** Identify and troubleshoot issues related to a particular commit. 65 | - **Documentation:** Document the evolution of features or fixes in the project history. 66 | 67 | ### 2. `git show HEAD~2 --name-only` 👤 68 | 69 | **Description:** 70 | Shows **only the names of the files** that were **modified**, **added**, or **deleted** in the specified commit. 71 | 72 | **Features:** 73 | - **📁 File Names:** Lists the files affected by the commit. 74 | - **🚫 No Code Changes:** Does not display the actual code differences. 75 | 76 | **Detailed Explanation:** 77 | The `--name-only` option filters the output of `git show` to include **only the names of the files** that were changed in the commit. This is useful for quickly identifying which parts of the project were affected without delving into the code changes themselves. 78 | 79 | **Example Command:** 80 | ```bash 81 | git show HEAD~2 --name-only 82 | ``` 83 | 84 | **Example Output:** 85 | ``` 86 | src/Auth.js 87 | src/UserProfile.js 88 | README.md 89 | ``` 90 | 91 | **Use Cases:** 92 | - **Quick File Audit:** Identify which files were changed in a commit. 93 | - **Impact Assessment:** Determine the scope of changes without reviewing the actual code. 94 | - **Automation Scripts:** Use in scripts that need to process or act upon modified files. 95 | 96 | ### 3. `git show HEAD~2 --name-status` 🗂️ 97 | 98 | **Description:** 99 | Displays the **names of the files** modified, added, or deleted in the commit **along with the status** of each change (modified, added, deleted). 100 | 101 | **Features:** 102 | - **📁 File Names:** Lists the affected files. 103 | - **📌 Change Status:** Indicates the type of change (e.g., M for modified, A for added, D for deleted). 104 | 105 | **Detailed Explanation:** 106 | The `--name-status` option extends the functionality of `--name-only` by also displaying the **status** of each file change. This provides a **concise summary** of what happened to each file in the commit, making it easier to understand the nature of the changes. 107 | 108 | **Example Command:** 109 | ```bash 110 | git show HEAD~2 --name-status 111 | ``` 112 | 113 | **Example Output:** 114 | ``` 115 | M src/Auth.js 116 | A src/UserProfile.js 117 | D src/OldComponent.js 118 | ``` 119 | 120 | **Use Cases:** 121 | - **Detailed File Changes:** Quickly understand what happened to each file in a commit. 122 | - **Code Reviews:** Assess the nature of changes (addition, modification, deletion) in a commit. 123 | - **Project Management:** Track file-level changes for better project oversight. 124 | 125 | ## 📝 Conclusion 126 | 127 | Using the `git show` command, you can **inspect the details** of a specific commit, including its **changes** and the **files affected**. 🧐 By specifying different options such as `--name-only` or `--name-status`, you can **tailor the output** to suit your requirements—whether you need a **detailed view** of the changes or just a **summary of the affected files**. This flexibility enhances your ability to **navigate** and **understand** the history of your project, aiding in **code reviews**, **debugging**, and **project management**. -------------------------------------------------------------------------------- /03_browsing_history/07_viewing_the_changes_across_two_commits/readme.md: -------------------------------------------------------------------------------- 1 | # 📂 **Viewing Changes Across Two Commits** 🔍✨ 2 | 3 | Welcome to the **comprehensive guide** on **Viewing Changes Across Two Commits** using the `git diff` command in Git! 🚀 Whether you're a seasoned developer or just starting with Git, this README is crafted to provide you with **detailed explanations**, **practical examples**, and **valuable insights** to help you effectively compare and understand the differences between commits in your repository. Let’s dive in! 🏊‍♂️💻 4 | 5 | --- 6 | 7 | ## 📑 Table of Contents 8 | 9 | 1. [🔍 Introduction](#-introduction) 10 | 2. [🛠️ Viewing Commit Changes](#-viewing-commit-changes) 11 | - [1. `git diff HEAD~2 HEAD` 📄](#1-git-diff-head~2-head-📄) 12 | - [2. `git diff HEAD~2 HEAD --name-only` 👤](#2-git-diff-head~2-head--name-only-👤) 13 | - [3. `git diff HEAD~2 HEAD --name-status` 🗂️](#3-git-diff-head~2-head--name-status-🗂️) 14 | 3. [📝 Conclusion](#-conclusion) 15 | 16 | ## 🔍 Introduction 17 | 18 | Git allows you to **compare changes** between different commits using the `git diff` command. 🖥️ By leveraging various options with `git diff`, you can **inspect the differences** between two specific commits, gaining insights into how your codebase has evolved over time. This is invaluable for **code reviews**, **debugging**, and **understanding the progression** of your project. 📖 This guide demonstrates how to **view the differences** between the last two commits using different `git diff` options. Let’s explore how! 🕵️‍♂️🔧 19 | 20 | 21 | ## 🛠️ Viewing Commit Changes 22 | 23 | The `git diff` command offers various options to **customize** the comparison between two commits. 📊 Below are the most commonly used `git diff` commands for viewing changes across two commits, along with **detailed explanations**, **example commands**, and **example outputs** to help you utilize them effectively. 24 | 25 | ### 1. `git diff HEAD~2 HEAD` 📄 26 | 27 | **Description:** 28 | Displays the **differences** between the commit located **two steps before the current HEAD** (`HEAD~2`) and the **current HEAD**. This includes the changes made to each file in the repository. 29 | 30 | **Features:** 31 | - **🔍 Comprehensive Diff:** Shows all changes between the two commits. 32 | - **🛠️ Detailed Changes:** Includes additions, deletions, and modifications in each file. 33 | - **📜 Unified Diff Format:** Presents changes in a readable unified format. 34 | 35 | **Detailed Explanation:** 36 | The `git diff HEAD~2 HEAD` command compares the state of the repository two commits behind the current `HEAD` with the current `HEAD`. This allows you to **inspect the exact changes** introduced in the last two commits. The output includes **diff hunks** that show line-by-line changes, making it easier to understand what was altered, added, or removed. 37 | 38 | **Example Command:** 39 | ```bash 40 | git diff HEAD~2 HEAD 41 | ``` 42 | 43 | **Example Output:** 44 | ```diff 45 | diff --git a/src/Auth.js b/src/Auth.js 46 | index e69de29..0d1d7fc 100644 47 | --- a/src/Auth.js 48 | +++ b/src/Auth.js 49 | @@ -0,0 +1,10 @@ 50 | +// Authentication module 51 | +import React from 'react'; 52 | + 53 | +function Auth() { 54 | + // Authentication logic 55 | +} 56 | + 57 | +export default Auth; 58 | ``` 59 | 60 | **Use Cases:** 61 | - **Code Review:** Examine the specific changes introduced in recent commits. 62 | - **Debugging:** Identify problematic changes that may have introduced bugs. 63 | - **Documentation:** Track the evolution of features by comparing different commits. 64 | 65 | ### 2. `git diff HEAD~2 HEAD --name-only` 👤 66 | 67 | **Description:** 68 | Shows **only the names of the files** that were **modified**, **added**, or **deleted** between the two specified commits. 69 | 70 | **Features:** 71 | - **📁 File Names Only:** Lists affected files without displaying the actual code changes. 72 | - **🚫 No Diff Details:** Provides a high-level overview of changed files. 73 | - **📋 Concise Output:** Easy to read and parse, especially for scripts. 74 | 75 | **Detailed Explanation:** 76 | The `--name-only` option with `git diff` filters the output to display **only the filenames** that have changed between `HEAD~2` and `HEAD`. This is useful when you need to **quickly identify which files** were affected by the changes without delving into the specific modifications within each file. 77 | 78 | **Example Command:** 79 | ```bash 80 | git diff HEAD~2 HEAD --name-only 81 | ``` 82 | 83 | **Example Output:** 84 | ``` 85 | src/Auth.js 86 | src/UserProfile.js 87 | README.md 88 | ``` 89 | 90 | **Use Cases:** 91 | - **Quick File Audit:** Identify which files were changed in recent commits. 92 | - **Impact Assessment:** Determine the scope of changes across the project. 93 | - **Automation Scripts:** Use in scripts that need to process or act upon modified files. 94 | 95 | ### 3. `git diff HEAD~2 HEAD --name-status` 🗂️ 96 | 97 | **Description:** 98 | Provides a **summary of the changes** between the two specified commits, including the **names of the modified files** and the **status** of each change (modified, added, deleted). 99 | 100 | **Features:** 101 | - **📁 File Names:** Lists all affected files. 102 | - **📌 Change Status:** Indicates the type of change with prefixes (M for modified, A for added, D for deleted). 103 | - **📝 Concise Summary:** Offers a clear and quick overview of changes. 104 | 105 | **Detailed Explanation:** 106 | The `--name-status` option extends the functionality of `--name-only` by **including the status** of each file change. This provides a **more informative summary** by indicating whether a file was **modified**, **added**, or **deleted** between the two commits. This is particularly useful for understanding the nature of the changes without examining the full diff. 107 | 108 | **Example Command:** 109 | ```bash 110 | git diff HEAD~2 HEAD --name-status 111 | ``` 112 | 113 | **Example Output:** 114 | ``` 115 | M src/Auth.js 116 | A src/UserProfile.js 117 | D src/OldComponent.js 118 | ``` 119 | 120 | **Use Cases:** 121 | - **Detailed File Changes:** Quickly understand what happened to each file in the commit range. 122 | - **Code Reviews:** Assess the types of changes (additions, modifications, deletions) for better context. 123 | - **Project Management:** Track file-level changes for reporting and oversight. 124 | 125 | ## 📝 Conclusion 126 | 127 | Using the `git diff` command with appropriate options, you can **compare changes between two commits** and gain valuable insights into how your codebase has **evolved over time**. 🧐 Whether you need a **detailed view** of the changes or just a **summary of the affected files**, Git provides the **flexibility** to meet your requirements. 128 | 129 | By mastering these `git diff` options, you can: 130 | - **🔍 Inspect Specific Changes:** Understand exactly what was altered between commits. 131 | - **📈 Track Project Evolution:** Monitor the progression and refinement of your project. 132 | - **🐛 Debug Efficiently:** Identify and resolve issues by pinpointing problematic changes. 133 | - **📊 Enhance Code Reviews:** Provide clear and concise information during the review process.* -------------------------------------------------------------------------------- /03_browsing_history/11_viewing_the_history_of_a_file/readme.md: -------------------------------------------------------------------------------- 1 | # 📂 **Viewing the History of a File** 🕵️‍♂️📄 2 | 3 | Welcome to the **ultimate guide** on **Viewing the History of a File** using Git! 🚀 Whether you're a seasoned developer or just starting with Git, this README is crafted to provide you with **detailed explanations**, **practical examples**, and **valuable insights** to help you effectively track and understand the evolution of specific files in your repository. Let’s dive in! 🏊‍♂️💻 4 | 5 | --- 6 | 7 | ## 📑 Table of Contents 8 | 9 | 1. [🔍 Introduction](#-introduction) 10 | 2. [🛠️ Viewing Commit History](#-viewing-commit-history) 11 | - [1. `git log ` 📄](#1-git-log-file-name-📄) 12 | - [2. `git log --oneline ` 🔍](#2-git-log--oneline-file-name-🔍) 13 | 3. [📝 Conclusion](#-conclusion) 14 | 15 | --- 16 | 17 | ## 🔍 Introduction 18 | 19 | Git allows you to **view the commit history** of a specific file, providing insights into its **evolution over time**. 📈 By examining the history of individual files, you can **track changes**, **identify when and why modifications were made**, and **understand the development** of specific features or components within your project. 🛠️ This guide demonstrates how to use `git log` to explore the history of a file effectively, enhancing your ability to **manage**, **debug**, and **collaborate** on file-based tasks within your repository. Let’s explore how! 🕵️‍♂️🔧 20 | 21 | --- 22 | 23 | ## 🛠️ Viewing Commit History 24 | 25 | The `git log` command is a powerful tool for **inspecting the history** of your repository. When combined with specific options and file paths, it allows you to **focus** on the changes made to individual files. 📜 Below are the most commonly used `git log` commands for viewing the history of a file, along with **detailed explanations**, **example commands**, and **example outputs** to help you utilize them effectively. 26 | 27 | ### 1. `git log ` 📄 28 | 29 | **Description:** 30 | Displays the **commit history** of the specified **file**. This includes information about each commit that **modified the file**, such as the **commit message**, **author**, **date**, and **commit hash**. 31 | 32 | **Features:** 33 | - **🔍 Detailed Commit Information:** Provides comprehensive details for each commit affecting the file. 34 | - **📜 Full Commit Messages:** Shows the complete commit messages for better context. 35 | - **👤 Author Attribution:** Identifies who made each change. 36 | 37 | **Detailed Explanation:** 38 | Running `git log ` allows you to **inspect the history** of a particular file within your repository. This command filters the commit history to include only those commits that have **altered the specified file**, making it easier to **trace the evolution** of that file over time. 39 | 40 | **Example Command:** 41 | ```bash 42 | git log src/App.js 43 | ``` 44 | 45 | **Example Output:** 46 | ``` 47 | commit a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0 48 | Author: Muhammad Hashim <*****@gmail.com> 49 | Date: Tue Apr 30 12:47:34 2024 +0500 50 | 51 | Refactored App component for better performance 52 | 53 | commit e4f5g6h7i8j9k0l1m2n3o4p5q6r7s8t9u0v1w2x3 54 | Author: Jane Doe 55 | Date: Mon Apr 29 09:15:30 2024 +0500 56 | 57 | Fixed routing bug in App.js 58 | 59 | commit z9y8x7w6v5u4t3s2r1q0p9o8n7m6l5k4j3i2h1g0 60 | Author: John Smith 61 | Date: Sun Apr 28 14:23:45 2024 +0500 62 | 63 | Added new feature to App.js 64 | ``` 65 | 66 | **Use Cases:** 67 | - **Change Tracking:** Monitor how a specific file has changed over time. 68 | - **Debugging:** Identify when a particular bug was introduced in a file. 69 | - **Code Reviews:** Review the history of changes made to a file for quality assurance. 70 | - **Documentation:** Document the evolution of a file for project records. 71 | 72 | --- 73 | 74 | ### 2. `git log --oneline ` 🔍 75 | 76 | **Description:** 77 | Shows a **condensed version** of the commit history for the specified **file**, displaying only the **abbreviated commit hash** and **commit message** in a **single line** for each commit. This is useful for **quickly scanning** through the commit history of a file. 78 | 79 | **Features:** 80 | - **🔑 Abbreviated SHA:** Provides a shortened version of the commit hash for readability. 81 | - **📝 One-Line Commit Messages:** Displays the first line of each commit message. 82 | - **📄 Concise Output:** Offers a streamlined view of the file's history without extensive details. 83 | 84 | **Detailed Explanation:** 85 | The `--oneline` option simplifies the output of `git log` by **condensing each commit** into a single line. When used with a file path, it focuses solely on the commits that have **affected that file**, allowing for a **quick overview** of its history. 86 | 87 | **Example Command:** 88 | ```bash 89 | git log --oneline src/App.js 90 | ``` 91 | 92 | **Example Output:** 93 | ``` 94 | a1b2c3d Refactored App component for better performance 95 | e4f5g6h Fixed routing bug in App.js 96 | z9y8x7w Added new feature to App.js 97 | ``` 98 | 99 | **Use Cases:** 100 | - **Quick Overview:** Get a rapid summary of changes made to a file. 101 | - **Efficient Navigation:** Easily navigate through recent commits without the verbosity of full commit details. 102 | - **Comparative Analysis:** Compare the frequency and nature of commits to a file over different periods. 103 | 104 | --- 105 | 106 | ## 📝 Conclusion 107 | 108 | By using `git log` with the appropriate **file name** and **options**, you can **explore the commit history** of a specific file in your Git repository effectively. 📂 This allows you to **track changes**, **understand when and why modifications were made**, and **collaborate efficiently** on file-based tasks within your project. Whether you need a **detailed view** with full commit information or a **concise summary** for quick scanning, Git provides the tools to tailor the output to your **specific needs**. 109 | 110 | ### Key Takeaways: 111 | - **🔍 Focused History:** Easily view the commit history of individual files to understand their evolution. 112 | - **📄 Customizable Output:** Use options like `--oneline` to adjust the level of detail in the log output. 113 | - **👥 Contributor Insights:** Identify who made specific changes to a file and when they did so. 114 | - **🐛 Efficient Debugging:** Quickly locate commits that introduced bugs or made significant changes to a file. 115 | 116 | Embrace these Git techniques to **enhance your version control proficiency**, **improve collaboration**, and **maintain a well-documented codebase**! 🚀 Keep exploring, stay curious, and **happy coding**! 👨‍💻🎉 117 | -------------------------------------------------------------------------------- /03_browsing_history/13_finding_the_author_of_a_line_using_blame/readme.md: -------------------------------------------------------------------------------- 1 | # 📂 **Finding the Author of a Line Using Blame** 🕵️‍♂️✍️ 2 | 3 | Welcome to the **ultimate guide** on **Finding the Author of a Line Using Blame** with Git! 🚀 Whether you're a seasoned developer or just starting with Git, this README is crafted to provide you with **detailed explanations**, **practical examples**, and **valuable insights** to help you efficiently identify the origin of specific lines in your files. Let’s dive in! 🏊‍♂️💻 4 | 5 | --- 6 | 7 | ## 📑 Table of Contents 8 | 9 | 1. [🔍 Introduction](#-introduction) 10 | 2. [🛠️ Blaming the File](#-blaming-the-file) 11 | - [1. `git blame ` 📄](#1-git-blame-file-name-📄) 12 | - [2. `git blame -e -L , ` 📜](#2-git-blame-e-l-startend-file-name-📜) 13 | 3. [📝 Conclusion](#-conclusion) 14 | 15 | --- 16 | 17 | ## 🔍 Introduction 18 | 19 | Git provides the `git blame` command to **track the origin** of each line in a file, revealing the **commit** and **author** responsible for the changes. 🖥️ By using `git blame`, you can **identify who made specific modifications**, understand **when changes were introduced**, and **trace the evolution** of a file over time. This is invaluable for **code reviews**, **debugging**, and **collaborative development**. 📈 This guide demonstrates how to use `git blame` effectively to uncover the authorship of individual lines in your files. Let’s explore how! 🕵️‍♂️🔧 20 | 21 | --- 22 | 23 | ## 🛠️ Blaming the File 24 | 25 | The `git blame` command annotates each line in a file with information about the last commit that modified that line. This section covers the most commonly used `git blame` commands, along with **detailed explanations**, **example commands**, and **example outputs** to help you utilize them effectively. 26 | 27 | ### 1. `git blame ` 📄 28 | 29 | **Description:** 30 | Displays a **detailed annotation** for each line in the specified file, showing the **commit hash**, **author**, **timestamp**, and **content** of the last change to each line. 31 | 32 | **Features:** 33 | - **🔍 Line-by-Line Annotation:** Provides granular details for each line. 34 | - **🔑 Commit Hash (``):** Identifies the specific commit responsible for the change. 35 | - **👤 Author Information (``):** Shows who made the change. 36 | - **🗓️ Timestamp (``):** Indicates when the change was made. 37 | - **✍️ Line Content:** Displays the actual content of the line. 38 | 39 | **Detailed Explanation:** 40 | Running `git blame ` annotates each line of the specified file with information about the **last commit** that modified it. This allows you to **trace back** changes to their origins, helping you understand the **context** and **reasoning** behind each modification. 41 | 42 | **Example Command:** 43 | ```bash 44 | git blame audience.txt 45 | ``` 46 | 47 | **Example Output:** 48 | ``` 49 | a1b2c3d4 (Jane Doe 2024-04-30 12:47:34 +0500 1) Introduction to the audience section. 50 | e4f5g6h7 (John Smith 2024-04-29 09:15:30 +0500 2) This line explains the target demographics. 51 | z9y8x7w6 (Jane Doe 2024-04-28 14:23:45 +0500 3) Additional details about audience engagement. 52 | ``` 53 | 54 | **Use Cases:** 55 | - **Code Reviews:** Identify who wrote or modified specific lines for targeted feedback. 56 | - **Debugging:** Trace the origin of problematic code to understand its history. 57 | - **Documentation:** Document the evolution of a file by understanding who contributed what. 58 | - **Accountability:** Ensure that changes are properly attributed to their authors. 59 | 60 | --- 61 | 62 | ### 2. `git blame -e -L , ` 📜 63 | 64 | **Description:** 65 | Blames only the specified **range of lines** (e.g., lines 1 to 2) in the file, including the **email addresses** of authors in the output. 66 | 67 | **Features:** 68 | - **📏 Line Range (`-L ,`):** Focuses on a specific subset of lines. 69 | - **📧 Email Addresses (`-e`):** Includes the authors' email addresses for more precise identification. 70 | - **🔍 Focused Annotation:** Provides detailed information for a targeted section of the file. 71 | - **🗂️ Efficient Scanning:** Quickly assess specific parts of large files without overwhelming output. 72 | 73 | **Detailed Explanation:** 74 | The `-L ,` option allows you to **limit the blame output** to a specific range of lines within the file. Combined with the `-e` option, which includes the authors' email addresses, this command provides a **detailed and focused** view of who modified specific lines and when. 75 | 76 | **Example Command:** 77 | ```bash 78 | git blame -e -L 1,2 audience.txt 79 | ``` 80 | 81 | **Example Output:** 82 | ``` 83 | a1b2c3d4 (Jane Doe 2024-04-30 12:47:34 +0500 1) Introduction to the audience section. 84 | e4f5g6h7 (John Smith 2024-04-29 09:15:30 +0500 2) This line explains the target demographics. 85 | ``` 86 | 87 | **Use Cases:** 88 | - **Targeted Analysis:** Examine specific sections of a file to understand changes in detail. 89 | - **Security Audits:** Review critical lines for security-related modifications. 90 | - **Feature Tracking:** Track changes in a particular feature or module within a file. 91 | - **Collaborative Projects:** Coordinate with specific team members based on their contributions to certain lines. 92 | 93 | --- 94 | 95 | ## 📝 Conclusion 96 | 97 | Using `git blame`, you can **track the history** of changes for each line in a file, helping you understand **who made which changes** and **when**. 📜 This capability is invaluable for **identifying authors responsible** for specific modifications, **investigating code changes**, and **tracing the evolution** of a file over time. By leveraging different options like `-e` and `-L`, you can **customize the output** to suit your **specific needs**, whether you're conducting a detailed analysis or seeking a quick overview. 98 | 99 | ### Key Takeaways: 100 | - **🔍 Granular Insights:** Gain detailed information about each line's history and authorship. 101 | - **📧 Enhanced Identification:** Utilize email addresses for more precise attribution. 102 | - **📏 Focused Analysis:** Narrow down blame to specific line ranges for targeted investigations. 103 | - **🛠️ Debugging Efficiency:** Quickly locate the source of bugs by tracing responsible lines. 104 | - **🤝 Collaborative Transparency:** Foster accountability and clarity within your development team. 105 | 106 | Embrace the power of `git blame` to **enhance your version control proficiency**, **improve code quality**, and **facilitate effective collaboration**! 🚀 Keep exploring, stay curious, and **happy coding**! 👨‍💻🎉 107 | -------------------------------------------------------------------------------- /03_browsing_history/16_summary/Summary.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HashimThePassionate/learn-git-mastery/cb2e79c89c470d5d8ab5d6a525a4a1494e11c2bb/03_browsing_history/16_summary/Summary.pdf -------------------------------------------------------------------------------- /03_browsing_history/17_exercise/Exercises.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HashimThePassionate/learn-git-mastery/cb2e79c89c470d5d8ab5d6a525a4a1494e11c2bb/03_browsing_history/17_exercise/Exercises.pdf -------------------------------------------------------------------------------- /03_browsing_history/readme.md: -------------------------------------------------------------------------------- 1 | # **Git Browsing History** 📜✨ 2 | 3 | Efficiently navigating your Git repository's history is crucial for understanding your project's evolution, debugging issues, and ensuring smooth collaboration. Below are essential tasks you can perform to explore and manage your Git repository history effectively. 4 | 5 | ## Table of Contents 📖✨ 6 | 1. [🔍 Search for Commits](#-search-for-commits) 7 | 2. [👀 View a Commit](#-view-a-commit) 8 | 3. [🛠️ Restore Your Project](#-restore-your-project) 9 | 4. [🔄 Compare Commits](#-compare-commits) 10 | 5. [🗂️ View the History of a File](#-view-the-history-of-a-file) 11 | 6. [🐛 Find a Bad Commit that Introduced a Bug](#-find-a-bad-commit-that-introduced-a-bug) 12 | 13 | ## 🔍 Search for Commits 14 | 15 | You can search for specific commits in your repository based on: 16 | 17 | - **👤 Author**: Filter commits made by a specific contributor. 18 | - **📅 Date**: Locate changes made during a particular time frame. 19 | - **✍️ Message**: Identify commits using keywords in their messages. 20 | 21 | **✨ Why it’s useful**: 22 | This enables you to find specific changes without manually sifting through the entire history. 23 | 24 | ## 👀 View a Commit 25 | 26 | Examine a particular commit to understand: 27 | 28 | - 📄 The changes made to files. 29 | - 📝 The purpose of the commit, as indicated in the message. 30 | 31 | **✨ Why it’s useful**: 32 | Helps you understand the context of modifications at a specific point in time. 33 | 34 | ## 🛠️ Restore Your Project 35 | 36 | Use Git to revert your project to a previous state by: 37 | 38 | - **🔄 Checking out** a specific commit: Temporarily view or work on an earlier version. 39 | - **↩️ Reverting changes**: Undo specific commits while keeping your history clean. 40 | 41 | **✨ Why it’s useful**: 42 | This is essential for rolling back unintended changes or recovering from errors. 43 | 44 | ## 🔄 Compare Commits 45 | 46 | Analyze the differences between two commits to: 47 | 48 | - 🧐 See what changed between versions. 49 | - 🕵️‍♂️ Identify when a specific feature or bug was introduced. 50 | 51 | **✨ Why it’s useful**: 52 | Provides insights into the progression of the codebase and helps in debugging. 53 | 54 | ## 🗂️ View the History of a File 55 | 56 | Track the changes to a specific file over time to: 57 | 58 | - 📜 See all the commits that modified the file. 59 | - 📈 Understand the evolution of its content. 60 | 61 | **✨ Why it’s useful**: 62 | Helps in analyzing the development and decisions made for a particular file. 63 | 64 | ## 🐛 Find a Bad Commit that Introduced a Bug 65 | 66 | Pin point the commit responsible for a bug or regression by: 67 | 68 | - 🕵️ Investigating the commit history. 69 | - 🛠️ Using Git tools like `git bisect` to automate the process. 70 | 71 | **✨ Why it’s useful**: 72 | Streamlines the debugging process by narrowing down potential sources of issues. -------------------------------------------------------------------------------- /04_branching/01_introduction/readme.md: -------------------------------------------------------------------------------- 1 | # 🌿 **Introduction to Branches** 2 | 3 | Branching is a fundamental concept in Git that enables developers to diverge from the main line of development and work on multiple features or fixes concurrently 🌟. Each branch represents an independent line of development, allowing developers to isolate changes and collaborate effectively. 4 | 5 | ## 🌟 Table of Contents 6 | 1. 🌱 [Introduction to Branching](#-introduction-to-branches) 7 | 2. 🛠️ [Common Branching Workflows](#️-common-branching-workflows) 8 | - 🌟 [Feature Branching](#-feature-branching) 9 | - 🚀 [Release Branching](#-release-branching) 10 | - 🔄 [Gitflow Workflow](#-gitflow-workflow) 11 | 3. 🌟 [Conclusion](#-conclusion) 12 | 13 | ## 🌱 Introduction to Branching 14 | Branching is a powerful Git feature that allows developers to work on multiple lines of development in parallel, fostering efficient collaboration and experimentation. 15 | 16 | ## 🛠️ Common Branching Workflows 17 | 18 | ### 🌟 Feature Branching 19 | Create a new branch for each feature or enhancement to keep changes isolated and organized. 20 | 21 | ### 🚀 Release Branching 22 | Use release branches to prepare releases and apply bug fixes independently of ongoing feature development. 23 | 24 | ### 🔄 Gitflow Workflow 25 | A structured branching model that defines branches for features, releases, and hotfixes, ensuring a clean and organized development process. 26 | 27 | ## 🌟 Conclusion 28 | Branching is a powerful feature in Git that fosters collaboration, experimentation, and parallel development 🚀. Understanding how to create, manage, and merge branches is essential for effective version control and seamless teamwork in software development projects. 🌟 -------------------------------------------------------------------------------- /04_branching/02_What_are_branches/readme.md: -------------------------------------------------------------------------------- 1 | # 🌿 **Branching in Git** 2 | 3 | Branching is a fundamental concept in Git that allows developers to manage multiple lines of development efficiently 🌟. It enables isolation, experimentation, and parallel development, making Git a powerful version control system 🚀. 4 | 5 | ## 🌟 Table of Contents 6 | 1. 🌱 [What is a Branch?](#-what-is-a-branch) 7 | 2. 🔍 [Why Use Branches?](#-why-use-branches) 8 | 3. 🛠️ [Common Branching Workflows](#️-common-branching-workflows) 9 | - 🌟 [Feature Branching](#-feature-branching) 10 | - 🚀 [Release Branching](#-release-branching) 11 | - 🔄 [Gitflow Workflow](#-gitflow-workflow) 12 | 4. ⚙️ [Basic Branching Operations](#️-basic-branching-operations) 13 | - 🧪 [Creating a Branch](#-creating-a-branch) 14 | - 🔄 [Switching Branches](#-switching-branches) 15 | - 🔗 [Merging Branches](#-merging-branches) 16 | 5. 🌟 [Conclusion](#-conclusion) 17 | 18 | 19 | ## 🌱 What is a Branch? 20 | A branch in Git is essentially a lightweight movable pointer to a specific commit 🗂️. When you create a new branch, you're essentially creating a new timeline 📅 where changes can be made without affecting the main development line 🛠️ (often referred to as the `master` or `main` branch). 21 | 22 | 23 | ## 🔍 Why Use Branches? 24 | Branches offer several benefits 🎯: 25 | - **Isolation** 🛡️: Changes made in one branch do not affect other branches until they are merged 🔗. 26 | - **Parallel Development** 🤝: Multiple developers can work on different features simultaneously without interfering with each other's work 🏗️. 27 | - **Experimentation** 🧪: Branches provide a safe space to try new ideas or implementations without risking the stability of the main codebase 🧩. 28 | - **Feature Development** 🚀: Each feature or bug fix can have its own dedicated branch, making tracking changes and collaboration easier 🔍. 29 | 30 | ## 🛠️ Common Branching Workflows 31 | 32 | ### 🌟 Feature Branching 33 | Create a new branch for each feature or enhancement 🌟 to keep changes isolated and organized 🗂️. 34 | 35 | ### 🚀 Release Branching 36 | Use release branches to prepare releases 📦 and apply bug fixes 🐛 independently of ongoing feature development 🛠️. 37 | 38 | ### 🔄 Gitflow Workflow 39 | A structured branching model 🏗️ that defines branches for features 🌟, releases 📦, and hotfixes 🔧, ensuring a clean and organized development process 🤝. 40 | 41 | ## ⚙️ Basic Branching Operations 42 | 43 | ### 🧪 Creating a Branch 44 | Use the `git branch` command 🖥️ to create a new branch based on the current commit 📅. 45 | 46 | ### 🔄 Switching Branches 47 | Use the `git checkout` command (or `git switch` in modern Git versions) 🔄 to switch between branches seamlessly 🛠️. 48 | 49 | ### 🔗 Merging Branches 50 | Use the `git merge` command 🔗 to integrate changes from one branch into another, ensuring collaboration 🧩. 51 | 52 | ## 🌟 Conclusion 53 | Branching in Git is a powerful tool 🛠️ for managing collaboration 🤝, experimentation 🧪, and parallel development 🚀. Understanding how to create, manage, and merge branches 🌟 is essential for effective version control 🎯 and seamless teamwork 🤝 in software development projects. 🌟 -------------------------------------------------------------------------------- /04_branching/03_getting_a_repository/Venus.zip: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HashimThePassionate/learn-git-mastery/cb2e79c89c470d5d8ab5d6a525a4a1494e11c2bb/04_branching/03_getting_a_repository/Venus.zip -------------------------------------------------------------------------------- /04_branching/03_getting_a_repository/readme.md: -------------------------------------------------------------------------------- 1 | # 🌿 **Extracting the "venus.zip" File for Branching** 2 | 3 | To set up your Git workflow, you'll need to locate the "03_getting_a_repository" directory and extract the "venus.zip" file inside it. Follow these steps to complete the process: 4 | 5 | ## 🌟 Table of Contents 6 | 1. 🔍 [Navigate to the Root Directory](#-1️⃣-navigate-to-the-root-directory) 7 | 2. 📁 [Search for the Directory](#-2️⃣-search-for-the-directory) 8 | 3. 📦 [Locate the Zip File](#-3️⃣-locate-the-zip-file) 9 | 4. 🛠️ [Extract the Zip File](#-4️⃣-extract-the-zip-file) 10 | 5. ✅ [Verify Extraction](#-5️⃣-verify-extraction) 11 | 6. 🚀 [Ready for Branching](#-ready-for-branching) 12 | 13 | 14 | ## 🔍 1️⃣ Navigate to the Root Directory 15 | If you're not already in the project's root directory 🗂️, navigate there. This is where the "03_getting_a_repository" directory is likely located. 16 | 17 | 18 | ## 📁 2️⃣ Search for the Directory 19 | Look for the "03_getting_a_repository" directory 🔍. You can use: 20 | - **File Explorer**: Browse manually to find the directory. 21 | - **Command Line**: Use `ls` (Linux/Mac) or `dir` (Windows) commands to list files and directories. 22 | 23 | 24 | ## 📦 3️⃣ Locate the Zip File 25 | Enter the "03_getting_a_repository" directory 📁 and search for the "venus.zip" file 📦. 26 | 27 | 28 | ## 🛠️ 4️⃣ Extract the Zip File 29 | Once you've located the file, extract its contents using one of the following methods: 30 | - **Graphical Interface**: Right-click on "venus.zip" and choose "Extract Here" or "Extract Files..." from the menu 📂. 31 | - **Command Line**: Use the `unzip venus.zip` command (Linux/Mac) or a similar tool on Windows 🖥️. 32 | 33 | 34 | ## ✅ 5️⃣ Verify Extraction 35 | Ensure the extraction is successful ✅. Check that the contents of the zip file are now visible in the directory 📂. You should see the extracted files and folders alongside "venus.zip". 36 | 37 | 38 | ## 🚀 Ready for Branching 39 | With the files extracted, you're now ready to incorporate them into your Git branching workflow 🌟. The extracted contents will serve as the foundation for your next steps in version control. -------------------------------------------------------------------------------- /04_branching/07_merging/readme.md: -------------------------------------------------------------------------------- 1 | # 🌿 **Merging in Git** 2 | 3 | Merging in Git is the process of combining changes from different branches into a single branch. It integrates divergent development efforts, reconciles conflicting modifications, and creates a unified history of changes to facilitate collaboration and code integration. 4 | 5 | ## 🌟 Table of Contents 6 | 1. 🌱 [What is Merging?](#-what-is-merging) 7 | 2. 🛠️ [Types of Merge](#️-types-of-merge) 8 | - 🚀 [Fast Forward Merge](#-fast-forward-merge) 9 | - 🔄 [3-Way Merge](#-3-way-merge) 10 | 11 | 12 | ## 🌱 What is Merging? 13 | Merging combines changes from different branches 🌟. It helps teams integrate code contributions, resolve conflicts, and maintain a consistent project state ✅. 14 | 15 | 16 | ## 🛠️ Types of Merge 17 | 18 | ### 🚀 Fast Forward Merge 19 | - Occurs when the branch being merged has all commits accessible from the branch you're merging into 🛤️. 20 | - Git simply **moves the branch pointer forward** to match the commit of the branch being merged 🏃‍♂️. 21 | - **No new merge commit is created**, making it fast and efficient ⏩. 22 | - Typically used in **linear histories**, where there are no conflicting changes 🤝. 23 | 24 | ### 🔄 3-Way Merge 25 | - Happens when there are **divergent changes** in both branches being merged 🛣️. 26 | - Git identifies the **common ancestor commit** of both branches and compares changes made in each branch since that ancestor 🕵️‍♂️. 27 | - Combines these changes into a **new merge commit**, integrating contributions from both branches into a unified state 🎯. 28 | - Necessary when there are **conflicts** or when branches have independent developments that need reconciliation ⚔️. 29 | 30 | -------------------------------------------------------------------------------- /04_branching/17_summaries/Summary.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HashimThePassionate/learn-git-mastery/cb2e79c89c470d5d8ab5d6a525a4a1494e11c2bb/04_branching/17_summaries/Summary.pdf -------------------------------------------------------------------------------- /04_branching/18_exercises/Exercises.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HashimThePassionate/learn-git-mastery/cb2e79c89c470d5d8ab5d6a525a4a1494e11c2bb/04_branching/18_exercises/Exercises.pdf -------------------------------------------------------------------------------- /04_branching/readme.md: -------------------------------------------------------------------------------- 1 | # 📖 **Branching in Git** 🌿 2 | 3 | Branching is a powerful feature in Git that helps developers work on multiple parts of a project simultaneously without interfering with others' work. Here's an organized explanation of Git branching concepts with beautiful emojis! 4 | 5 | ## 🌟 Table of Contents 6 | 1. 🌱 [What is Branching?](#-what-is-branching) 7 | 2. 🚀 [Use Branches](#-use-branches) 8 | 3. 🔍 [Compare Branches](#-compare-branches) 9 | 4. 🔗 [Merge Branches](#-merge-branches) 10 | 5. ⚔️ [Resolve Conflicts](#️-resolve-conflicts) 11 | 6. ⏪ [Undo a Faulty Merge](#-undo-a-faulty-merge) 12 | 7. 🛠️ [Essential Tools](#️-essential-tools) 13 | 8. 💡 [Benefits of Mastering Branching](#-benefits-of-mastering-branching) 14 | 15 | ### 🌱 What is Branching? 16 | Branching allows developers to work on multiple tasks, like features or bug fixes, independently 🌟. It ensures the stability of the main codebase while enabling parallel progress. 17 | 18 | ### 🚀 Use Branches 19 | Create and switch branches to work on new features or bug fixes 🌿. This enables parallel development, allowing team members to contribute independently without stepping on each other's toes. 20 | 21 | ### 🔍 Compare Branches 22 | Compare the differences between branches to review changes before merging them 🔎. This ensures that only intentional and clean updates are added to the main codebase. 23 | 24 | ### 🔗 Merge Branches 25 | Integrate changes from one branch into another, such as merging a feature branch into the main branch 🔗. This combines the work of multiple contributors into a unified codebase. 26 | 27 | ### ⚔️ Resolve Conflicts 28 | Conflicts arise when Git cannot automatically merge changes ⚔️. Resolve them by manually reviewing and fixing discrepancies between different versions of the same file. 29 | 30 | ### ⏪ Undo a Faulty Merge 31 | If a merge introduces issues, revert to the previous state without affecting other parts of the codebase 🔄. This restores stability while you debug the problem. 32 | 33 | ### 🛠️ Essential Tools 34 | **Stashing** temporarily saves uncommitted changes, allowing you to clean your working directory without losing progress 🧰. **Cherry-picking** applies specific commits from one branch to another 🍒, helping you selectively integrate critical updates or fixes. 35 | 36 | ### 💡 Benefits of Mastering Branching 37 | Mastering branching ensures smooth team collaboration 🤝 and parallel development 🌟. It helps manage complex workflows without breaking the main codebase and boosts confidence in handling conflicts and mistakes during development. Branching in Git is your key to managing collaborative workflows effectively and keeping your development process efficient 🚀! -------------------------------------------------------------------------------- /05_collaboration/01_workflow/readme.md: -------------------------------------------------------------------------------- 1 | ### Centralized Workflow: 2 | In a centralized workflow, there's a single repository where all collaborators push their changes. Each contributor clones the central repository, makes changes locally, and then pushes them back. This simplicity makes it easy to manage, especially for smaller teams, but can lead to bottlenecks and conflicts as all changes are funneled through one location. 3 | 4 | **Advantages:** 5 | 1. **Simplicity:** Easy to understand and set up, suitable for small teams. 6 | 2. **Control:** Offers a centralized point of control over the project's history and updates. 7 | 8 | **Disadvantages:** 9 | 1. **Single Point of Failure:** If the central repository goes down, collaborators can't push changes. 10 | 2. **Potential Bottlenecks:** A bottleneck can occur when many developers try to push changes simultaneously. 11 | 12 | **Example:** The Linux Kernel development initially followed a centralized workflow, where Linus Torvalds managed the main repository, and developers submitted patches to him for approval and integration. 13 | ``` 14 | Collaborator 1 Collaborator 2 15 | | | 16 | v v 17 | Central Repository (master/main) 18 | ``` 19 | ### Distributed Workflow: 20 | In a distributed workflow, each developer has their own repository, and changes are shared between them. Developers pull changes from each other's repositories and push to their own. This decentralization fosters greater independence and flexibility but can require more coordination and communication. 21 | 22 | **Advantages:** 23 | 1. **Flexibility:** Developers can work offline and push changes when ready. 24 | 2. **Redundancy:** Multiple copies of the repository reduce the risk of data loss. 25 | 26 | **Disadvantages:** 27 | 1. **Complexity:** Requires more coordination and communication among developers. 28 | 2. **Consistency:** Maintaining consistency across repositories can be challenging. 29 | 30 | **Example:** The development of the Git version control system itself follows a distributed workflow, where each developer has their own repository and contributes changes through pull requests. 31 | 32 | ``` 33 | Collaborator 1 Collaborator 2 34 | | | 35 | v v 36 | Local Repository 1 Local Repository 2 37 | | | 38 | v v 39 | Remote Repository (shared) 40 | ``` 41 | ### Integration-Manager Workflow: 42 | In an integration-manager workflow, there's a central repository with a designated integration manager who accepts changes from contributors. Developers fork the central repository, make changes in their forks, and then submit pull requests to the integration manager for review and integration. This workflow provides a balance between centralization and decentralization. 43 | 44 | **Advantages:** 45 | 1. **Controlled Integration:** Changes are reviewed and integrated by a designated person, ensuring quality and consistency. 46 | 2. **Flexibility:** Contributors can work independently in their forks and submit changes when ready. 47 | 48 | **Disadvantages:** 49 | 1. **Potential Bottlenecks:** The integration manager can become a bottleneck if there are many pull requests to review. 50 | 2. **Dependency on Integration Manager:** Development pace can be affected if the integration manager is unavailable or overwhelmed. 51 | 52 | **Example:** The development of the Ruby on Rails framework follows an integration-manager workflow, where contributors fork the main repository on GitHub, make changes in their forks, and then submit pull requests to the core team for review and integration. 53 | ``` 54 | Collaborator 1 Collaborator 2 55 | | | 56 | v v 57 | Integration Manager (Reviews & Merges) 58 | | 59 | v 60 | Central Repository 61 | ``` -------------------------------------------------------------------------------- /05_collaboration/02_creating_a_github_repository/readme.md: -------------------------------------------------------------------------------- 1 | 1. **Sign in to GitHub:** 2 | If you don't have an account, create one. If you already have an account, sign in. 3 | 4 | 2. **Create a New Repository:** 5 | - Click on the "+" sign in the top-right corner of the GitHub interface. 6 | - From the dropdown, select "New repository". 7 | 8 | 3. **Fill in Repository Information:** 9 | - In the "Repository name" field, enter "mars" (or any other desired name). 10 | - Optionally, add a description. 11 | - Choose whether to make it public or private. For this case, select "Public". 12 | - Optionally, initialize the repository with a README file. Check the checkbox labeled "Initialize this repository with a README". 13 | 14 | 4. **Add a README file:** 15 | - If you haven't checked the option to initialize with a README file in the previous step, you can manually create one after creating the repository. 16 | - Once the repository is created, click on the "Add a README" button, or click on the "Create new file" button and name it "README.md". 17 | 18 | 5. **Edit README file:** 19 | - Click on the README file to open it. 20 | - You can use Markdown syntax to format your README file. Provide a brief description of your project, its purpose, how to use it, etc. Markdown syntax allows for formatting text, adding links, images, etc. 21 | - Once you're done editing, scroll down and click on the "Commit changes" button to save your README file. 22 | 23 | 6. **Repository is Ready:** 24 | - Congratulations! Your Mars repository is now created, and it's public with a README file. 25 | -------------------------------------------------------------------------------- /05_collaboration/03_adding_collaborators/readme.md: -------------------------------------------------------------------------------- 1 | Certainly! Adding a collaborator to your GitHub repository allows them to contribute to the project. Here are the steps to add someone as a collaborator to your "mars" repository: 2 | 3 | 1. **Access Repository Settings:** 4 | - Navigate to your "mars" repository on GitHub. 5 | - Click on the "Settings" tab located on the menu bar of your repository. 6 | 7 | 2. **Manage Access:** 8 | - In the left sidebar, select the "Manage access" option under the "Settings" section. 9 | 10 | 3. **Invite Collaborator:** 11 | - Scroll down to the "Collaborators" section. 12 | - Click on the "Invite a collaborator" button. 13 | 14 | 4. **Enter Collaborator's GitHub Username or Email:** 15 | - In the pop-up dialog, enter the GitHub username or email address of the person you want to add as a collaborator. 16 | - GitHub will suggest usernames as you type. 17 | 18 | 5. **Select Collaborator:** 19 | - Once you've entered the username or email, click on the correct user from the suggestions. 20 | 21 | 6. **Confirm Invitation:** 22 | - After selecting the user, click on the "Add [hashimthepassionate] to this repository" button. 23 | 24 | 7. **Confirm the Invitation:** 25 | - GitHub will ask you to confirm the invitation. Confirm by clicking on the "Invite [hashimthepassionate]" button. 26 | 27 | 8. **Notification Sent:** 28 | - GitHub will send a notification to the collaborator, informing them of the invitation to collaborate on your repository. 29 | 30 | 9. **Collaborator Accepts Invitation:** 31 | - The collaborator will receive an email notification and can accept the invitation by clicking on the link provided in the email or by visiting the repository's page on GitHub. 32 | 33 | 10. **Access Granted:** 34 | - Once the collaborator accepts the invitation, they will have access to the repository and can start contributing to the project. 35 | 36 | That's it! The collaborator is now added to your "mars" repository, and they can collaborate with you on the project. -------------------------------------------------------------------------------- /05_collaboration/04_cloning_a_repository/readme.md: -------------------------------------------------------------------------------- 1 | 1. **Open Terminal (Linux/Mac) or Git Bash (Windows):** 2 | - Navigate to the directory where you want to clone the repository. 3 | 4 | 2. **Clone the Repository: and rename clone repository** 5 | - Use the `git clone` command followed by the URL of the repository you want to clone. For example: 6 | ``` 7 | git clone https://github.com/hashimthepassionate/mars.git MarsProject 8 | ``` 9 | 3. **Navigate into the New Directory:** 10 | - Go to MarsProject repository 11 | ``` 12 | cd MarsProject 13 | ``` 14 | 4. **Understanding origin/main and origin/HEAD:** 15 | - In Git, `origin` refers to the remote repository from which the local repository was cloned. 16 | - `origin/main` refers to the main branch (`main` can also be `master`, depending on your repository settings) on the remote repository. 17 | - `origin/HEAD` is a symbolic reference to the currently checked out branch on the remote repository. It typically points to the default branch (`main` or `master`). 18 | - When you clone a repository, Git sets up a tracking branch called `origin/main` which tracks the remote main branch. 19 | 20 | 5. **Viewing Remote Repositories:** 21 | - To view the remote repositories associated with your local repository, use the `git remote -v` command: 22 | ``` 23 | git remote -v 24 | ``` 25 | - This command lists the remote URLs along with their associated names (`origin` is the default name). 26 | -------------------------------------------------------------------------------- /05_collaboration/05_fetching_repository/readme.md: -------------------------------------------------------------------------------- 1 | **Before Changes in Remote Repository:** 2 | ```bash 3 | git log --oneline --all --graph 4 | * 123abc (HEAD -> main, origin/main) Initial commit 5 | ``` 6 | 7 | 1. **Remote Repository Changes:** 8 | - Someone makes changes to the README file directly on the GitHub repository. 9 | 10 | 2. **Fetch Changes to Local Repository:** 11 | ``` 12 | git fetch origin 13 | ``` 14 | 15 | This command fetches the latest changes from the remote repository (`origin`), including any changes made to branches. However, it does not automatically merge these changes into your local branch. 16 | 17 | 3. **View the Changes:** 18 | ```bash 19 | git log --oneline --all --graph 20 | * 123abc (HEAD -> main, origin/main) Initial commit 21 | * 456def (origin/main) Updated README file 22 | ``` 23 | 24 | The `git log` command shows that there is a new commit (`456def`) on the `origin/main` branch, indicating that the README file was updated. 25 | 26 | 4. **Merge Changes into Local Branch:** 27 | ``` 28 | git merge origin/main 29 | ``` 30 | 31 | This command merges the changes from the `origin/main` branch into your current local branch (typically `main`). 32 | 33 | **After Merging Changes in Local Repository:** 34 | ```bash 35 | git log --oneline --all --graph 36 | * abc123 (HEAD -> main) Merge branch 'origin/main' into main 37 | |\ 38 | | * 456def (origin/main) Updated README file 39 | |/ 40 | * 123abc (origin/main) Initial commit 41 | ``` 42 | 43 | Explanation: 44 | - The `git merge origin/main` command merges the changes from the `origin/main` branch into your local `main` branch. 45 | - A new merge commit (`abc123`) is created, combining the changes from both branches. 46 | - Now, your local repository is up to date with the changes made in the remote repository. 47 | -------------------------------------------------------------------------------- /05_collaboration/06_pulling/readme.md: -------------------------------------------------------------------------------- 1 | ## Before Pull: 2 | ```bash 3 | git log --oneline --all --graph 4 | * 123abc (HEAD -> main, origin/main) Initial commit 5 | * 456def (origin/main) Updated README file 6 | ``` 7 | 8 | 1. **Perform Pull Operation:** 9 | - To fetch changes from the remote repository and automatically merge them into the current branch, use: 10 | ``` 11 | git pull origin main 12 | ``` 13 | - This command fetches changes from the remote's main branch and merges them into the local main branch. 14 | 15 | 2. **Check Commit History (Local) After Pull:** 16 | - After pulling changes, run the command again to see the updated commit history: 17 | ``` 18 | git log --oneline --all --graph 19 | ``` 20 | 21 | - You'll see a three-way merge commit that incorporates the changes from the remote's main branch into your local main branch. The commit history might look something like this: 22 | 23 | ```bash 24 | * 789ghi (HEAD -> main) Merge branch 'origin/main' into main 25 | |\ 26 | | * 456def (origin/main) Updated README file 27 | * | 123abc (origin/main) Initial commit 28 | |/ 29 | * abc123 Your local commit 30 | ``` 31 | 32 | 3. **Perform Rebase Merge:** 33 | - To perform a rebase merge, you can use interactive rebase or a regular rebase. Here, let's use interactive rebase: 34 | ``` 35 | git rebase -i HEAD~2 36 | ``` 37 | - This command will open an editor where you can choose how to rebase your commits. 38 | 39 | 4. **Squash Commits (Optional):** 40 | - In the interactive rebase editor, you can squash commits or reorder them as needed. 41 | - Save and exit the editor. 42 | 43 | 5. **Check Commit History (Local) After Rebase Merge:** 44 | - After rebasing, run the same command again to see the updated commit history: 45 | ``` 46 | git log --oneline --all --graph 47 | ``` 48 | 49 | - You'll see a linear commit history after the rebase merge, with the changes from the remote's main branch incorporated into your local main branch. 50 | -------------------------------------------------------------------------------- /05_collaboration/07_pushing/readme.md: -------------------------------------------------------------------------------- 1 | ## Before Changes: 2 | ```bash 3 | git log --oneline --all --graph 4 | * 123abc (HEAD -> main) Initial commit 5 | * 456def Updated README file 6 | ``` 7 | 1. **Local Changes:** 8 | - Make changes to a file (e.g., README) in your local repository. 9 | 10 | ```bash 11 | git log --oneline --all --graph 12 | * 123abc (HEAD -> main) Initial commit 13 | * 456def Updated README file 14 | * 789ghi Your local changes 15 | ``` 16 | 17 | 2. **Push Local Changes:** 18 | - Push your local changes to the remote repository: 19 | ``` 20 | git push origin main 21 | ``` 22 | 23 | 3. **Remote Changes:** 24 | - Someone else adds new changes to the remote repository. 25 | 26 | ```bash 27 | git log --oneline --all --graph 28 | * 123abc (HEAD -> main, origin/main) Initial commit 29 | * 456def Updated README file 30 | * 012xyz New changes from remote 31 | ``` 32 | 33 | 4. **Pull and Rebase:** 34 | - Pull the changes from the remote repository and rebase your local changes on top: 35 | ``` 36 | git pull --rebase origin main 37 | ``` 38 | 39 | - Resolve any conflicts if necessary. 40 | 41 | 5. **Check Commit History After Pull and Rebase:** 42 | 43 | ```bash 44 | git log --oneline --all --graph 45 | * 123abc (origin/main) Initial commit 46 | * 456def Updated README file 47 | * 012xyz New changes from remote 48 | * 789ghi (HEAD -> main) Your local changes 49 | ``` 50 | 51 | 6. **Push Rebased Changes:** 52 | - Push the rebased changes to the remote repository: 53 | ``` 54 | git push origin main 55 | ``` 56 | 57 | 7. **Final Commit History After Push:** 58 | 59 | ```bash 60 | git log --oneline --all --graph 61 | * 123abc (origin/main) Initial commit 62 | * 456def Updated README file 63 | * 012xyz New changes from remote 64 | * 789ghi (HEAD -> main) Your local changes 65 | ``` 66 | -------------------------------------------------------------------------------- /05_collaboration/08_storing_credentials/readme.md: -------------------------------------------------------------------------------- 1 | ### Step 1: Download and Install Git for Windows 2 | 3 | 1. **Download Git for Windows:** 4 | - Visit the Git for Windows website: [https://gitforwindows.org](https://gitforwindows.org). 5 | - Click the "Download" button to get the installer. 6 | 7 | 2. **Install Git for Windows:** 8 | - Run the downloaded installer. 9 | - Follow the installation prompts. Make sure to select the option to use the Git Credential Manager during the installation process. This is usually enabled by default. 10 | - Complete the installation. 11 | 12 | ### Step 2: Configure Git to Use the Credential Manager 13 | 14 | 1. **Open Git Bash:** 15 | - After installing Git, open Git Bash from the Start menu or your desktop. 16 | 17 | 2. **Configure Git to Use Credential Manager:** 18 | - Run the following command in Git Bash to configure Git to use the Windows Credential Manager: 19 | ```bash 20 | git config --global credential.helper manager 21 | ``` 22 | 23 | ### Step 3: Store GitHub Remote Credentials 24 | 25 | 1. **Clone a Repository or Push Changes to Trigger Credential Prompt:** 26 | - When you clone a repository or push changes for the first time, Git will prompt you to enter your GitHub credentials. 27 | - For example, to clone a repository, use: 28 | ```sh 29 | git clone https://github.com/hashimthepassionate/mars.git 30 | ``` 31 | 32 | 2. **Enter GitHub Credentials:** 33 | - When prompted, enter your GitHub username and password (or personal access token if you have two-factor authentication enabled). 34 | - The Windows Credential Manager will store these credentials securely. 35 | 36 | ### Step 4: Verify Stored Credentials 37 | 38 | 1. **Access Windows Credential Manager:** 39 | - Open the Control Panel and navigate to "User Accounts" > "Credential Manager". 40 | - Alternatively, you can search for "Credential Manager" in the Start menu. 41 | 42 | 2. **Verify GitHub Credentials:** 43 | - In the Credential Manager, go to the "Windows Credentials" tab. 44 | - Look for an entry related to `git:https://github.com` or similar. 45 | - Verify that your GitHub credentials are stored correctly. 46 | 47 | ### Additional Notes: 48 | 49 | - **Updating Credentials:** 50 | - If you change your GitHub password or personal access token, you can update the stored credentials by deleting the existing entry in the Credential Manager and re-entering your credentials the next time Git prompts you. 51 | 52 | - **Security:** 53 | - Using the Windows Credential Manager helps keep your credentials secure by storing them in an encrypted format. 54 | -------------------------------------------------------------------------------- /05_collaboration/10_releases/readme.md: -------------------------------------------------------------------------------- 1 | ### Step 1: Create a Tag for the Release 2 | 3 | 1. **Create the Tag:** 4 | - If you haven't already created the tag `v1.0`, do so using: 5 | ```sh 6 | git tag v1.0 7 | ``` 8 | 9 | 2. **Push the Tag to the Remote Repository:** 10 | - Push the tag to the remote repository: 11 | ```sh 12 | git push origin v1.0 13 | ``` 14 | 15 | ### Step 2: Create a Release on GitHub 16 | 17 | 1. **Navigate to Your Repository on GitHub:** 18 | - Open your web browser and go to your GitHub repository. 19 | 20 | 2. **Go to the "Releases" Section:** 21 | - Click on the "Releases" link located typically near the top of the repository page or in the right-hand sidebar. 22 | 23 | 3. **Create a New Release:** 24 | - Click the "Draft a new release" button. 25 | 26 | 4. **Fill in the Release Information:** 27 | - **Tag version:** Select `v1.0` from the dropdown list (it should be pre-populated with the tag you pushed earlier). 28 | - **Release title:** Enter a title for your release, such as "Version 1.0". 29 | - **Description:** Provide a description of the release. This can include highlights, new features, bug fixes, and any other relevant information. 30 | - **Optional Files:** If you have any binaries or additional files to include with the release, you can upload them by dragging and dropping or using the "Attach binaries by dropping them here or selecting them" area. 31 | 32 | 5. **Publish the Release:** 33 | - Once you've filled in all the necessary details, click the "Publish release" button. 34 | 35 | ### Step 3: Verify the Release 36 | 37 | 1. **Check the Releases Page:** 38 | - After publishing, you should be redirected to the releases page where you can see the newly created release `v1.0`. 39 | 40 | 2. **Verify the Tag and Release:** 41 | - Ensure that the release information and tag are correct. The release should be associated with the `v1.0` tag and include all the details you entered. 42 | 43 | ### Summary of Commands and Steps 44 | 45 | 1. **Create and Push the Tag:** 46 | ```sh 47 | git tag v1.0 48 | git push origin v1.0 49 | ``` 50 | 51 | 2. **Create a Release on GitHub:** 52 | - Navigate to your repository on GitHub. 53 | - Go to the "Releases" section. 54 | - Click "Draft a new release". 55 | - Fill in the release information (tag version `v1.0`, release title, description). 56 | - Publish the release. 57 | 58 | -------------------------------------------------------------------------------- /05_collaboration/11_sharing_branches/readme.md: -------------------------------------------------------------------------------- 1 | 2 | 1. **Create a new branch and switch to it:** 3 | ```sh 4 | git switch -C feature/change-password 5 | ``` 6 | 7 | 2. **Make your changes** (edit files, add new files, etc.). 8 | 9 | 3. **Stage the changes:** 10 | ```sh 11 | git add . 12 | ``` 13 | 14 | 4. **Commit the changes:** 15 | ```sh 16 | git commit -m "Made changes related to change-password feature" 17 | ``` 18 | 19 | 5. **Add the new branch to the remote repository (origin):** 20 | ```sh 21 | git push origin feature/change-password 22 | ``` 23 | 24 | 6. **Switch back to the main branch (or any other branch you want to switch to):** 25 | ```sh 26 | git switch main 27 | ``` 28 | 29 | 7. **Delete the local branch:** 30 | ```sh 31 | git branch -d feature/change-password 32 | ``` 33 | 34 | 8. **Delete the remote branch:** 35 | ```sh 36 | git push origin --delete feature/change-password 37 | ``` 38 | 39 | Here is the sequence of commands you will use: 40 | 41 | ```sh 42 | # Step 1 43 | git switch -C feature/change-password 44 | 45 | # Step 2 46 | # (Make changes to files in your repository) 47 | 48 | # Step 3 49 | git add . 50 | 51 | # Step 4 52 | git commit -m "Made changes related to change-password feature" 53 | 54 | # Step 5 55 | git push origin feature/change-password 56 | 57 | # Step 6 58 | git switch main 59 | 60 | # Step 7 61 | git branch -d feature/change-password 62 | 63 | # Step 8 64 | git push origin --delete feature/change-password 65 | ``` 66 | -------------------------------------------------------------------------------- /05_collaboration/12_collaborating_workflow/readme.md: -------------------------------------------------------------------------------- 1 | Sure, let's create a scenario where two people (Alice and Bob) are collaborating on a Git repository. We'll walk through the process of creating a new branch on the remote, fetching it locally, setting up tracking branches, and collaborating by pulling and pushing changes. Finally, we'll prune remote-tracking branches. 2 | 3 | ### Scenario Steps 4 | 5 | #### 1. Create a Branch on the Remote Repository 6 | Assume Alice is creating a new branch called `feature/new-feature` on the remote repository. 7 | 8 | ```sh 9 | # Alice creates a new branch on the remote repository 10 | git push origin HEAD:refs/heads/feature/new-feature 11 | ``` 12 | 13 | This command pushes the current branch (`HEAD`) to a new branch called `feature/new-feature` on the remote (`origin`). 14 | 15 | #### 2. Fetch the New Branch Locally 16 | Both Alice and Bob need to fetch the new branch to their local repositories. 17 | 18 | ```sh 19 | # Alice fetches the new branch 20 | git fetch origin feature/new-feature 21 | 22 | # Bob fetches the new branch 23 | git fetch origin feature/new-feature 24 | ``` 25 | 26 | #### 3. Create and Track the New Branch Locally 27 | Alice and Bob create a local branch and set it to track the remote branch `feature/new-feature`. 28 | 29 | ```sh 30 | # Alice creates and tracks the new branch 31 | git switch -C feature/new-feature -t origin/feature/new-feature 32 | 33 | # Bob creates and tracks the new branch 34 | git switch -C feature/new-feature -t origin/feature/new-feature 35 | ``` 36 | 37 | The `-t` option is shorthand for `--track`, which sets up the local branch to track the specified remote branch. 38 | 39 | #### 4. Collaborate by Pulling and Pushing Changes 40 | Alice and Bob can now make changes, commit them, and push/pull to collaborate. 41 | 42 | **Alice makes a change:** 43 | ```sh 44 | # Alice makes some changes 45 | git add . 46 | git commit -m "Alice's changes to new feature" 47 | git push origin feature/new-feature 48 | ``` 49 | 50 | **Bob pulls Alice's changes and makes his own:** 51 | ```sh 52 | # Bob pulls Alice's changes 53 | git pull origin feature/new-feature 54 | 55 | # Bob makes some changes 56 | git add . 57 | git commit -m "Bob's changes to new feature" 58 | git push origin feature/new-feature 59 | ``` 60 | 61 | **Alice pulls Bob's changes:** 62 | ```sh 63 | # Alice pulls Bob's changes 64 | git pull origin feature/new-feature 65 | ``` 66 | 67 | #### 5. Prune Remote-Tracking Branches 68 | When branches are deleted on the remote, it's good practice to prune the local repository to clean up stale references. 69 | 70 | **Delete the remote branch:** 71 | Assume the feature is completed, and the branch `feature/new-feature` is deleted from the remote. 72 | 73 | ```sh 74 | # Alice deletes the remote branch 75 | git push origin --delete feature/new-feature 76 | ``` 77 | 78 | **Prune the remote-tracking branches:** 79 | Both Alice and Bob should prune their local repositories. 80 | 81 | ```sh 82 | # Alice prunes her remote-tracking branches 83 | git fetch -p 84 | 85 | # Bob prunes his remote-tracking branches 86 | git fetch -p 87 | ``` 88 | 89 | The `-p` option for `git fetch` is shorthand for `--prune`, which removes references to remote-tracking branches that no longer exist on the remote. 90 | 91 | ### Summary of Commands 92 | 93 | Here's the sequence of commands used: 94 | 95 | **Alice creates a remote branch:** 96 | ```sh 97 | git push origin HEAD:refs/heads/feature/new-feature 98 | ``` 99 | 100 | **Alice and Bob fetch the new branch:** 101 | ```sh 102 | git fetch origin feature/new-feature 103 | ``` 104 | 105 | **Alice and Bob create and track the new branch:** 106 | ```sh 107 | git switch -t feature/new-feature origin/feature/new-feature 108 | ``` 109 | 110 | **Alice makes changes:** 111 | ```sh 112 | git add . 113 | git commit -m "Alice's changes to new feature" 114 | git push origin feature/new-feature 115 | ``` 116 | 117 | **Bob pulls changes and makes his own:** 118 | ```sh 119 | git pull origin feature/new-feature 120 | git add . 121 | git commit -m "Bob's changes to new feature" 122 | git push origin feature/new-feature 123 | ``` 124 | 125 | **Alice pulls Bob's changes:** 126 | ```sh 127 | git pull origin feature/new-feature 128 | ``` 129 | 130 | **Alice deletes the remote branch:** 131 | ```sh 132 | git push origin --delete feature/new-feature 133 | ``` 134 | 135 | **Alice and Bob prune their local repositories:** 136 | ```sh 137 | git fetch -p 138 | ``` -------------------------------------------------------------------------------- /05_collaboration/13_pull_requests/readme.md: -------------------------------------------------------------------------------- 1 | ### Steps: 2 | 3 | #### 1. Bob and Alice clone the repository: 4 | Both Bob and Alice clone the repository to their local machines. 5 | 6 | ```sh 7 | git clone https://github.com/hashimthepassionate/mars.git MarsProject 8 | cd MarsProject 9 | ``` 10 | 11 | #### 2. Bob and Alice create a new branch for their feature: 12 | Each contributor creates a new local branch for their feature. 13 | 14 | ```sh 15 | git switch -c feature/awesome-feature 16 | ``` 17 | 18 | #### 3. Bob and Alice make changes and commit: 19 | They make changes to the codebase and commit them to their local branches. 20 | 21 | ```sh 22 | # Make changes 23 | git add . 24 | git commit -m "Implemented awesome feature" 25 | ``` 26 | 27 | #### 4. Bob and Alice pull changes from the main branch: 28 | Before pushing their changes, they fetch and pull the latest changes from the main branch to ensure they're up-to-date. 29 | 30 | ```sh 31 | git switch main 32 | git pull origin main 33 | ``` 34 | 35 | #### 5. Bob and Alice rebase their feature branches: 36 | To incorporate the latest changes from the main branch into their feature branches, they rebase. 37 | 38 | ```sh 39 | git switch feature/awesome-feature 40 | git rebase main 41 | ``` 42 | 43 | #### 6. Bob and Alice resolve any conflicts: 44 | If there are any conflicts during the rebase, they resolve them. 45 | 46 | #### 7. Bob and Alice push their feature branches: 47 | Once their changes are committed and rebased, they push their feature branches to the remote repository. 48 | 49 | ```sh 50 | git push origin feature/awesome-feature 51 | ``` 52 | 53 | #### 8. Bob and Alice create pull requests on GitHub: 54 | They go to the repository on GitHub and create pull requests from their feature branches to the main branch. 55 | 56 | #### 9. Review and merge pull requests: 57 | Other team members review the pull requests on GitHub, provide feedback, and finally merge them into the main branch. 58 | 59 | #### 10. Bob and Alice fetch the latest changes from the main branch: 60 | After the pull requests are merged, they fetch the latest changes from the main branch to their local repositories. 61 | 62 | ```sh 63 | git switch main 64 | git pull origin main 65 | ``` 66 | 67 | #### 11. Bob and Alice delete their local feature branches: 68 | Once their changes are merged into the main branch, they delete their local feature branches. 69 | 70 | ```sh 71 | git branch -d feature/awesome-feature 72 | ``` 73 | 74 | #### 12. Bob and Alice delete their remote feature branches: 75 | Optionally, they can delete their remote feature branches. 76 | 77 | ```sh 78 | git push origin --delete feature/awesome-feature 79 | ``` 80 | 81 | ### Summary: 82 | 1. Clone the repository. 83 | 2. Create a new local branch for the feature. 84 | 3. Make changes and commit. 85 | 4. Pull changes from the main branch. 86 | 5. Rebase the feature branch on the main branch. 87 | 6. Resolve conflicts if any. 88 | 7. Push the feature branch to the remote. 89 | 8. Create pull requests on GitHub. 90 | 9. Review and merge pull requests. 91 | 10. Fetch latest changes from the main branch. 92 | 11. Delete local feature branches. 93 | 12. Optionally, delete remote feature branches. 94 | -------------------------------------------------------------------------------- /05_collaboration/14_resolving_conflicts/readme.md: -------------------------------------------------------------------------------- 1 | Sure, let's walk through a scenario where Bob and Alice are both working directly on the main branch. They each make changes, push to the main branch, and encounter a conflict. Bob resolves the conflict using the GitHub graphical interface. 2 | 3 | ### Scenario Steps: 4 | 5 | #### 1. Clone the repository: 6 | Both Bob and Alice clone the repository to their local machines. 7 | 8 | ```sh 9 | git https://github.com/hashimthepassionate/mars.git MarsProject 10 | cd MarsProject 11 | ``` 12 | 13 | #### 2. Bob and Alice work on the main branch: 14 | They both make changes directly on the main branch. 15 | 16 | ```sh 17 | # Make changes 18 | git add . 19 | git commit -m "Alice's changes" 20 | git push origin main 21 | ``` 22 | 23 | ```sh 24 | # Make changes 25 | git add . 26 | git commit -m "Bob's changes" 27 | git push origin main 28 | ``` 29 | 30 | #### 3. Conflict occurs on Bob's side: 31 | When Bob pushes his changes, there's a conflict because Alice has also made changes to the same part of the code. 32 | 33 | #### 4. Bob resolves the conflict using GitHub: 34 | Bob navigates to the repository on GitHub and opens a pull request for his changes. 35 | 36 | #### 5. Bob resolves the conflict using the GitHub interface: 37 | Bob goes to his pull request on GitHub, where he sees the conflict indicated. He clicks on the "Resolve conflicts" button. 38 | 39 | #### 6. Bob resolves the conflict: 40 | GitHub provides a text editor where Bob can resolve the conflict. He makes the necessary changes, then commits the resolution directly on GitHub. 41 | 42 | #### 7. Bob's pull request is merged: 43 | Once the conflict is resolved and Bob's changes are reviewed, his pull request is merged into the main branch. 44 | 45 | ### Summary: 46 | 1. Clone the repository. 47 | 2. Bob and Alice work on the main branch, making changes directly. 48 | 3. Conflict occurs when Bob pushes his changes. 49 | 4. Bob opens a pull request for his changes on GitHub. 50 | 5. Bob resolves the conflict using the GitHub interface. 51 | 6. Bob makes the necessary changes and commits the resolution on GitHub. 52 | 7. Bob's pull request is merged into the main branch. 53 | -------------------------------------------------------------------------------- /05_collaboration/15_issues/readme.md: -------------------------------------------------------------------------------- 1 | The purpose of issues in GitHub is to track tasks, enhancements, bugs, or any other topics related to a repository. Issues serve as a centralized place for discussion, collaboration, and project management. They provide a structured way for users to communicate about problems, propose ideas, and coordinate work on a project. 2 | 3 | ### Creating a New Issue and Assigning to Myself: 4 | 5 | #### 1. Navigate to the Repository: 6 | Go to the repository where you want to create the issue. 7 | 8 | #### 2. Click on the "Issues" Tab: 9 | In the repository's navigation bar, click on the "Issues" tab to view existing issues and create a new one. 10 | 11 | #### 3. Create a New Issue: 12 | Click on the "New issue" button to create a new issue. 13 | 14 | #### 4. Provide Issue Details: 15 | - **Title**: Enter a concise title that summarizes the issue. 16 | - **Description**: Provide detailed notes about the issue. Include information such as: 17 | - What the problem is or what feature needs to be implemented. 18 | - Steps to reproduce the problem (if it's a bug). 19 | - Suggestions for solutions or how to implement the feature (if it's an enhancement). 20 | - **Labels**: Optionally, add labels to categorize the issue (e.g., bug, enhancement, documentation). 21 | - **Assignees**: Assign the issue to yourself by clicking on your username in the "Assignees" section. 22 | 23 | #### 5. Submit the Issue: 24 | Once you've provided all the necessary information, click on the "Submit new issue" button to create the issue. 25 | 26 | ### Detailed Notes for the Issue: 27 | 28 | #### Issue Title: 29 | Implement User Authentication 30 | 31 | #### Description: 32 | **Problem:** 33 | Currently, our application lacks user authentication, leaving sensitive data and functionalities exposed to unauthorized users. 34 | 35 | **Steps to Reproduce:** 36 | 1. Navigate to any restricted area of the application. 37 | 2. No authentication prompt or access control mechanism is in place. 38 | 39 | **Proposed Solution:** 40 | Implement user authentication using JWT (JSON Web Tokens) and integrate it with our existing user management system. 41 | - Utilize a library such as `jsonwebtoken` for token generation and verification. 42 | - Implement middleware to protect routes that require authentication. 43 | - Provide endpoints for user login and registration. 44 | - Store user credentials securely and handle password hashing. 45 | 46 | **Tasks:** 47 | 1. Integrate JWT authentication middleware. 48 | 2. Implement user login and registration endpoints. 49 | 3. Secure sensitive routes using authentication middleware. 50 | 4. Update documentation to include authentication instructions. 51 | 52 | #### Labels: 53 | - Enhancement 54 | - Security 55 | 56 | #### Assignees: 57 | - hashimthepassionate 58 | -------------------------------------------------------------------------------- /05_collaboration/16_custom_labels/readme.md: -------------------------------------------------------------------------------- 1 | Sure, let's create a custom issue with a title, description, and a custom color. 2 | 3 | ### Custom Issue Details: 4 | 5 | #### Title: 6 | Update Landing Page Design 7 | 8 | #### Description: 9 | **Current Design:** 10 | The landing page of our website lacks visual appeal and fails to effectively communicate our brand message. The layout is outdated, and the content could be organized more effectively. 11 | 12 | **Proposed Changes:** 13 | 1. **Visual Refresh**: Update the color scheme, typography, and overall visual elements to align with our brand identity. 14 | 2. **Content Organization**: Rearrange the sections and content on the landing page to improve clarity and user engagement. 15 | 3. **Call-to-Action (CTA)**: Add prominent CTAs to encourage user interaction and guide them through our website. 16 | 17 | **Tasks:** 18 | 1. Conduct a design audit to identify areas for improvement. 19 | 2. Create mockups or wireframes for the updated landing page design. 20 | 3. Implement design changes using HTML, CSS, and JavaScript. 21 | 4. Test the updated landing page across different devices and browsers to ensure responsiveness and compatibility. 22 | 23 | #### Custom Color: 24 | Custom color: `#f0ad4e` (a shade of orange) 25 | 26 | This custom color will help differentiate this issue from others and make it stand out visually in the issue tracker. 27 | 28 | ### Summary: 29 | Creating a custom issue with a clear title, detailed description, and custom color helps to effectively communicate the issue's purpose, proposed changes, and importance. It also makes it easier to identify and prioritize the issue among others in the issue tracker. 30 | 31 | -------------------------------------------------------------------------------- /05_collaboration/17_milestone/readme.md: -------------------------------------------------------------------------------- 1 | ### Creating a Milestone: 2 | 3 | #### 1. Navigate to the Milestones Section: 4 | Go to the "Issues" tab in your repository's navigation bar and click on the "Milestones" option. 5 | 6 | #### 2. Create a New Milestone: 7 | Click on the "New milestone" button to create a new milestone. 8 | 9 | #### 3. Fill in Milestone Details: 10 | - **Title**: Enter a title for the milestone, such as "Website Redesign". 11 | - **Description**: Optionally, provide a description to briefly explain the purpose or goals of the milestone. 12 | - **Due date**: Set a due date for the milestone, if applicable. 13 | 14 | #### 4. Create the Milestone: 15 | Click on the "Create milestone" button to create the milestone. 16 | 17 | ### Assigning the Milestone to the Issue: 18 | 19 | #### 1. Open the Issue: 20 | Navigate to the issue you want to assign to the milestone. 21 | 22 | #### 2. Edit the Issue: 23 | Click on the "Edit" button (pencil icon) near the top right corner of the issue. 24 | 25 | #### 3. Assign the Milestone: 26 | In the editing interface, locate the "Milestone" section and select the milestone you just created from the dropdown menu. 27 | 28 | #### 4. Save Changes: 29 | Click on the "Save changes" button to save the changes to the issue. 30 | 31 | ### Closing the Milestone: 32 | 33 | #### 1. Navigate to the Milestone: 34 | Go to the "Milestones" section and click on the milestone you want to close. 35 | 36 | #### 2. Close the Milestone: 37 | Click on the "Close milestone" button to mark the milestone as complete. 38 | 39 | #### 3. Confirm Closure: 40 | Confirm the closure of the milestone when prompted. 41 | 42 | ### Summary: 43 | By creating a milestone and assigning it to an issue, you can track progress and organize work effectively. Closing the milestone once the associated tasks are completed helps to mark the completion of a specific goal or phase of the project. This helps in maintaining clarity and accountability throughout the project lifecycle. -------------------------------------------------------------------------------- /05_collaboration/18_forked_repository_up_to_date/readme.md: -------------------------------------------------------------------------------- 1 | Certainly! Here's a step-by-step guide to fork a repository, keep it up to date with the original repository (upstream), and add the original repository as the base URL: 2 | 3 | ### Steps to Fork a Repository and Keep it Up to Date: 4 | 5 | #### 1. Fork the Repository: 6 | - Go to the GitHub page of the repository you want to fork. 7 | - Click on the "Fork" button in the top-right corner of the page. 8 | - Select your GitHub username or organization where you want to fork the repository. 9 | 10 | #### 2. Clone the Forked Repository: 11 | - Copy the URL of your forked repository from the address bar. 12 | - Open your terminal or command prompt. 13 | - Navigate to the directory where you want to clone the repository. 14 | - Run the following command to clone the forked repository to your local machine: 15 | ```sh 16 | git clone https://github.com/hashimthepassionate/mars.git MarsProject 17 | cd MarsProject 18 | ``` 19 | 20 | #### 3. Add the Upstream Remote: 21 | - Copy the URL of the original repository (the one you forked from). 22 | - In the terminal, navigate to your forked repository directory. 23 | - Run the following command to add the original repository as the upstream remote: 24 | ```sh 25 | git remote add upstream https://github.com/hashimthepassionate/moon.git 26 | ``` 27 | 28 | #### 4. Verify Remote Setup: 29 | - To verify that the remotes have been set up correctly, run: 30 | ```sh 31 | git remote -v 32 | ``` 33 | - You should see both `origin` (your fork) and `upstream` (original repository) listed. 34 | 35 | #### 5. Keep Fork Up to Date: 36 | - Regularly fetch changes from the original repository to keep your fork up to date. 37 | - In your terminal, while inside the forked repository directory, run: 38 | ```sh 39 | git fetch upstream 40 | git merge upstream/main 41 | ``` 42 | This fetches changes from the original repository's main branch (assuming the original repository's default branch is named `main`) and merges them into your forked repository's main branch. 43 | 44 | #### 6. Push Changes to Your Fork (Optional): 45 | - If you've made changes to your fork and want to push them to your GitHub repository, use: 46 | ```sh 47 | git push origin main 48 | ``` 49 | 50 | #### Summary: 51 | By forking a repository, adding the original repository as the upstream remote, and regularly fetching changes from the upstream repository, you can keep your fork up to date with the latest changes. This ensures that your fork remains synchronized with the original repository and allows you to contribute to the project effectively. -------------------------------------------------------------------------------- /05_collaboration/19_summary/readme.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HashimThePassionate/learn-git-mastery/cb2e79c89c470d5d8ab5d6a525a4a1494e11c2bb/05_collaboration/19_summary/readme.md -------------------------------------------------------------------------------- /05_collaboration/20_exercises/readme.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HashimThePassionate/learn-git-mastery/cb2e79c89c470d5d8ab5d6a525a4a1494e11c2bb/05_collaboration/20_exercises/readme.md -------------------------------------------------------------------------------- /05_collaboration/readme.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HashimThePassionate/learn-git-mastery/cb2e79c89c470d5d8ab5d6a525a4a1494e11c2bb/05_collaboration/readme.md -------------------------------------------------------------------------------- /06_rewriting_history/01_why_rewriting_commit_history/readme.md: -------------------------------------------------------------------------------- 1 | Rewriting history in GitHub refers to altering the commit history of a repository. This can involve modifying, combining, or removing commits to create a cleaner and more understandable project history. Here’s a step-by-step explanation of why and how we do it, without using Git commands: 2 | 3 | ### Why We Rewrite History 4 | 5 | 1. **Clean Up Commits**: Over time, a repository can accumulate a lot of unnecessary commits, such as those with incomplete features, typo fixes, or debugging changes. Rewriting history helps to condense these into meaningful, polished commits. 6 | 7 | 2. **Remove Sensitive Information**: If sensitive information like passwords or API keys accidentally gets committed, rewriting history allows you to remove these from the repository entirely. 8 | 9 | 3. **Improve Readability**: A clear and concise commit history is easier for collaborators to understand and navigate. It shows a logical progression of changes, making it simpler to review and follow the development process. 10 | 11 | 4. **Squash Commits**: Combining multiple small commits into a single, larger commit can make the history more coherent, especially if those smaller commits are part of a single feature or bug fix. 12 | 13 | 5. **Correct Mistakes**: If incorrect or misleading commit messages were used, rewriting history allows you to amend these to be more accurate and descriptive. 14 | 15 | ### How We Rewrite History 16 | 17 | 1. **Identify the Target Commits**: Determine which commits need to be modified. This involves reviewing the commit history and identifying commits that are redundant, contain mistakes, or have sensitive information. 18 | 19 | 2. **Prepare Your Local Repository**: Ensure you have a local copy of the repository where you can safely make changes without affecting the remote repository or other collaborators initially. 20 | 21 | 3. **Modify the Commits**: Use tools to alter the identified commits. This can include: 22 | - **Rewording Commit Messages**: Updating the commit messages to be more accurate or descriptive. 23 | - **Squashing Commits**: Combining multiple related commits into a single commit. 24 | - **Removing Commits**: Completely removing any commits that are unnecessary or problematic. 25 | - **Editing Commit Content**: Changing the actual content of the commits to fix issues or remove sensitive information. 26 | 27 | 4. **Test Changes Locally**: Verify that the repository still functions as expected with the rewritten history. This ensures that no critical changes were lost or altered incorrectly. 28 | 29 | 5. **Force Update the Remote Repository**: After thoroughly testing, the local changes need to be pushed to the remote repository. This is often done with a force push to overwrite the existing commit history. 30 | 31 | 6. **Communicate with Collaborators**: Inform your team about the rewritten history, as it may affect their local copies of the repository. They will need to synchronize their local repositories to match the new commit history. 32 | 33 | ### Key Considerations 34 | 35 | - **Backup Before Rewriting**: Always make a backup of the repository before making any history changes to avoid data loss. 36 | - **Coordination**: Rewriting history affects all collaborators, so it’s essential to coordinate and communicate effectively. 37 | - **Branch Impact**: Be aware that rewriting history on the main branch can affect all feature branches. It’s often better to rewrite history on branches before they are merged into the main branch. 38 | 39 | Rewriting history is a powerful tool for maintaining a clean and professional GitHub repository, but it must be used carefully to avoid disrupting the workflow and causing confusion among team members. -------------------------------------------------------------------------------- /06_rewriting_history/02_golden_rule_of_rewriting_history/readme.md: -------------------------------------------------------------------------------- 1 | The golden rule of rewriting history in Git is: **Never rewrite history that has been pushed to a shared repository.** 2 | 3 | ### Explanation 4 | 5 | 1. **Impact on Collaboration**: When you rewrite history on a shared branch, it changes the commit IDs of the modified commits. This can create significant issues for collaborators who have already based their work on the previous commit history. Their local copies will diverge from the remote repository, leading to complex and confusing merge conflicts. 6 | 7 | 2. **Commit IDs Change**: Each commit in Git is identified by a unique hash. When you rewrite history, even if the changes seem minor (like editing commit messages or squashing commits), the commit hashes will change. This makes it impossible for Git to automatically reconcile the new history with the old history. 8 | 9 | 3. **Force Pushing**: Rewriting history typically requires a force push (`git push --force`), which forcibly updates the remote branch to match your local branch. This can overwrite others' work if they have pushed changes after your last pull, leading to data loss or the need to manually resolve conflicts. 10 | 11 | ### Best Practices 12 | 13 | - **Rewrite Locally Before Sharing**: If you need to rewrite history, do so on local branches that have not yet been pushed to the shared repository. This ensures that no one else is affected by the changes. 14 | 15 | - **Communicate with Your Team**: If you absolutely must rewrite shared history (which should be rare and only for critical issues like removing sensitive data), communicate clearly with your team. Make sure everyone knows to backup their work and understand the steps they need to take after the rewrite. 16 | 17 | - **Use Feature Branches**: Develop features and fixes in separate branches. Only rewrite history in these feature branches before they are merged into the main branch. Once merged, consider the history immutable. 18 | 19 | - **Backup the Repository**: Before rewriting history, always create a backup of the repository to safeguard against accidental data loss. 20 | 21 | ### Summary 22 | 23 | Adhering to the golden rule of not rewriting shared history helps maintain a stable and reliable collaboration environment. It ensures that the commit history remains consistent for all team members, reducing the risk of conflicts and confusion. -------------------------------------------------------------------------------- /06_rewriting_history/03_getting_bad_history_repository/Mercury.zip: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HashimThePassionate/learn-git-mastery/cb2e79c89c470d5d8ab5d6a525a4a1494e11c2bb/06_rewriting_history/03_getting_bad_history_repository/Mercury.zip -------------------------------------------------------------------------------- /06_rewriting_history/04_undoing_commits/readme.md: -------------------------------------------------------------------------------- 1 | ### Understanding `git reset`: Soft, Mixed, and Hard 2 | 3 | The `git reset` command is used to undo changes in your Git repository. It can move the HEAD pointer and reset the state of your working directory and staging area. There are three modes of `git reset`: soft, mixed, and hard. Here’s an explanation of each, using your example as a guide. 4 | 5 | #### 1. Soft Reset (`--soft`) 6 | 7 | **Purpose:** Moves the HEAD to a specific commit and leaves the changes staged (in the index). 8 | 9 | **Scenario:** 10 | - You want to undo a commit but keep the changes staged for the next commit. 11 | 12 | **Example Steps:** 13 | 14 | 1. **Current Commit History:** 15 | ``` 16 | * 088455d (HEAD -> master) . 17 | * f666091 WIP 18 | * 111bd75 Update terms of service and Google Map SDK version. 19 | ``` 20 | 21 | 2. **Execute Soft Reset:** 22 | ```sh 23 | git reset --soft HEAD~1 24 | ``` 25 | 26 | 3. **Result:** 27 | - The commit `088455d` is undone. 28 | - Changes from `088455d` are staged. 29 | - HEAD points to `f666091`. 30 | 31 | 4. **Verify Changes:** 32 | ```sh 33 | git status -s 34 | ``` 35 | ``` 36 | M terms.txt 37 | ``` 38 | 39 | The changes in `terms.txt` are staged but not committed. 40 | 41 | #### 2. Mixed Reset (`--mixed`) 42 | 43 | **Purpose:** Moves the HEAD to a specific commit and unstages the changes (keeps them in the working directory). 44 | 45 | **Scenario:** 46 | - You want to undo a commit and unstage the changes, but keep the changes in the working directory. 47 | 48 | **Example Steps:** 49 | 50 | 1. **Current Commit History:** 51 | ``` 52 | * f666091 (HEAD -> master) WIP 53 | * 111bd75 Update terms of service and Google Map SDK version. 54 | ``` 55 | 56 | 2. **Execute Mixed Reset:** 57 | ```sh 58 | git reset --mixed HEAD 59 | ``` 60 | 61 | 3. **Result:** 62 | - The commit `088455d` is undone. 63 | - Changes from `088455d` are unstaged. 64 | - HEAD points to `f666091`. 65 | 66 | 4. **Verify Changes:** 67 | ```sh 68 | git status -s 69 | ``` 70 | ``` 71 | M terms.txt 72 | ``` 73 | The changes in `terms.txt` are in the working directory but not staged. 74 | 75 | #### 3. Hard Reset (`--hard`) 76 | 77 | **Purpose:** Moves the HEAD to a specific commit and discards all changes in the working directory and staging area. 78 | 79 | **Scenario:** 80 | - You want to completely undo a commit and discard all changes. 81 | 82 | **Example Steps:** 83 | 84 | 1. **Current Commit History:** 85 | ``` 86 | * f666091 (HEAD -> master) WIP 87 | * 111bd75 Update terms of service and Google Map SDK version. 88 | ``` 89 | 90 | 2. **Execute Hard Reset:** 91 | ```sh 92 | git reset --hard HEAD 93 | ``` 94 | 95 | 3. **Result:** 96 | - The commit `088455d` is undone. 97 | - All changes in `terms.txt` are discarded. 98 | - HEAD points to `f666091`. 99 | 100 | 4. **Verify Changes:** 101 | ```sh 102 | git status -s 103 | ``` 104 | No changes should be shown, as everything is reset to `f666091`. 105 | 106 | ### Summary 107 | 108 | - **Soft Reset:** Keeps changes staged. 109 | - **Mixed Reset:** Keeps changes in the working directory but unstaged. 110 | - **Hard Reset:** Discards all changes and resets to a specific commit. 111 | 112 | These reset modes help manage your commit history and working state, allowing you to correct mistakes or refine your project’s history as needed. -------------------------------------------------------------------------------- /06_rewriting_history/05_reverting_commits/readme.md: -------------------------------------------------------------------------------- 1 | ### Why Use `git revert` Instead of `git reset --hard` on a Remote Repository 2 | 3 | Using `git revert` instead of `git reset --hard` on a remote repository is essential for maintaining a collaborative and stable environment. Here’s why: 4 | 5 | 1. **Preservation of History**: `git revert` creates a new commit that undoes the changes introduced by previous commits without altering the commit history. This maintains a clear and traceable history of all changes made to the repository. 6 | 7 | 2. **Avoiding Disruption**: `git reset --hard` rewrites the commit history, which can disrupt the work of other collaborators. When others have based their work on the commit history you are rewriting, it causes conflicts and confusion. 8 | 9 | 3. **Safe Collaboration**: In a shared repository, `git revert` ensures that everyone has a consistent view of the project’s history. It avoids the need for force-pushing changes, which can overwrite other people’s work. 10 | 11 | ### Explanation of Steps Using `git revert` 12 | 13 | Here’s a detailed explanation of how to use `git revert` to undo changes while keeping the repository history intact, based on your example: 14 | 15 | 1. **View the Commit History:** 16 | ```sh 17 | git log --oneline --all --graph 18 | ``` 19 | ``` 20 | * f666091 (HEAD -> master) WIP 21 | * 111bd75 Update terms of service and Google Map SDK version. 22 | * 72856ea WIP 23 | * 8441b05 Add a reference to Google Map SDK. 24 | * 8527033 Change the color of restaurant icons. 25 | * af26a96 Fix a typo. 26 | * 6fb2ba7 Render restaurants the map. 27 | * 70ef834 Initial commit 28 | ``` 29 | 30 | 2. **Revert the Last Three Commits:** 31 | ```sh 32 | git revert --no-commit HEAD~3.. 33 | ``` 34 | - This command prepares the repository to revert the changes made by the last three commits but does not create the revert commit yet. 35 | - You are now in a state where the changes are undone in your working directory, and you need to continue the revert process. 36 | 37 | 3. **Check the Status:** 38 | ```sh 39 | git status -s 40 | ``` 41 | ``` 42 | M map.txt 43 | M package.txt 44 | D terms.txt 45 | ``` 46 | - These are the changes that will be included in the revert commit. 47 | 48 | 4. **Continue the Revert Process:** 49 | ```sh 50 | git revert --continue 51 | ``` 52 | - This completes the revert operation by creating a new commit that undoes the changes introduced by the specified commits. 53 | 54 | 5. **View the Updated Commit History:** 55 | ```sh 56 | git log --oneline --all --graph 57 | ``` 58 | ``` 59 | * 0cd0b85 (HEAD -> master) Reverting bad code 60 | * f666091 WIP 61 | * 111bd75 Update terms of service and Google Map SDK version. 62 | * 72856ea WIP 63 | * 8441b05 Add a reference to Google Map SDK. 64 | * 8527033 Change the color of restaurant icons. 65 | * af26a96 Fix a typo. 66 | * 6fb2ba7 Render restaurants the map. 67 | * 70ef834 Initial commit 68 | ``` 69 | - The new commit `0cd0b85` documents the reversal of the changes, keeping the history intact and clear. 70 | 71 | ### Summary 72 | 73 | Using `git revert` is crucial in a collaborative environment as it safely undoes changes by creating new commits, thereby preserving the commit history and avoiding disruptions for other contributors. This method ensures that everyone working on the project has a consistent and stable view of the repository’s history, promoting a smooth and effective collaboration process. -------------------------------------------------------------------------------- /06_rewriting_history/06_recovering_lost_commits/readme.md: -------------------------------------------------------------------------------- 1 | ### Recovering Lost Commits with Git Reflog 2 | 3 | When you perform a hard reset, it might seem like you’ve permanently lost commits. However, Git keeps a record of all changes to the HEAD pointer in the reflog, allowing you to recover those commits. Here’s an explanation of the process you followed to recover lost commits using `git reflog`. 4 | 5 | ### Steps Explained 6 | 7 | 1. **View the Current Commit History:** 8 | ```sh 9 | git log --oneline --all --graph 10 | ``` 11 | Output: 12 | ``` 13 | * 0cd0b85 (HEAD -> master) Reverting bad code 14 | * f666091 WIP 15 | * 111bd75 Update terms of service and Google Map SDK version. 16 | * 72856ea WIP 17 | * 8441b05 Add a reference to Google Map SDK. 18 | * 8527033 Change the color of restaurant icons. 19 | * af26a96 Fix a typo. 20 | * 6fb2ba7 Render restaurants the map. 21 | * 70ef834 Initial commit 22 | ``` 23 | 24 | This shows the current state of your repository, with the latest commit being `0cd0b85` (Reverting bad code). 25 | 26 | 2. **Perform a Hard Reset:** 27 | ```sh 28 | git reset --hard HEAD~6 29 | ``` 30 | - This command resets the HEAD to the commit six commits back from the current HEAD. 31 | - It removes the latest six commits from the history. 32 | 33 | 3. **View the Updated Commit History:** 34 | ```sh 35 | git log --oneline --all --graph 36 | ``` 37 | Output: 38 | ``` 39 | * af26a96 (HEAD -> master) Fix a typo. 40 | * 6fb2ba7 Render restaurants the map. 41 | * 70ef834 Initial commit 42 | ``` 43 | 44 | The commit history now only shows the first three commits, indicating that the latest six commits have been removed. 45 | 46 | 4. **View the Reflog:** 47 | ```sh 48 | git reflog 49 | ``` 50 | Output: 51 | ``` 52 | af26a96 (HEAD -> master) HEAD@{0}: reset: moving to HEAD~6 53 | 0cd0b85 HEAD@{1}: commit: Reverting bad code 54 | f666091 HEAD@{2}: reset: moving to f666091b6691ed523dc80af32e900c365e434c24 55 | f666091 HEAD@{3}: reset: moving to HEAD 56 | f666091 HEAD@{4}: reset: moving to HEAD 57 | f666091 HEAD@{5}: reset: moving to HEAD~1 58 | 088455d HEAD@{6}: commit: . 59 | f666091 HEAD@{7}: commit: WIP 60 | 111bd75 HEAD@{8}: commit: Update terms of service and Google Map SDK version. 61 | 72856ea HEAD@{9}: commit: WIP 62 | 8441b05 HEAD@{10}: commit: Add a reference to Google Map SDK. 63 | 8527033 HEAD@{11}: commit: Change the color of restaurant icons. 64 | af26a96 (HEAD -> master) HEAD@{12}: commit: Fix a typo. 65 | 6fb2ba7 HEAD@{13}: commit: Render restaurants the map. 66 | 70ef834 HEAD@{14}: commit (initial): Initial commit 67 | ``` 68 | 69 | The reflog shows a record of all changes to the HEAD pointer. Each entry indicates the previous position of HEAD, allowing you to recover lost commits. 70 | 71 | 5. **Recover the Lost Commits:** 72 | ```sh 73 | git reset --hard HEAD@{1} 74 | ``` 75 | - This command moves the HEAD back to the state it was in at `HEAD@{1}`, which corresponds to the commit `0cd0b85` (Reverting bad code). 76 | 77 | 6. **Verify the Commit History:** 78 | ```sh 79 | git log --oneline --all --graph 80 | ``` 81 | Output: 82 | ``` 83 | * 0cd0b85 (HEAD -> master) Reverting bad code 84 | * f666091 WIP 85 | * 111bd75 Update terms of service and Google Map SDK version. 86 | * 72856ea WIP 87 | * 8441b05 Add a reference to Google Map SDK. 88 | * 8527033 Change the color of restaurant icons. 89 | * af26a96 Fix a typo. 90 | * 6fb2ba7 Render restaurants the map. 91 | * 70ef834 Initial commit 92 | ``` 93 | 94 | The commit history is now restored to its previous state, including all the commits that were "lost" due to the hard reset. 95 | 96 | ### Summary 97 | 98 | By using the reflog, you can recover lost commits even after performing operations like `git reset --hard`. The reflog tracks all movements of the HEAD pointer, allowing you to identify and restore previous states of your repository. This ensures that no commit is ever truly lost, providing a safety net for repository management. -------------------------------------------------------------------------------- /06_rewriting_history/07_amending_the_last_commits/readme.md: -------------------------------------------------------------------------------- 1 | ### Why Use `git commit --amend`? 2 | 3 | Amending the last commit in Git is a useful technique for making corrections or additions to your most recent commit without creating a new commit. This is particularly helpful for: 4 | 5 | - Correcting mistakes in the last commit message. 6 | - Adding or removing changes from the last commit. 7 | - Avoiding cluttering the commit history with multiple minor fix commits. 8 | 9 | Here’s a step-by-step explanation of using `git commit --amend` and how it was applied in your example: 10 | 11 | ### Step-by-Step Explanation 12 | 13 | 1. **Initial State: View the Commit History** 14 | ```sh 15 | git log --oneline --all --graph 16 | ``` 17 | Output: 18 | ``` 19 | * 0cd0b85 (HEAD -> master) Reverting bad code 20 | * f666091 WIP 21 | * 111bd75 Update terms of service and Google Map SDK version. 22 | * 72856ea WIP 23 | * 8441b05 Add a reference to Google Map SDK. 24 | * 8527033 Change the color of restaurant icons. 25 | * af26a96 Fix a typo. 26 | * 6fb2ba7 Render restaurants the map. 27 | * 70ef834 Initial commit 28 | ``` 29 | 30 | 2. **Make Changes to a File:** 31 | ```sh 32 | echo cafes >> map.txt 33 | ``` 34 | 35 | 3. **Check the Status of Changes:** 36 | ```sh 37 | git status -s 38 | ``` 39 | Output: 40 | ``` 41 | M map.txt 42 | ``` 43 | 44 | 4. **Stage and Commit the Changes:** 45 | ```sh 46 | git commit -am "Render cafes on the map" 47 | ``` 48 | Output: 49 | ``` 50 | [master f8b5d10] Render cafes on the map 51 | 1 file changed, 1 insertion(+) 52 | ``` 53 | 54 | 5. **View the Updated Commit History:** 55 | ```sh 56 | git log --oneline --all --graph 57 | ``` 58 | Output: 59 | ``` 60 | * f8b5d10 (HEAD -> master) Render cafes on the map 61 | * 0cd0b85 Reverting bad code 62 | * f666091 WIP 63 | * 111bd75 Update terms of service and Google Map SDK version. 64 | * 72856ea WIP 65 | * 8441b05 Add a reference to Google Map SDK. 66 | * 8527033 Change the color of restaurant icons. 67 | * af26a96 Fix a typo. 68 | * 6fb2ba7 Render restaurants the map. 69 | * 70ef834 Initial commit 70 | ``` 71 | 72 | 6. **Make Additional Changes to the Same File:** 73 | ```sh 74 | echo >> map.txt 75 | echo blue >> map.txt 76 | ``` 77 | 78 | 7. **Stage the New Changes:** 79 | ```sh 80 | git add . 81 | ``` 82 | 83 | 8. **Amend the Previous Commit with the New Changes:** 84 | ```sh 85 | git commit --amend 86 | ``` 87 | Output: 88 | ``` 89 | [master d3e877e] Render cafes on the map 90 | Date: Sun May 19 22:05:25 2024 +0500 91 | 1 file changed, 2 insertions(+) 92 | ``` 93 | 94 | 9. **Verify the Amended Commit:** 95 | ```sh 96 | git log --oneline --all 97 | ``` 98 | Output: 99 | ``` 100 | d3e877e (HEAD -> master) Render cafes on the map 101 | 0cd0b85 Reverting bad code 102 | f666091 WIP 103 | 111bd75 Update terms of service and Google Map SDK version. 104 | 72856ea WIP 105 | 8441b05 Add a reference to Google Map SDK. 106 | 8527033 Change the color of restaurant icons. 107 | af26a96 Fix a typo. 108 | 6fb2ba7 Render restaurants the map. 109 | 70ef834 Initial commit 110 | ``` 111 | 112 | 10. **Make Additional Changes and Stage Them:** 113 | ```sh 114 | echo Hello > file1.txt 115 | git add . 116 | ``` 117 | 118 | 11. **Amend the Commit Again with the New Changes:** 119 | ```sh 120 | git commit --amend 121 | ``` 122 | Output: 123 | ``` 124 | [master 6843550] Render cafes on the map 125 | Date: Sun May 19 22:05:25 2024 +0500 126 | 2 files changed, 3 insertions(+) 127 | create mode 100644 file1.txt 128 | ``` 129 | 130 | 12. **View the Final Commit History:** 131 | ```sh 132 | git log --oneline --all 133 | ``` 134 | Output: 135 | ``` 136 | 6843550 (HEAD -> master) Render cafes on the map 137 | 0cd0b85 Reverting bad code 138 | f666091 WIP 139 | 111bd75 Update terms of service and Google Map SDK version. 140 | 72856ea WIP 141 | 8441b05 Add a reference to Google Map SDK. 142 | 8527033 Change the color of restaurant icons. 143 | af26a96 Fix a typo. 144 | 6fb2ba7 Render restaurants the map. 145 | 70ef834 Initial commit 146 | ``` 147 | 148 | ### Summary 149 | 150 | The `git commit --amend` command is a powerful tool for refining the last commit. It allows you to correct mistakes or include additional changes, keeping your commit history clean and meaningful. In your example, you used it to update the commit with additional changes to `map.txt` and the creation of `file1.txt`, ensuring all related changes are captured in a single, cohesive commit. -------------------------------------------------------------------------------- /06_rewriting_history/08_amending_an_earlier_commit/readme.md: -------------------------------------------------------------------------------- 1 | ### Step-by-Step Explanation: 2 | 3 | 1. **View the Commit History:** 4 | ```sh 5 | git log --oneline 6 | ``` 7 | Output: 8 | ``` 9 | 46d4118 (HEAD -> master) Render cafes on the maps 10 | 0cd0b85 Reverting bad code 11 | f666091 WIP 12 | 111bd75 Update terms of service and Google Map SDK version. 13 | 72856ea WIP 14 | 8441b05 Add a reference to Google Map SDK. 15 | 8527033 Change the color of restaurant icons. 16 | af26a96 Fix a typo. 17 | 6fb2ba7 Render restaurants the map. 18 | 70ef834 Initial commit 19 | ``` 20 | 21 | 2. **View Details of a Specific Commit:** 22 | ```sh 23 | git show 8441b05 24 | ``` 25 | Output: 26 | ``` 27 | commit 8441b059eda5262f08f8030e383a72256adc8bd7 28 | Author: Moshfegh Hamedani 29 | Date: Wed Sep 9 17:41:49 2020 -0700 30 | 31 | Add a reference to Google Map SDK. 32 | 33 | diff --git a/package.txt b/package.txt 34 | new file mode 100644 35 | index 0000000..7324ece 36 | --- /dev/null 37 | +++ b/package.txt 38 | @@ -0,0 +1 @@ 39 | +Google Map 1.0.0 40 | ``` 41 | 42 | 3. **Initiate an Interactive Rebase:** 43 | ```sh 44 | git rebase -i 8527033 45 | ``` 46 | Output: 47 | ``` 48 | Stopped at 8441b05... Add a reference to Google Map SDK. 49 | You can amend the commit now, with 50 | 51 | git commit --amend 52 | 53 | Once you are satisfied with your changes, run 54 | 55 | git rebase --continue 56 | ``` 57 | 58 | 4. **Create a New File and Check Status:** 59 | ```sh 60 | echo license > license.txt 61 | git status -s 62 | ``` 63 | Output: 64 | ``` 65 | ?? license.txt 66 | ``` 67 | 68 | 5. **Stage and Amend the Commit:** 69 | ```sh 70 | git add . 71 | git commit --amend 72 | ``` 73 | Output: 74 | ``` 75 | [detached HEAD 3fdac0a] Add a reference to Google Map SDK. 76 | Author: Moshfegh Hamedani 77 | Date: Wed Sep 9 17:41:49 2020 -0700 78 | 2 files changed, 2 insertions(+) 79 | create mode 100644 license.txt 80 | create mode 100644 package.txt 81 | ``` 82 | 83 | 6. **Continue the Rebase Process:** 84 | ```sh 85 | git rebase --continue 86 | ``` 87 | Output: 88 | ``` 89 | Successfully rebased and updated refs/heads/master. 90 | ``` 91 | 92 | 7. **View the Updated Commit History:** 93 | ```sh 94 | git log --oneline --all --graph 95 | ``` 96 | Output: 97 | ``` 98 | * 491c434 (HEAD -> master) Render cafes on the maps 99 | * 244097d Reverting bad code 100 | * 4cfdcdf WIP 101 | * d3ee50e Update terms of service and Google Map SDK version. 102 | * 559ca3d WIP 103 | * 3fdac0a Add a reference to Google Map SDK. 104 | * 8527033 Change the color of restaurant icons. 105 | * af26a96 Fix a typo. 106 | * 6fb2ba7 Render restaurants the map. 107 | * 70ef834 Initial commit 108 | ``` 109 | 110 | 8. **View Details of the Amended Commit:** 111 | ```sh 112 | git show 3fdac0a 113 | ``` 114 | Output: 115 | ``` 116 | commit 3fdac0a8c0c36d1dc11acaa5dfa1590cd43163ce 117 | Author: Moshfegh Hamedani 118 | Date: Wed Sep 9 17:41:49 2020 -0700 119 | 120 | Add a reference to Google Map SDK. 121 | 122 | diff --git a/license.txt b/license.txt 123 | new file mode 100644 124 | index 0000000..cdc5d66 125 | --- /dev/null 126 | +++ b/license.txt 127 | @@ -0,0 +1 @@ 128 | +license 129 | diff --git a/package.txt b/package.txt 130 | new file mode 100644 131 | index 0000000..7324ece 132 | --- /dev/null 133 | +++ b/package.txt 134 | @@ -0,0 +1 @@ 135 | +Google Map 1.0.0 136 | ``` 137 | 138 | ### Summary: 139 | 140 | In summary, you initiated an interactive rebase to edit an earlier commit (`Add a reference to Google Map SDK.`). Then you amended that commit by adding a new file (`license.txt`). Finally, you continued the rebase process to update the commit history. -------------------------------------------------------------------------------- /06_rewriting_history/09_dropping_commits/readme.md: -------------------------------------------------------------------------------- 1 | Sure, let's break down the steps involved in dropping commits: 2 | 3 | 1. **View the Commit History:** 4 | ```sh 5 | git log --oneline --all 6 | ``` 7 | Output: 8 | ``` 9 | 491c434 (HEAD -> master) Render cafes on the maps 10 | 244097d Reverting bad code 11 | 4cfdcdf WIP 12 | d3ee50e Update terms of service and Google Map SDK version. 13 | 559ca3d WIP 14 | 3fdac0a Add a reference to Google Map SDK. 15 | 8527033 Change the color of restaurant icons. 16 | af26a96 Fix a typo. 17 | 6fb2ba7 Render restaurants the map. 18 | 70ef834 Initial commit 19 | ``` 20 | 21 | 2. **View Details of Specific Commits:** 22 | ```sh 23 | git show 559ca3d 24 | git show d3ee50e 25 | ``` 26 | Output: 27 | ``` 28 | commit 559ca3da46b6e8884f23cb4d78fce2eeb21a03bf 29 | Author: Moshfegh Hamedani 30 | Date: Wed Sep 9 17:42:00 2020 -0700 31 | 32 | WIP 33 | 34 | diff --git a/terms.txt b/terms.txt 35 | new file mode 100644 36 | index 0000000..f3d4377 37 | --- /dev/null 38 | +++ b/terms.txt 39 | @@ -0,0 +1 @@ 40 | +draft 41 | ``` 42 | 43 | ``` 44 | commit d3ee50e11d568d03f2a62f5e3a2534da65cda779 45 | Author: Moshfegh Hamedani 46 | Date: Wed Sep 9 17:42:34 2020 -0700 47 | 48 | Update terms of service and Google Map SDK version. 49 | 50 | diff --git a/package.txt b/package.txt 51 | index 7324ece..5111c93 100644 52 | --- a/package.txt 53 | +++ b/package.txt 54 | @@ -1 +1 @@ 55 | -Google Map 1.0.0 56 | +Google Map 2.0.0 57 | diff --git a/terms.txt b/terms.txt 58 | index f3d4377..6ab9fed 100644 59 | --- a/terms.txt 60 | +++ b/terms.txt 61 | @@ -1 +1 @@ 62 | -draft 63 | +completed 64 | ``` 65 | 66 | 3. **Initiate an Interactive Rebase to Drop Commits:** 67 | ```sh 68 | git rebase -i 559ca3d^ 69 | ``` 70 | Output: 71 | ``` 72 | CONFLICT (modify/delete): terms.txt deleted in HEAD and modified in d3ee50e (Update terms of service and Google Map SDK version.). Version d3ee50e (Update terms of service and Google Map SDK version.) of terms.txt left in tree. 73 | error: could not apply d3ee50e... Update terms of service and Google Map SDK version. 74 | hint: Resolve all conflicts manually, mark them as resolved with 75 | hint: "git add/rm ", then run "git rebase --continue". 76 | hint: You can instead skip this commit: run "git rebase --skip". 77 | hint: To abort and get back to the state before "git rebase", run "git rebase --abort". 78 | Could not apply d3ee50e... Update terms of service and Google Map SDK version. 79 | ``` 80 | 81 | 4. **Check Status and Resolve Conflicts:** 82 | ```sh 83 | git status -s 84 | git mergetool 85 | ``` 86 | Output: 87 | ``` 88 | M package.txt 89 | DU terms.txt 90 | ``` 91 | 92 | 5. **Continue the Rebase Process:** 93 | ```sh 94 | git rebase --continue 95 | ``` 96 | Output: 97 | ``` 98 | Successfully rebased and updated refs/heads/master. 99 | ``` 100 | 101 | 6. **View the Updated Commit History:** 102 | ```sh 103 | git log --oneline --all --graph 104 | ``` 105 | Output: 106 | ``` 107 | * 04bf4af (HEAD -> master) Render cafes on the maps 108 | * ea73870 Reverting bad code 109 | * 3abdc41 WIP 110 | * 453f9e0 Update terms of service and Google Map SDK version. 111 | * 3fdac0a Add a reference to Google Map SDK. 112 | * 8527033 Change the color of restaurant icons. 113 | * af26a96 Fix a typo. 114 | * 6fb2ba7 Render restaurants the map. 115 | * 70ef834 Initial commit 116 | ``` 117 | 118 | In this scenario, you attempted to drop commits using an interactive rebase but encountered a conflict that needed manual resolution. After resolving the conflict, you continued the rebase process, successfully dropping the commits and updating the commit history. -------------------------------------------------------------------------------- /06_rewriting_history/10_rewording_commits_messages/readme.md: -------------------------------------------------------------------------------- 1 | To reword commit messages using an interactive rebase, you followed these steps: 2 | 3 | 1. **View the Commit History:** 4 | ```sh 5 | git log --oneline 6 | ``` 7 | Output: 8 | ``` 9 | 528758b (HEAD -> master) Render cafes on the maps 10 | 453f9e0 Update terms of service and Google Map SDK version. 11 | 3fdac0a Add a reference to Google Map SDK. 12 | 8527033 Change the color of restaurant icons. 13 | af26a96 Fix a typo. 14 | 6fb2ba7 Render restaurants the map. 15 | 70ef834 Initial commit 16 | ``` 17 | 18 | 2. **Initiate an Interactive Rebase to Reword Commit Messages:** 19 | ```sh 20 | git rebase -i 6fb2ba7^ 21 | ``` 22 | This command opens an editor with a list of commits. 23 | 24 | 3. **In the Editor:** 25 | - Change `pick` to `reword` for the commits you want to reword. 26 | - Save and close the editor. 27 | 28 | 4. **Reword the Commit Message:** 29 | In this step, you modified the commit message for the commit `6fb2ba7` to "Render restaurants on the map." 30 | 31 | 5. **Continue the Rebase Process:** 32 | After saving the changes in the editor, Git automatically continues the rebase process. 33 | 34 | 6. **View the Updated Commit History:** 35 | ```sh 36 | git log --oneline 37 | ``` 38 | Output: 39 | ``` 40 | 4d7aa04 (HEAD -> master) Render cafes on the maps 41 | eaf37d5 Update terms of service and Google Map SDK version. 42 | 37e6289 Add a reference to Google Map SDK. 43 | 157d968 Change the color of restaurant icons. 44 | 12e3f9c Fix a typo. 45 | bd6b847 Render restaurants on the map. 46 | 70ef834 Initial commit 47 | ``` 48 | 49 | After completing these steps, the commit message for the specified commit (`6fb2ba7`) was successfully reworded. -------------------------------------------------------------------------------- /06_rewriting_history/11_reordering_commits/readme.md: -------------------------------------------------------------------------------- 1 | To reorder commits using an interactive rebase, here's what you did: 2 | 3 | 1. **View the Commit History:** 4 | ```sh 5 | git log --oneline 6 | ``` 7 | Output: 8 | ``` 9 | 4d7aa04 (HEAD -> master) Render cafes on the maps 10 | eaf37d5 Update terms of service and Google Map SDK version. 11 | 37e6289 Add a reference to Google Map SDK. 12 | 157d968 Change the color of restaurant icons. 13 | 12e3f9c Fix a typo. 14 | bd6b847 Render restaurants on the map. 15 | 70ef834 Initial commit 16 | ``` 17 | 18 | 2. **Initiate an Interactive Rebase to Reorder Commits:** 19 | ```sh 20 | git rebase -i 70ef834 21 | ``` 22 | This command opens an editor with a list of commits. 23 | 24 | 3. **In the Editor:** 25 | - Reorder the commits as desired by changing their order in the list. 26 | - Save and close the editor. 27 | 28 | 4. **Continue the Rebase Process:** 29 | After saving the changes in the editor, Git automatically continues the rebase process. 30 | 31 | 5. **View the Updated Commit History:** 32 | ```sh 33 | git log --oneline 34 | ``` 35 | Output: 36 | ``` 37 | a0fad60 (HEAD -> master) Render cafes on the maps 38 | fd4b3f4 Update terms of service and Google Map SDK version. 39 | 8fc2741 Change the color of restaurant icons. 40 | 146c49c Fix a typo. 41 | 1e4ffcc Render restaurants on the map. 42 | 944a2ca Add a reference to Google Map SDK. 43 | 70ef834 Initial commit 44 | ``` 45 | 46 | After completing these steps, the commits were successfully reordered according to your specifications. -------------------------------------------------------------------------------- /06_rewriting_history/12_squashing_commits/readme.md: -------------------------------------------------------------------------------- 1 | To squash commits, you follow a similar process to reordering commits with an interactive rebase: 2 | 3 | 1. **View the Commit History:** 4 | ```sh 5 | git log --oneline 6 | ``` 7 | Output: 8 | ``` 9 | a0fad60 (HEAD -> master) Render cafes on the maps 10 | fd4b3f4 Update terms of service and Google Map SDK version. 11 | 8fc2741 Change the color of restaurant icons. 12 | 146c49c Fix a typo. 13 | 1e4ffcc Render restaurants on the map. 14 | 944a2ca Add a reference to Google Map SDK. 15 | 70ef834 Initial commit 16 | ``` 17 | 18 | 2. **Initiate an Interactive Rebase to Squash Commits:** 19 | ```sh 20 | git rebase -i 944a2ca^ 21 | ``` 22 | This command opens an editor with a list of commits. 23 | 24 | 3. **In the Editor:** 25 | - Mark the commits you want to squash with "squash" or "s". 26 | - Save and close the editor. 27 | 28 | 4. **Edit the Commit Message (if necessary):** 29 | After marking the commits for squashing, Git will open another editor to allow you to edit the commit message for the squashed commit. 30 | 31 | 5. **Continue the Rebase Process:** 32 | After saving the changes in the editor, Git will automatically continue the rebase process. 33 | 34 | 6. **View the Updated Commit History:** 35 | ```sh 36 | git log --oneline 37 | ``` 38 | Output: 39 | ``` 40 | a39da7e (HEAD -> master) Render cafes on the maps 41 | 5287c8c Update terms of service and Google Map SDK version. 42 | c432f2c Render restaurants on the map. 43 | 944a2ca Add a reference to Google Map SDK. 44 | 70ef834 Initial commit 45 | ``` 46 | 47 | After completing these steps, the specified commits were squashed into a single commit, and the commit history was updated accordingly. -------------------------------------------------------------------------------- /06_rewriting_history/13_splitting_commits/readme.md: -------------------------------------------------------------------------------- 1 | Here's a detailed explanation of the steps you took to split a commit into two separate commits: 2 | 3 | ### Initial State 4 | 5 | You started with the following commit history: 6 | ```sh 7 | git log --oneline --all --graph 8 | * a39da7e (HEAD -> master) Render cafes on the maps 9 | * 5287c8c Update terms of service and Google Map SDK version. 10 | * c432f2c Render restaurants on the map. 11 | * 944a2ca Add a reference to Google Map SDK. 12 | * 70ef834 Initial commit 13 | ``` 14 | 15 | ### Starting the Rebase 16 | 17 | 1. **Initiate an Interactive Rebase:** 18 | ```sh 19 | git rebase -i 5287c8c^ 20 | ``` 21 | This command opens an editor for an interactive rebase starting from the commit before `5287c8c`. 22 | 23 | 2. **Stop at the Commit to Split:** 24 | The interactive rebase stopped at the commit `5287c8c` and you were prompted to amend the commit: 25 | ```sh 26 | Stopped at 5287c8c... Update terms of service and Google Map SDK version. 27 | You can amend the commit now, with 28 | git commit --amend 29 | Once you are satisfied with your changes, run 30 | ``` 31 | 32 | ### Splitting the Commit 33 | 34 | 3. **Reset to Unstage Changes:** 35 | ```sh 36 | git reset --mixed HEAD^ 37 | ``` 38 | This command unstages the changes from the commit `5287c8c` but keeps them in the working directory. 39 | 40 | 4. **Check the Status:** 41 | ```sh 42 | git status -s 43 | ``` 44 | Output: 45 | ```sh 46 | M package.txt 47 | ?? terms.txt 48 | ``` 49 | 50 | 5. **Stage and Commit the First Change:** 51 | ```sh 52 | git add package.txt 53 | git commit -m "Update Google Map SDK version 1.0 => 2.0" 54 | ``` 55 | This creates a new commit `e3e0263` with the changes to `package.txt`. 56 | 57 | 6. **Check the Commit History:** 58 | ```sh 59 | git log --oneline --all --graph 60 | ``` 61 | Output: 62 | ```sh 63 | * e3e0263 (HEAD) Update Google Map SDK version 1.0 => 2.0 64 | | * a39da7e (master) Render cafes on the maps 65 | | * 5287c8c Update terms of service and Google Map SDK version. 66 | |/ 67 | * c432f2c Render restaurants on the map. 68 | * 944a2ca Add a reference to Google Map SDK. 69 | * 70ef834 Initial commit 70 | ``` 71 | 72 | 7. **Stage and Commit the Second Change:** 73 | ```sh 74 | git add terms.txt 75 | git commit -m "Add terms of services" 76 | ``` 77 | This creates another new commit `56e3b7a` with the changes to `terms.txt`. 78 | 79 | 8. **Check the Commit History Again:** 80 | ```sh 81 | git log --oneline --all --graph 82 | ``` 83 | Output: 84 | ```sh 85 | * 56e3b7a (HEAD) Add terms of services 86 | * e3e0263 Update Google Map SDK version 1.0 => 2.0 87 | | * a39da7e (master) Render cafes on the maps 88 | | * 5287c8c Update terms of service and Google Map SDK version. 89 | |/ 90 | * c432f2c Render restaurants on the map. 91 | * 944a2ca Add a reference to Google Map SDK. 92 | * 70ef834 Initial commit 93 | ``` 94 | 95 | ### Completing the Rebase 96 | 97 | 9. **Continue the Rebase:** 98 | ```sh 99 | git rebase --continue 100 | ``` 101 | This completes the rebase process and updates the commit history on the `master` branch. 102 | 103 | 10. **Final Commit History:** 104 | ```sh 105 | git log --oneline --all --graph 106 | ``` 107 | Output: 108 | ```sh 109 | * 08e5382 (HEAD -> master) Render cafes on the maps 110 | * 56e3b7a Add terms of services 111 | * e3e0263 Update Google Map SDK version 1.0 => 2.0 112 | * c432f2c Render restaurants on the map 113 | * 944a2ca Add a reference to Google Map SDK 114 | * 70ef834 Initial commit 115 | ``` 116 | 117 | By following these steps, you successfully split the original commit `5287c8c` into two separate commits: `e3e0263` (updating the SDK version) and `56e3b7a` (adding the terms of service). -------------------------------------------------------------------------------- /06_rewriting_history/14_summary/Summary.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HashimThePassionate/learn-git-mastery/cb2e79c89c470d5d8ab5d6a525a4a1494e11c2bb/06_rewriting_history/14_summary/Summary.pdf -------------------------------------------------------------------------------- /06_rewriting_history/readme.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HashimThePassionate/learn-git-mastery/cb2e79c89c470d5d8ab5d6a525a4a1494e11c2bb/06_rewriting_history/readme.md -------------------------------------------------------------------------------- /07_setting-up[oh-my-posh]/1.Create bash_profile.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HashimThePassionate/learn-git-mastery/cb2e79c89c470d5d8ab5d6a525a4a1494e11c2bb/07_setting-up[oh-my-posh]/1.Create bash_profile.PNG -------------------------------------------------------------------------------- /07_setting-up[oh-my-posh]/2.Open bash_profile in vs code.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HashimThePassionate/learn-git-mastery/cb2e79c89c470d5d8ab5d6a525a4a1494e11c2bb/07_setting-up[oh-my-posh]/2.Open bash_profile in vs code.png -------------------------------------------------------------------------------- /07_setting-up[oh-my-posh]/3.Save json file.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HashimThePassionate/learn-git-mastery/cb2e79c89c470d5d8ab5d6a525a4a1494e11c2bb/07_setting-up[oh-my-posh]/3.Save json file.PNG -------------------------------------------------------------------------------- /07_setting-up[oh-my-posh]/4.Carriage return and line feed.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HashimThePassionate/learn-git-mastery/cb2e79c89c470d5d8ab5d6a525a4a1494e11c2bb/07_setting-up[oh-my-posh]/4.Carriage return and line feed.png -------------------------------------------------------------------------------- /07_setting-up[oh-my-posh]/4.Configure oh my posh.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HashimThePassionate/learn-git-mastery/cb2e79c89c470d5d8ab5d6a525a4a1494e11c2bb/07_setting-up[oh-my-posh]/4.Configure oh my posh.PNG -------------------------------------------------------------------------------- /07_setting-up[oh-my-posh]/5.Final Result.PNG: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HashimThePassionate/learn-git-mastery/cb2e79c89c470d5d8ab5d6a525a4a1494e11c2bb/07_setting-up[oh-my-posh]/5.Final Result.PNG -------------------------------------------------------------------------------- /07_setting-up[oh-my-posh]/iterm2.omp.json: -------------------------------------------------------------------------------- 1 | { 2 | "$schema": "https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/main/themes/schema.json", 3 | "blocks": [ 4 | { 5 | "alignment": "left", 6 | "segments": [ 7 | { 8 | "background": "#003543", 9 | "foreground": "#fff", 10 | "powerline_symbol": "\ue0b0", 11 | "properties": { 12 | "windows": "\uf179" 13 | }, 14 | "style": "powerline", 15 | "template": " {{ if .WSL }}WSL at {{ end }}{{.Icon}}", 16 | "type": "os" 17 | }, 18 | { 19 | "background": "#003543", 20 | "foreground": "#d2ff5e", 21 | "powerline_symbol": "\ue0b0", 22 | "style": "powerline", 23 | "template": "{{ .UserName }} ", 24 | "type": "session" 25 | }, 26 | { 27 | "background": "#0087D8", 28 | "foreground": "#003544", 29 | "powerline_symbol": "\ue0b0", 30 | "properties": { 31 | "folder_separator_icon": "/", 32 | "style": "full" 33 | }, 34 | "style": "powerline", 35 | "template": " \ue5ff {{ .Path }} ", 36 | "type": "path" 37 | }, 38 | { 39 | "background": "#d2ff5e", 40 | "background_templates": [ 41 | "{{ if or (.Working.Changed) (.Staging.Changed) }}#ff9248{{ end }}", 42 | "{{ if and (gt .Ahead 0) (gt .Behind 0) }}#f26d50{{ end }}", 43 | "{{ if gt .Ahead 0 }}#89d1dc{{ end }}", 44 | "{{ if gt .Behind 0 }}#f17c37{{ end }}" 45 | ], 46 | "foreground": "#193549", 47 | "powerline_symbol": "\ue0b0", 48 | "properties": { 49 | "fetch_stash_count": true, 50 | "fetch_status": true 51 | }, 52 | "style": "powerline", 53 | "template": " {{ .HEAD }}{{ if .Staging.Changed }} \uf046 {{ .Staging.String }}{{ end }}{{ if and (.Working.Changed) (.Staging.Changed) }} |{{ end }}{{ if .Working.Changed }} \uf044 {{ .Working.String }}{{ end }}{{ if gt .StashCount 0 }} \ueb4b {{ .StashCount }}{{ end }} ", 54 | "type": "git" 55 | }, 56 | { 57 | "background": "#33DD2D", 58 | "background_templates": [ 59 | "{{ if gt .Code 0 }}#f1184c{{ end }}" 60 | ], 61 | "foreground": "#242424", 62 | "powerline_symbol": "\ue0b0", 63 | "properties": { 64 | "always_enabled": true 65 | }, 66 | "style": "powerline", 67 | "template": " \uea6c ", 68 | "type": "status" 69 | } 70 | ], 71 | "type": "prompt" 72 | }, 73 | { 74 | "alignment": "right", 75 | "segments": [ 76 | { 77 | "background": "#f36943", 78 | "background_templates": [ 79 | "{{if eq \"Charging\" .State.String}}#33DD2D{{end}}", 80 | "{{if eq \"Discharging\" .State.String}}#FFCD58{{end}}", 81 | "{{if eq \"Full\" .State.String}}#0476d0{{end}}" 82 | ], 83 | "foreground": "#242424", 84 | "invert_powerline": true, 85 | "powerline_symbol": "\ue0b2", 86 | "style": "powerline", 87 | "template": " {{ if not .Error }}{{ .Icon }}{{ .Percentage }}{{ end }}{{ .Error }}\uf295 \ueb2d ", 88 | "type": "battery" 89 | }, 90 | { 91 | "background": "#0087D8", 92 | "foreground": "#003544", 93 | "invert_powerline": true, 94 | "powerline_symbol": "\ue0b2", 95 | "properties": { 96 | "display_mode": "context", 97 | "fetch_virtual_env": true 98 | }, 99 | "style": "powerline", 100 | "template": " \ue235 {{ .Venv }} ", 101 | "type": "python" 102 | }, 103 | { 104 | "background": "#003543", 105 | "foreground": "#fff", 106 | "invert_powerline": true, 107 | "powerline_symbol": "\ue0b2", 108 | "style": "powerline", 109 | "template": "<#fff> \ue641 {{ .CurrentDate | date .Format }} ", 110 | "type": "time" 111 | } 112 | ], 113 | "type": "prompt" 114 | }, 115 | { 116 | "alignment": "left", 117 | "newline": true, 118 | "segments": [ 119 | { 120 | "foreground": "#FFD700", 121 | "style": "plain", 122 | "template": " \u26a1 ", 123 | "type": "root" 124 | }, 125 | { 126 | "foreground": "#f1184c", 127 | "style": "plain", 128 | "template": "🚀 ", 129 | "type": "text" 130 | } 131 | ], 132 | "type": "prompt" 133 | } 134 | ], 135 | "console_title_template": "{{ .Shell }} in {{ .Folder }}", 136 | "final_space": true, 137 | "transient_prompt": { 138 | "background": "transparent", 139 | "foreground": "#FFD700", 140 | "template": "{{if .Root}}\u26a1 {{end}}🚀 " 141 | }, 142 | "version": 2 143 | } 144 | -------------------------------------------------------------------------------- /07_setting-up[oh-my-posh]/readme.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HashimThePassionate/learn-git-mastery/cb2e79c89c470d5d8ab5d6a525a4a1494e11c2bb/07_setting-up[oh-my-posh]/readme.md -------------------------------------------------------------------------------- /08_quiz/readme.md: -------------------------------------------------------------------------------- 1 | ### Practical Quiz on Git and GitHub with a JavaScript Quiz Application 2 | 3 | #### Instructions: 4 | Follow each step carefully and provide the required deliverables. 5 | 6 | #### Step 1: Set Up Your Repository 7 | 8 | 1. **Create a GitHub Repository:** 9 | - Create a new repository on GitHub named `js-quiz-app`. 10 | - Initialize the repository with a README file. 11 | 12 | **Deliverable:** Submit the URL of your GitHub repository. 13 | 14 | 2. **Clone the Repository:** 15 | - Clone the newly created repository to your local machine. 16 | 17 | **Deliverable:** Submit the command used and a screenshot of the cloned repository on your local machine. 18 | 19 | #### Step 2: Create the Initial Quiz Application 20 | 21 | 3. **Create the Initial Quiz Application:** 22 | - Create an `index.html` file with a basic structure for your quiz application. 23 | - Create a `style.css` file for basic styling. 24 | - Create an `app.js` file for the quiz logic. Implement a simple quiz with one question and multiple-choice answers. 25 | 26 | **Deliverable:** Submit the files `index.html`, `style.css`, and `app.js`. 27 | 28 | 4. **Commit the Initial Version:** 29 | - Add the files to the staging area and commit the initial version of the quiz application to the `main` branch. 30 | 31 | **Deliverable:** Submit the commands used and the output of `git log`. 32 | 33 | #### Step 3: Add New Features with Branches 34 | 35 | 5. **Create a New Branch for a Feature:** 36 | - Create a new branch named `feature/add-timer`. 37 | - Switch to this branch. 38 | 39 | **Deliverable:** Submit the commands used and the output of `git branch`. 40 | 41 | 6. **Implement the Timer Feature:** 42 | - In the `feature/add-timer` branch, add a timer to the quiz in `app.js` that limits the time to answer each question. 43 | - Update `index.html` and `style.css` as needed. 44 | 45 | **Deliverable:** Submit the updated `app.js`, `index.html`, and `style.css`. 46 | 47 | 7. **Commit the Timer Feature:** 48 | - Commit the changes for the timer feature in the `feature/add-timer` branch. 49 | 50 | **Deliverable:** Submit the commands used and the output of `git log`. 51 | 52 | 8. **Create Another Branch for Another Feature:** 53 | - Create a new branch named `feature/add-score-tracking`. 54 | - Switch to this branch. 55 | 56 | **Deliverable:** Submit the commands used and the output of `git branch`. 57 | 58 | 9. **Implement the Score Tracking Feature:** 59 | - In the `feature/add-score-tracking` branch, add functionality to track and display the user's score in `app.js`. 60 | - Update `index.html` and `style.css` as needed. 61 | 62 | **Deliverable:** Submit the updated `app.js`, `index.html`, and `style.css`. 63 | 64 | 10. **Commit the Score Tracking Feature:** 65 | - Commit the changes for the score tracking feature in the `feature/add-score-tracking` branch. 66 | 67 | **Deliverable:** Submit the commands used and the output of `git log`. 68 | 69 | #### Step 4: Merge Features into Main Branch 70 | 71 | 11. **Merge the Timer Feature:** 72 | - Switch to the `main` branch. 73 | - Merge the `feature/add-timer` branch into `main`. 74 | 75 | **Deliverable:** Submit the commands used and the output of `git log`. 76 | 77 | 12. **Resolve Any Merge Conflicts (if any):** 78 | - If there are any merge conflicts, resolve them and complete the merge. 79 | 80 | **Deliverable:** Submit the resolved files and the commands used. 81 | 82 | 13. **Merge the Score Tracking Feature:** 83 | - Switch to the `main` branch. 84 | - Merge the `feature/add-score-tracking` branch into `main`. 85 | 86 | **Deliverable:** Submit the commands used and the output of `git log`. 87 | 88 | 14. **Resolve Any Merge Conflicts (if any):** 89 | - If there are any merge conflicts, resolve them and complete the merge. 90 | 91 | **Deliverable:** Submit the resolved files and the commands used. 92 | 93 | #### Step 5: Push Changes to GitHub 94 | 95 | 15. **Push All Changes to GitHub:** 96 | - Push the `main` branch with all merged features to GitHub. 97 | 98 | **Deliverable:** Submit the command used and a screenshot of the updated repository on GitHub. 99 | 100 | ### Submission: 101 | Submit all required deliverables (files, commands, outputs, screenshots, and URLs) as a single document or archive. Ensure each step is clearly labeled with the corresponding deliverable. 102 | 103 | This practical quiz will give users hands-on experience with Git branching, merging, and GitHub collaboration while building a functional JavaScript quiz application. -------------------------------------------------------------------------------- /LISENCE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2024 Muhammad Hashim 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # 📚 Git Version Control 2 | 3 | Welcome to the **Git Version Control Tutorial**! 🚀 In this guide, we'll delve into the powerful features of Git, a widely-used version control system that empowers developers to manage and track changes in their codebase effectively. Whether you're new to version control or aiming to strengthen your understanding, this tutorial will walk you through the essential concepts and best practices of using Git. 4 | 5 | ## 📑 Table of Contents 6 | 7 | 1. [**Introduction**](#-introduction) ✨ 8 | 2. [**What We Will Learn**](#-what-we-will-learn) 📖 9 | - [1. Fundamental Concepts](#-1-fundamental-concepts) 🧩 10 | - [2. Creating Snapshots](#-2-creating-snapshots) 📸 11 | - [3. Browsing a Project History](#-3-browsing-a-project-history) 🔍 12 | - [4. Branching and Merging](#-4-branching-and-merging) 🌿🔀 13 | - [5. Collaborating Using GitHub](#-5-collaborating-using-github) 🤝 14 | 3. [**Getting Started**](#-getting-started) 🏁 15 | 16 | 17 | ## ✨ Introduction 18 | 19 | Welcome to the Git Version Control Tutorial! In this guide, we'll explore the robust features of Git, a cornerstone tool in modern software development. Git allows developers to efficiently manage and track changes in their projects, fostering collaboration and ensuring code integrity. Whether you're just starting or looking to deepen your Git knowledge, this tutorial has got you covered. 📘 20 | 21 | ## 📖 What We Will Learn 22 | 23 | ### 🧩 1. Fundamental Concepts 24 | 25 | - **Introduction to Version Control** 📂: Grasp the basics of version control and its significance in software development. 26 | - **Git Basics** 🛠️: Understand core Git concepts, including repositories, commits, and the staging area. 27 | - **Installing Git** 📥: Follow step-by-step instructions to install Git on your system. 28 | - **Configuration** ⚙️: Set up your Git environment with your personal information for seamless tracking. 29 | 30 | ### 📸 2. Creating Snapshots 31 | 32 | - **Creating a Repository** 🗂️: Initialize a new Git repository to start tracking your project. 33 | - **Tracking Changes** 📝: Learn how to add files to the staging area and commit changes effectively. 34 | - **Commit History** 📜: Discover how to view and interpret your commit history to monitor progress. 35 | 36 | ### 🔍 3. Browsing a Project History 37 | 38 | - **Viewing Commits** 👀: Use Git commands to review past commits and understand your project's evolution. 39 | - **Comparing Changes** 🔄: Learn how to compare different file versions to identify changes. 40 | - **Undoing Changes** ↩️: Master techniques to revert or amend commits when necessary. 41 | 42 | ### 🌿🔀 4. Branching and Merging 43 | 44 | - **Branches** 🌱: Comprehend the concept of branches and how to create and manage them for parallel development. 45 | - **Switching Branches** 🔄: Learn how to navigate between branches to work on different features or fixes. 46 | - **Merging** 🔀: Understand how to merge changes from different branches and resolve any conflicts that arise. 47 | 48 | ### 🤝 5. Collaborating Using GitHub 49 | 50 | - **Introduction to GitHub** 🐙: Get acquainted with GitHub, a platform for hosting and collaborating on Git repositories. 51 | - **Remote Repositories** 🌐: Learn how to push your local repository to a remote server for backup and collaboration. 52 | - **Collaboration** 🤝: Discover how to clone repositories, submit pull requests, and manage contributions from multiple collaborators. 53 | - **Issues and Project Boards** 📋: Utilize GitHub features to track issues and manage project workflows efficiently. 54 | 55 | ## 🏁 Getting Started 56 | 57 | Before diving into the tutorial, ensure that Git is installed on your machine. You can download Git from [here](https://git-scm.com/downloads). Follow the installation instructions specific to your operating system. 🖥️💾 58 | 59 | Once Git is installed, you're all set to embark on your Git journey! Each section of this tutorial builds upon the previous one, so it's recommended to follow along in order for the best learning experience. 📈 60 | 61 | **Regards,** 62 | **Muhammad Hashim** 👨‍💻 63 | --------------------------------------------------------------------------------