Mastering Git: Version Control Guide for Beginners and Beyond

1. Intro: Are you ready to level up your development skills? Whether you are completely new to it or want to take your knowledge to the next level, this course is perfect for you. Learn the essential from scratch and dive into more advanced features as your progress. Git is the industry standard version control system used by developers worldwide. Mastering Git will help you collaborate more efficiently, track changes, and manage your project with ease. In this course, I'll guide you step by step through the basics. We understand what it is, how to use it, and why it's essential tool for developers. Core commands, learn how to commit, create branches, merge, and revert changes. Collaboration, learn how to work seamlessly with teams using GitHub. We also discover rebasing and how to resolve conflicts. It's highly recommended that you follow along by typing out the commands yourself as you work the course. This hands on approach will help solidify your understanding and make learning it more effective. Practice is the key to mastering the tool. Start mastering it today and then lock endless possibilities in your development journey. 2. Git Installation & Setup: Understanding Global and Local Settings: Hello, guys. Today we'll cover the following topics. What is GID? What is it used for, and how to work with it? So what is GID? Git is version control system used to manage and track changes in software code and other files. It allows developers to collaborate on projects and keep track of different versions of the code. In other words, Git stores all changes made to your code in a special database called the repository. With GIT, we can view the project's history to see who made changes, when they were made and what those changes were. Without GID, team members would make changes to their local copies of files and manually keep track of different versions by renaming files or creating backups. Teams would often pass files back and forth via email or shared network drive. If two team members worked on the same file simultaneously, they would have to coordinate with each other to avoid conflicts. If a mistake was made or a file was lost, there wouldn't be a way to revert to a previous version of the code. The console or command line interface is one of the most primary tools for working with GID. However, it requires users to type commands using specific syntax and terminology, which can be intimidating for beginners. Thankfully, Git is integrated into Visual Studio code as a tool for version control. This integration provides a graphical user interface for Git, making it easier for developers to use Git without needing to memorize command line syntax. Visual Studio code also offers a variety of extensions that enhance Git functionality. You can find many Git extensions on the Visual Studio Code marketplace offering conditional features. For those who prefer visual interface for Git, there are also standalone graphic user interface tools available for different operating systems. Some of these tools are free while others are paid. Let's start by setting up Git. First, go to the GIT website and install Git for your operating system. I won't install it because I already have Git installed. It's not difficult. Just follow the instructions. For Linux, you can use sudo Opt Install Git. For Mac, simply download and double click to Install. Before we start working with Git, let's talk about some settings. The global config refers to settings that apply to all Git repositories on your machine. The two most commonly configured global options are your name and your email address. These are used to identify who made each commit in the repository. By setting your name and email globally on your machine, Git will record them with each commit. This allows other users to see who made changes to the repository. This command allows us to see the already installed global settings and git. Here you can see our global name and email. If you need a different name or email for specific projects, you can use local configurations. Local configurations apply only to a specific repository, while global settings apply to all repositories. You can set global configuration settings using the Command Git config with the flag global while local settings are set using Git config without the global option inside a specific repository, go to your project directory and set the name and email just for this repository. You can use the Git config list command to see all the settings, both global and local. Here you can see our global user and the local settings we just configured. This command shows only the changes in the local config. Here we can see the user name and email specifically set for this project using this command, but with the option, global, we can see only global config. Again, just for reminder, general config with both local and global settings. To unset a configuration, use the Git config and set command. For example, to remove the local username, we use this command. I type Git config, dash dash set user name. This will remove the local user name from the config, but the global settings will still be in place and used for commits. Here we can clearly see that we removed user name and email. We can also unset the global emails using the same command, but with the global prefix. This will remove the global email from the configuration. Each operating system, Windows, Mac or Linux, can use a different format for line endings. These differences can cause issues when sharing files in a Git repository, especially when working across different operating systems. To prevent this issue, you can configure Git to handle line ending automatically. This ensures that files stay consistent, error free, and behave as expected, even when check out on different operating system. When working in a mixed environment team, these discrepancies can cause unnecessary Div Smtch conflicts or issues in code execution. By configuring Git to handle line endings automatically, you ensure that files are consistent across all platforms, preventing bugs and errors related to line endings. For example, on Windows, you can set Git to automatically convert line endings to Windows format by setting core dot Atoserf to true. On Unix based systems like Linux or Mac, you can set it to input, since this setting can affect all your projects. It's best to configure it globally to ensure uniformity across all repositories you work on. Modern editors like Vascde, Intelligda and sublime text handle line de differences automatically. They detect the format CLF or LF and adjust as needed. So in many cases, you won't notice any issues unless working in cross platform teams. But settings core out a Serra 11 Git is still a good practice to prevent potential problems. In the next lesson, we'll start the project from scratch and learn the basic Git commands. See you. 3. Git Workflow Explained: Working Area, Staging, Repository & Configuring .gitignore: Welcome back, guys. Let's start our first project, create a directory and navigate to it using the command line. Run the command ls minus A to see all files and directories, including hidden ones, and we see that this folder is completely empty. To initialize a Git repository in this directory, use the Git init command. This creates a hidden dot Git folder, which contains all the necessary files and directories for the repository. At this point, the repository is empty and doesn't contain any commits yet. The git folder is the backbone of your repository. It includes the Git database, which tracks all changes. The index, which is used for staging files, local configuration files. Here we can see the settings. You may also notice a folder called hooks. These are scripts that Git can run automatically at specific points in your workflow. Very important note, never delete the git folder manually, as it's critical for the repository to function. Alright, let's create a file called textixty. Sorry, my imagination is a bit lagging today. If we repeat the LS minus a command, we might notice another file such DC store on MacOS. I use MacOS system. So I have this. What are DC store files if you're using MacOS. So you may have encountered on these files. These files are automatically generated by the MacOS operating system. They are hidden by default and store metadata about a folder, such as the size and position of icons, view options for the folder, and so on. While these files help MacOS remember how you like to view your folders. They can cause issues when using version control systems like Git. The Git status command displays the current status of your repository. It provides information about changes made to files such as files that are modified but not yet staged or staged and ready for a comite. In the output of Git status, you'll see files that are prepared for Comit. Among them, you might notice unwanted files like DCIS store on MacOS, which can clutter your repository. To prevent DC store or other unnecessary files from being tracked by Git, you can create a global GIT Ignore file. This file will apply to all Git repositories on your system. Here's how to set it up. Go to your root directory and create a hidden file for the Global. At DStore or any other files you want to ignore to this file. Here you can see two lines. The first one, Distore ignores only the exact match of the DStorFle. The second one, Distor ignores any file starting with DStore and followed by exactly one additional character. It potentially can be Distor one or Distor two. This provides extra protection against similar but slightly altered file names. And finally, configure Git to use this global Ignore file. From now on, desisorFles will be ignored in all your Git repositories. You can verify this by running Git status command. The desisorFle will no longer appear in the list of tracked files. Let's add and stage files in Git. Let's create another file, write some content in it, like hello and check the status using Git status. Git will show you the files that have been modified or created but are not yet staged for a Comi. To stage files, use the Git add command. These are several ways to use this command. The first one stage specific files. Here I list all files I want to add. The second one stage all files with a specific extension. And here I use the Asterix dot and extension. I want to add all files with this extension. And the third one stage all changes at once, and here I use dot. In this example, let's stage all Tixti files. Now Git status will show the files as staged and ready for Commit. Let's make our first commit. To save the changes, we need to create a commit. Use the Git Commit command with the minus M option to include a message describing the changes. In my case, it will be initial commit with text file. GID will create a new commit with a unique hash cod containing a snapshot of the staged files or changes if they were. After this, run in GID status and show that the working directory is clean, meaning all changes have been saved. I'll explain schematically what we just did. In Git, there are three main areas where files are stored and managed the working directory, the staging area, index, and the repository. The working directory, this is the directory on your local machine where you make changes to your project files. Any modifications made here are not automatically tracked by Git. The staging area or index. This is where you add the changes from your working directory that you plan to include in your next commit. Think of it as a buffer or preparation area where you can review and fine tune the changes before committing them and the repository. This is where Git stores the complete history of all changes made to your project, including all committed versions of your files. It acts as a database containing snapshots of your project at various points in time. So in summary, the working directory is where you make changes. The staging area is where you prepare those changes for a comite, and the repository is where GID saves the history of all changes. Understanding these three areas is crucial for managing your project effectively with GID. In the next lesson, we will move on to some practical use cases. Sea. 4. Renaming and Deleting Files in Git: Using Git Commands & Shell Commands: Welcome back, guys. In the last lesson, we finished by creating and committing initialized project. Let's create another one changes and write something into TXT file. The command echo text appends the text to the file TikT. Running Git status will reveal our changes. Here we can see message that no change is added to commit. So let's add these changes. Instead of using two separate commands, Git add, and then GIT Commit, we can perform both action in a single command. Minus A flag stages all modified files, excluding U files, and the minus M flag adds a Commit message. Let's ain that here we resolved errors. After running this command, Git will process and save all changes in one step. Now, Git status confirms that there is nothing to commit because all changes are saved. We've made our second commit with just one command. We can see all two commits with the command Git log. So let's consider deleting files and Git. The LS command shows what we have in this folder. The RM command is a standard command used to remove files and directories from the file system. When you use RAM to delete a file, it's permanently removed from your system, but Git isn't aware of this deletion. For example, let's delete file text with Command RM. After running this, GIT data will show that the file has been deleted, but the changes must still be staged and committed. So stage the deletion. Staged files and Git are marked in green. So when you see green files and git, they are ready to be committed and then commit the changes. Now let's delete a second file. But this time, we will use the Git specific Git RM command. Unlike RM GITRM removes the file from both the working directory and the repository in one step while also tracking the deletion in the commit history. You'll notice we skipped the Git add step, but the changes are highlighted in green. That means they are good to go for the next commit. That's why I use here only minus M flag. Well, in summary, use RM to remove files only from the file system and then manually update Git. Use GID RM to delete files and record the deletion in Git in a single step. So for now, our folder is empty. We just deleted two files that we had. With the command touch, I create new file app dot py. Then add it to the stage. Commit. When you make a commit, you may see the message, your name and email were configured automatically. In the previous lesson, we discussed configuring Git with your name and email using global or local settings. Since we configured global and local settings in the previous lesson and then unset the email and name, Git is now using automatically generated email and name values. To avoid this message and ensure proper tracking of contributions, I can configure user name and email with these commands. But right now for this example, I don't need it, so I leave it as it is. Check folder and we can see our file. The MV command is a general purpose command for renaming or moving files in the file system. While it works for file management, it does notify Git about the changes. If I perform this command, Git will treat this as a deletion of app Pi and addition of it by requiring manual staging and committing. So I edit and commit. I create another one file app dot pie, add it to the stage, and commit it. I want to show you the second way to rename it. So for now, we have two files renamed II Dotpy and nearly created ab dot py. Let's rename app dot pi to coordtpy. Alternatively, you can use the GID specific GD&V command, which simplifies this process. It automatically renames the file in the working directory and updates Git records preparing the changes for staging in one step. I perform Command LS, and we can see our renamed file coedtpy and the first one renamed Iiddtpi. So we have advantages of GID and V command. It keeps the history of the renamed file intact in the Git repository. Also, it simplifies the process by combining the rename and staging steps. After running Git and V, the file is ready for a commit and Git status will show the staged rename operation. By understanding these commands, you can handle file additions, deletions and renames more efficiently while maintaining proper version control. See in the next lesson. 5. Mastering .gitignore: Configuration, Types of Settings & Managing User Info in Git Config: Welcome back, guys. Let's discuss files that shouldn't be committed. When working on a project, you'll often encounter files and directories that don't need to be included in your commits. The GID Ignore file helps manage this. The GID Ignore file is a configuration file used by Git to define and track files and directories that should be ignored and excluded from version control. In a previous lesson, we configured a global Gig Nur file for system files that we don't want to include in any of our projects. And this lesson we'll create a GiignerFle specifically for a single project. First, I create a hidden file called dot GitegnR in the root directory of our project. The GiignorFle can be placed either the repository through directory or in specific sub directories, and it will affect all files and directories within its defined scope. You can find plenty of Giegnor examples on Github. These examples vary by project and programming language as each has specific files or directories that shouldn't be included in the project's shared repository. For example, many programming languages generate temporary files, logs, or build artifacts that are unnecessary for version control. GitHub even provides language specific Gitegnor templates for various frameworks. So let's consider common syntax and GitegnorFils. By effectively using GiegnoFle, you can customize which files and directories Git should ignore. You can see a few examples of common patterns. This pattern means that the entire contents of TMP directory, including all sub directories and files will be ignored. Or we can ignore files by extension. This pattern will ignore all files with the log extension. By using an exclamation mark, you can specify exception for the rule. In this case, all log files will be ignored except debug log. The asterisk acts as a wildcard matching zero or more characters. For example, asterisk dot TikT will ignore all TixtFles WildeR asterisk will match all files within a directory, but not its subdirectories. Enough theory, let's practice. To demonstrate, I clean the project directory and then add a temporary directory named TMP and TikTFle inside. And also, I write hello to the TikTFle inside Temp folder. Initially, the TEM directory and its content appears in the GIT status output. If we decide that this directory should not be included in any comits, we can write the following rule into Git Ignore file. The ECO command creates or overwrites GitegnorFle in the current directory. In our case, I write TAMs two Git Ignore, and this means GID will no longer track or include the TAM directory in commits, even if changes are made inside it. The command CAT dot Git Ignore displays the contents of the Git Ignore file in the terminal. After saving this pattern and re running Git status, the TAM directory is no longer visible. This ensures that we won't accidentally commit unnecessary files from the TAM directory. Now we will add and commit our changes. However, when I do it, we encounter worrying message because the email and username for this project haven't been configured. As I said before, GID automatically generates default email and user name values, but it's better to set them up manually. For now, let's configure them locally for this project. First, I assign a user name. Next, I set up an email. To demonstrate, I create a new test file dt, and commit the changes. Running Git log command confirms that the new user name and email appear in the commute history, and previous warning messages are gone. See you in the next lesson. 6. GitHub Essentials: Cloning Repositories, Pushing & Pulling Changes, and SSH Connection Setup: Welcome, B, guys. Git isn't just version control system. It's a distributed version control system, which means you don't need a central server to work. Each developer has their own local copy of Git that stores the project's entire development history. When developers make changes, they first record them locally on their computers. Then if they choose, they can share their changes with colleagues or receive updates from others. However, in real world projects, a central server is usually created for convenience. This server acts as a hub for collaboration where all developers can send their changes and pull updates from others. Any remote computer with proper access can serve as a Git server. Platforms like GitHub, Gitlab, and Bitbucket are popular web based solutions for hosting Git repositories. These platforms provide infrastructure for store code, managing access, and facilitating collaboration on project using Git. Also, each platform has its unique features, attracting developers and teams of varying skills and needs. Today, we'll focus on Github and learn how to create delete and clone repositories, as well as set up as a sage for secure communication. So start by going to the GitHub website and registering for an account. Enter your email address, which will be used for account registration. Click the Continue button and confirm your email. Since I already have an account, I'll simply login and proceed to create a new repository. To create a new repository, follow these steps. Specify the repository name. It must be unique. Set visibility, choose between public or private, public, it's visible to everyone, making it possible to others to clone your repository. Public repository are ideal for showcasing portfolios or sharing open source projects. Private restricted to you and your collaborators, suitable for commercial or private work. We also have the read me file, which typically contains instructions about the project and its purpose. Generate dot GTI Nor file, which helps exclude the necessary files from being tracked. Yeah, Github can Auto generate a GitegnorFle tailored to the programming language you are using. Now, we have successfully created a Github repository with some initial files. Our next task is to clone it to our local computer. To clone repository through your local computer, first, open your repository on Github. Click the code button and select a link to clone the project. You'll have three options HTTPS, SSH or Github CLI. We'll focus on cloning using SSH because it's secure and eliminates the need to repeatedly enter your credentials. To clone via SSH, you need to generate an SSH key and add it to Github. On your local computer, generate an SSH key using the terminal. I generate SSH keys by using the command SSH Kagan. It's used for all systems Macs you want to Windows. The process is the same across platforms with options for different key types. During the process, you'll be asked where to save the key. You can either specify a custom location or accept the default directory. Since I already have a key generated, I'll skip this step. After generating the key, navigate to the directory where it was saved. You'll find two files, the private key, keep this secure and the public key. This is what we'll add to Github. Copy the contents of the public key file. Go to the Github, to the settings SSH and click New SSH key. Assign a descriptive name, pass the public key and confirm by entering your Github password. Now SSH axis is configured. Let's clone the repository. Copy the SSH link from your Github repository, open the terminal and navigate to the directory where you want to clone the project and run the following command. Once completed, you will see the project files on your local computer exactly as they are in the Github repository. That's it. You've successfully created a repository on Github. See you in the next lesson. 7. Pushing Local Changes to GitHub, Deleting Repositories, and CLI Connection Setup: Welcome back, guys. Let's quickly go over how to delete a Github repository from remote server. To delete a project on Github, go to the settings of the repository, scroll down to find the option to delete repository, and finally confirm that you really want to remove it. Deleting the repository on Github doesn't affect your local copy. Since you clone the repository, you can continue working with it locally. Now let's quickly create new project, name it test project. And use the Github CLI instead of SSH link. First, you will need to install Github CLI. Please refer to the Github CLI documentation for installation instructions. Github CLI is a common line tool that interacts with Github from the terminal, while graphical interfaces are often used for convenience. Knowing how to use the Github CLI is equally important. For example, servers typically don't have graphical interfaces, and you may need to work through the console. Here you can see, as I repeat all necessary steps from the documentation. When setting up Github CLI, you'll be asked a few questions during the configuration process. One of the question is whether you want to connect to an Enterprise Github server or use the default Github. Since most users work with Github, you can choose not to use Enterprise Git unless you are working in organization that hosts its own instance of GitHub Enterprise. Next, you will be asked to select the method of authentication. Should choose SSH for the connection. SSH is a secure and convenient way to communicate with Github server, allowing you to push, pull, and interact with your repositories without entering your credential each time. After selecting SSH, the CLI will ask you to use an existing published SSH key or generate a new one and give it a name to identify the device. Once you've named the key Github CLI will automatically upload your public SSH key to your GitHub account. You may be asked to authenticate using your Github credentials, such as re entering a one time verification code to confirm the action. After this step, your Github CLI setup is complete and you can secure clone, push, pull, and interact with Github repositories using SSH. When you clone a project using this command, the connection to GitHub is automatically established. The command uses the Git protocol to fetch the entire repository to your computer. So once the command is successfully executed, you will have a complete clone of the repository and can start working locally. Here I navigated to the directory of the clone project. To check the connection to the remote repository, use the following command Git remote minus V. This command will show you the connection to the remote repository. By default, it's named origin, but you can assign a custom name when cloning a project. Now let's learn how to push changes to the remote Git repository. Let's make some local changes and push them to remote Git repository. I'll modify the read me file and add some changes. Add these changes to the staging area and commit them. So here I can see our commit. To push these changes to the remote repository, execute git push origin main. Here, orgion is the connection name, and main is the branch to which we push our changes. After successfully pushing the changes, you can visit GitHub to see the updates. You will be able to view the commit details and see the exact changes. With added lines marked in green and removed lines in red. Let's do the reverse pull changes from the remote repository into your local project. I modify ReadMe file on GitHub, which will create a new Camt Now on your local project, you'll see two kamits while on GitHub, you'll see three amits To fetch the changes from GitHub, execute the command git pull or region Min. This post the latest updates from the remote main branch into your local repository. After the pull, the Read M file on your local computer will reflect the changes made remotely. Let's consider another scenario. You have a project locally on your computer, and now you want to upload it into GitHub to share with others. Start by creating a folder and initializing it with Git as we did in earlier lessons. I create Test TiktiFle and write hello into it. And then, of course, add to this stage and commit it. After making some changes and committing them locally, you're ready to upload the project to Github. To upload it to Github, create a new repository on Github. This time, don't add read me file or Git Ignore. Github will provide specific instructions to upload your project. Go to your terminal and execute these commands one by one. The first command establishes a connection to the remote repository. The second command ensures your local repository uses the main branch. If your project uses master, this step renames it to main. The third command pushes the changes to the Github. The minus U option links your local main branch to the remote main branch, making it easier to push changes in the future without specifying extra parameters. After pushing, refresh your GitHub page to see the project, your files and commits should now appear in the repository. So we've covered how to delete the repository, create a new one, clone it using GitHub CLI, push changes, pull updates, and applaud the local project to GitHub. You've done a great job. See you in the next lesson. 8. Installing Git Graph Extension in VS Code & Basic Git Branch Commands: Welcome back, guys. Today, we'll dive deeper into working with branches and commits. We start from the beginning. Totally New project. I create empty directory. Running Git status won't show anything yet because we haven't initialized the project. First, I'll make a simple change by writing hello to the Read Me TiktiFle. This file will be created automatically with the command. Just remember echo this command, write hello to the Read Me TixtiFle. Next, the Git init command initializes the project, creating a hidden git folder. Now Git will start tracking our changes. To confirm it, run s minus A to display both hidden and regular files. You'll see the Git folder and the readmitixty file. Running Git status now shows our changes that need to be added and committed. Let's handle this. In Visual Studio code, there is an extension called GID graph, which provides a convenient graphical interface for viewing commit history. To install it, open the extensions panel, in VS code, search for GID graph and install it. It visually maps branches, changes, mergers, and more. Once installed, you'll notice a GID graph icon at the bottom panel. Clicking displays the current state of the project. Here we see we are on the main branch, the default branch. The initial commit labeled in it project, clicking the Commit allows us to view all the files changed in that Commit. For instance, clicking Rhythm txt shows exactly what was added. Now I'm going to create branches using multiple methods. First method, run the command Git branch, feature one, to create a new branch named feature one. Then using the command GethekoFeature one, we switch to it. Check the graph to see that we are now in the fit one branch. In this branch, I write the line project in the TiktiFle. Here it is. Then add these changes and commit them. Let's make another one. I write the third line into TiktiFle and this line will be commit to. A after making another commit, we'll see both commits on the feature one branch in the Git graph. Now I'm going to create another one branch, but for this, I'm going to use another command. With the command Git checkout main, I switch to the main branch. So right now we are in the main branch. Just to remember, here we don't have these previous two commits. I use the command Got minus B and then name of my second branch feature two. This creates and switches to a new branch simultaneously. In the feature to branch, I will create a new Python file app dot py and add a simple print Hello World function. You can create any file and write something into it. It's up to you. Git status shows the file that we need d and commit. After staging and committing this, we will see the first Gamit for feature two in the GID graph. So for now, we have three branches main feature one and feature two. Main has just one commit innit project. Since we branched off from main, the new branch feature one starts from the same initial commit of main init project and includes two additional commits that we just made in feature one. Commit one and Commit two. The same with the branch feature two. This branch has the initial commit int project and the commit that we just made. Commit one, feature two. 9. Merging Branches in Git: Step-by-Step Guide: Let's figure out how to merge branches. Branch merging Git is the process of combining changes from one branch into another, typically merging a feature branch into main branch. This integrates the updates and ensures all changes are consolidated into a single branch. By pressing the up arrow, you can repeat the previous commands you executed in the console. I will go back to the command where I wrote hello world to the file app dot pi. I will change text to commit two. And run the command again, writing a different line into the file. If I open the app dot py file, we can see the second line, we just dit. Also, if I press uncommitted changes in Gig graph, we can see this file, and again, our second line with plus that we just edit. Then I add these changes and commit them. I'm doing this so that we can see more commits in each branch. This will make it clearer when we merge these branches, as we'll be able to see all commits that were made. So right now, I made the changes in branch feature two. Then I switched to main branch. Immediately, we notice that our AbdtPifle is missing. This is because the AbdtPifle was created in the feature two branch, and now we are in the main branch. We haven't merged the changes yet. If we open our rhythm txt, we'll also see only the initial hello. We wrote at the very beginning. To view all branches, the Git branch command shows us all the branches we currently have locally. This includes our main branch indicated by the asterisk and the two branches we created. If you're working and can't remember which branches have already been merged, there's a useful command Git branch, dash dash, merged. This shows the branches that have already been merged into the current branch. In our case, nothing has been merged yet, so we only see our main branch. There is also command to show unmerged branches, Git branch, dash dash, no merged. The lists branches that have changes that haven't been merged into our main branch yet. Now, being in the branch where we plan to merge changes, we execute the git merge command and specify the branch from which we'll merge the changes. Let's start with the first branch feature one. After merging, we see two additional lines in our read me Tixty file. Next, we move to the feature two branch and begin merging all the changes from the second branch into the main branch. Again, being in the main branch, we execute the kit merge command and specify, of course, the feature two branch. Here you can see the message. Don't worry, a new commit is created during the merge. You can either change the commit message or leave it as it is. Since we are learning to work with getting the terminal, a text editor has opened. Yours might be nana or VIM depending on what is installed. In my case, it is VIM editor, so this command stands for write and quit. At this point, we've successfully merged both branches into our main branch. Now, all the changes we made are in the main branch. In the Git graph, we can choose which specific branch we want to you. If there are many branches, it might be hard to track all the commits for each one. So here we can choose one or another and clearly see all commits in this branch. The Git log command shows all the commits we currently have in our branch. If you want to view the Commit history in graph format, you can use Git log graph. This will display something similar to what we saw in the graphical interface where we can clearly see our commits and the merge commits from feature one and feature two. The Git log D graph command is another way to visualize everything we've done. Suppose you're working on a server without graphical interface. In that case, you can see the same information directly from the terminal by executing the Git log command. Being able to work with the terminal is very useful. Let's imagine that feature one and feature two are two features. We are developing for our app. If we want to see how the state of feature one differs from feature two, we can switch to the feature one branch and use the Git DIV command to compare the differences. We specify the branch we want to compare against, in this case, feature two. So here we are comparing and looking for differences between two branches, feature one and feature two. We'll see that the AbdtPifles is missing in feature one, and we also have two additional lines in the Rath met xt. In this example, the Gi Div command shows us the differences between the two branches, highlighting what's present in feature two, but missing in feature one. If we want to compare the current commit in our branch with a specific commit, we can use the Git Div command again. But this time, we need to specify the commit we want to compare it with. To do this, we first need to find the hash of the Camt we want to compare against. We can see the Commit hashes by running Git log or just seeing Git graph. Each commit has unique has, but we don't have to type the full hash. It allows us to use the first few characters. Typically first seven, which is usually enough to identify Cami once we have the hash, we can run this command. And this will show us the differences between our current working state and the specified commit. For example, here in the terminal, we can see that in the current state, we have additional of line, Commit two. We can go to the Giggraph and view the same. I press feature one, Commit two. This is current Commit we have right now. And here we can see this line. In the next lesson, we'll continue working with branches and commits. S. 10. Resolving Merge Conflicts in Git: A Complete Guide: Welcome back, guys. Let's continue working with branches. I'm currently in the branch feature one, which I created from the main branch. Here I'll make some changes. Using this command, I will add a line to Read MitixtiFle. Let's imagine that we've been making multiple commits, and for some reason, we now need to check the uncommitted changes in your working directory compared to the last Gamit. In the previous lesson, we learned how the GI Div command works with branches to show differences. We also look at specific commits using their hashes. Today, I'll show you how Git Div works with changes in real time. I want to see what I have modified and what hasn't been added to the staging area yet. To do this, I'll use the GI Div command. This command displays the uncommitted changes in the working directory compared to the last commit in this branch. These changes haven't been added to the staging area. If I open the text file, read me Tixty, we will see the line that I just added with the command in the terminal. After viewing the added line, I'll execute the command, get diff, dash, dash, staged. But this time, we won't see any output because this command shows the differences between changes that have already been staged and the last committed version. So to see the difference between stage area and the last committed version, I need to add all our changes to the stage area. I will add these changes to the staging area, but without committing yet. Well, let's imagine we take a coffee break and upon returning, we forget what we had added and staged. To check what is staged, but not yet committed, we can use Div da da staged. This command shows the difference between the last commit and the changes that are staged, but not yet committed. We can now review these changes before making the commit. Once we commit the changes, running Div staged again won't show anything since there are no more differences between the stage changes and the last Gamit. Similarly, running Git div will also return no output. And there are no uncommitted changes left in the working directory. Next, let's switch to the main branch and merge the changes from feature one. Remember, when merging branches, you need to be on the branch where you want to merge the changes into. Since we want to merge feature one into mean we execute Git merge, feature one. This creates a merge commit where we can either modify the commit message or leave it as it is. Previously, we also created another branch called feature two. Now, I'll switch to that branch. In feature two, we have three commits the initial commit, which was inherited from mine branch when we created the featured two branch. And two additional commits that were made specifically for this branch. Additionally, we have a new file app at Pi, and in Red Mitixt we see only the text hello. So the state of the feature two branch is completely different from feature one or main branches. I will now add another line to the Redmtixt file and commit it. After this, I will switch back to main branch and attempt to merge these changes. Being in main branch, I execute the command git merge feature two. And we see that we encounter our first Git conflict resolution. Specifically, we added a line in the feature to branch, but there is already something written in the main branch since both lines exist in the same place, they conflict with each other. So to complete our merge, we need to resolve these conflicts. We go to the files, which conflicts, identify them, and fix them. We choose what we want to keep. When I open the file, we can see visual presentation with markers identifying the current state. Below, we can see changes from the feature to branch that we are about to merge. It turns out that two lines from two different branches exist in the same location, but contain different content. In almost any editor, you can choose to accept all incoming changes. Keep what you currently have in the branch and reject the incoming changes or keep everything merging both versions. In this case, you can automatically resolve these conflicts, leaving all the information from both branches. You can also compare these changes and see exactly what needs to be resolved. In the right, we have our feature to branch from which we are merging changes, and in the left, we have our current branch. When you click Resolve in the March Editor, it opens in GIN graph. This allows you to manually resolve the conflict during branch merging. In the march editor, you can review the differences between conflicting versions of the file and choose which changes to keep. After resolving conflicts and saving the changes, you complete the branch merging process. Since not everyone works with GID graph, I will resolve the conflicts directly in the file itself. I plan to keep the line from the feature two branch and also keep everything from the main branch. So we go to the files with conflicts, identify them, and fix them. We choose what to keep. And if both conflicting changes are needed, we leave everything but make slight modifications. Now running Git status will show us the new changes. We made these changes manually in the Rhythmtixti file, keeping everything from the main branch and adding changes from the feature two branch. We add the changes and make a Camite. In Giddigraph, it's very convenient to see the difference. Now, in the feature two branch, we look at the Rhymitixty file and we can see our hello message along with our Comite. Meanwhile, if we switch to the main branch and check the Rhythm TixtiFle, it will show everything we just did, the previous changes and the last line that we added from the feature to branch. In the next lesson, I will introduce you with very useful command. See you. 11. Advanced Techniques Git Reflog and Reset: Hard vs Soft: Welcome back, guys. Now I want to introduce you to a very useful command, but I need to do some preparation first. So let's return to our features branch and switch to it. Here in the ab dot B file, let's imagine I want to delete a function, and I do that. After removing the second print statement, I will add these changes and commit them. Then I'll switch back to the main branch and merge these changes. The Git log command will show our latest commit where we merged feature two into the main branch. And now time for another command, I want to introduce to you. Every time you perform operations like moving, creating or deleting commits or branches, Git stores the sections in the Rf log. And this allows you to restore the repository to previous points and also recover deleted commits that were overwritten and do incorrect mergers. Well, it's truly very useful command. The flog keeps track of the latest position of I reference for a certain period, but I want to notice that vlog is stored locally and is not shared with remote repositories. Now, imagine that I regret merging this branch, and I urgently need to undo it ideally without leaving trace in commit history. Currently, I'm at the merged commit of the feature two, but I need to roll back one commit. To check what changed, I will execute get DF and then commit hash. This shows the difference between the current state and the specified commit. As you can see, the current commit differs from the one I specified specifically because the second print statement is missing. This means the previous commit contains the state we need because I want to restore this line and no one should see that it was deleted. Giro dash dahart completely resets your working directory and commit history to the specified point. When you run, GitrSt dash dashart, get moves your branch to the specified commit, delete all on committed changes, and erases commits that came after the specified commit. But be careful. This operation is irreversible. You cannot recover the lady changes unless they are appearing there a flog. After running the command, our second print statement is back. We did it deletion. Our merge committee is gone. And if we execute Gift Log, we can see that the main branch has returned to the fixed conflict commit just as it was before the merge. As I mentioned earlier, the Git raf log command shows everything we've done. When I run Git flock, we see that the reset abration moving the branch back to commit 44 F 18, the beginning of the commit we roll back to the merge commit we just raised, meaning this action is not without consequences, even though git reset dash dash hard deletes all changes. They still exist in the relock for a limited time. Since we have learned how to roll back to previous commits without saving this action in the commit history, using the Gitvlog command. Let's also learn how to undo this rollback without creating chaos in the commit history. In other words, we roll back to a previous commit, removing everything that came after it from the history. Now we want to undo this rollback. So we should go back to the vlog, copy the hash of the merge commit, and execute the command git reset, dash dash hard, and hash. And now, look at this. Our commit graph is exactly as it was before. All Commit names and their hashes remain unchanged. Right now we used the command with the hard option. Now let's talk about another command. Git reset dash dash soft. Unlike GitRSet dash dash hard, the soft option undoes the last Camuts but keeps it all changes in your working directory and staging area. Right now, our branch is in the same state as it was before we learned about the GDR set dash dash hard command. Let's repeat all the actions we did with the hard option. But this time, using the soft option. So let's redo R and D of the feature to merge. But this time we use GITR set, DDR soft, and again, has our Camt. This moves our branch back to the previous Camt before the merge. And now take a look the GitRset das Dar soft command undid the merge of feature to branch. The removal of the second print statement was also undone, but unlike Hart, the changes are still there. Currently, these stage changes can be committed, modified or discarded. This command is useful when you committed something by mistake and want to modify it or you forgot to add a change and need to update the last commit. Or if you want to fix the commit message, unlike hard git reset, D soft does and delete changes, keeps changes in the staging area, and allows you to easily commit again. Guitri said soft is safer because it only moves the branch pointer without affecting your changes, allowing you to modify and recommit them as needed. But the hard option shouldn't be used with caution because it permanently discards changes in both the working directory and the staging area, making it difficult or even impossible to recover those changes once they're gone. Well, for now, that's all. See you in the next lesson. 12. Advanced Git Techniques: Working with Amend, Squash, and Deleting Branches (Merged and Unmerged): Hello, guys, and we continue working with Git. Let's get to the point right away. Imagine we made a terrible commit. For example, like this. Currently, I'm in the fisher tree branch, and see the last commit with some nonsensical message. Not only that, if we go inside, we'll see that Read me file has changes that are also to put it mildly. No great. The command Git commit amend is used to make changes to the last commit. Specifically, it's used for adding new changes or changing the commit message. The first thing we'll do is fix those nonsensical changes we saw in the readme file. I will write something more or less plausible. Then we'll add these changes to the staging area and execute the command Git commit amend. When you execute the GID Commit amend, a new committee is created, that captures the current state of files. If after committing, you realize that you forgot to add some important changes, made a mistake in the commit message or decided to change everything completely. The Git Commit Amend command allows you to make additional changes to the last commit without creating a new one. In other words, it rewrites your commit. It allows you to quickly make changes and correct mistakes if you locally messed up and want to change the previous commit without cluttering the commit history. So let's also fix our nonsensical commit message. Here's what we see after amending. Will show the last commit with details. We can notice that the message was changed and the line in the read me file was modified. Our commit completely changed the message and modified the changes that were inside without cluttering the commit history with unnecessary commits. What we did essentially, was that Git rolled back one commit, and we made changes and rewrote this Cammit. Please pay attention. We didn't modify it. We rewrote now let's work with branches. The GID branch command shows all the branches we have. How can we delete unnecessary branches locally? Currently, we have main and two newly created branches. If you have completed your task in a branch and you no longer need it, you've already merged it changes into the main branch, and you can delete it locally so that it doesn't bother you. The command GID branch minus D in lowercase, and the branch name will delete this branch locally. If it exists on the remote server, it will stay there, but locally, you won't have this branch anymore. Now I'll switch to the feature one branch, which is still there, and I will make more commits to show you another thing. I will add new line to the Rhythmtixty file and commit them separately, so you can see the additions in green. When working with Git, there might be a situation where you have several consecutive commits that you want to combine into one while preserving the changes from these commits. This can be useful for improving the commit history, reducing its quantity or preparing a clean, understandable history when committing changes to the main repository. So we made changes, added if you line to our RID M file. Now we switch to the main branch to merge all these changes. The git merge squash command allows you to combine commits into one. These changes the commit history by merging changes from multiple commits into one you commit. Here we can clearly see that being in the main branch, we have a commit that consists of three commits from our feature one branch. Sometimes after you've completed your task, you made many amides in your branch, tried several variants, experimented, and you don't really want all these to be visible in overall history. In other words, your goal is to take all these changes in one commit and merge them in the main branch in the project. After running the Git merge squash command, all changes from the feature one branch are combined into a single commit as if they were made directly in the current branch. The feature one branch itself remains unchanged, allowing you to either delete it or keep it without affecting the mind history. After completing the task and merging changes with the main branch, you can delete the feature branch as it is no longer needed. And now I want to show you how to force the branch to be deleted, even if it hasn't been pushed or merged yet because we know that we cannot delete a branch in it if it has uncommitted or unmerged changes. For this, I'll make a commit and not merge it with the main branch. As you can see, I made a change in the file, added it to the staging area, and commit it. Then I'll switch to the main branch. If you need to delete a branch and the changes haven't been merged because they suddenly became unnecessary, the usual branch deletion command with minus D in lower case will not work. Will not allow you to delete the branch, but by using the minus the uppercase option. You force Git to delete the branch regardless of its merge status. It's important to be careful with this command as it irreversibly deletes the branch and its contents. Before deletion, ensure you are not losing any important changes. In the next lesson, we will dive deeper into working with logs using the Git log command. Sea. 13. Working with Git Logs: Customizing Log Output and Using Aliases: Now let's move to the logs. Often, you need to view the last comite or the last couple of commits to avoid displaying the entire log. You can execute the command Git log and specify any number with minus sign. This will show us the latest comits in the repository history. I used minus two and was shown the last two logs. The Git log d stat command is used to view detail statistics of changes for the last two emits. When you execute Git log stat, you displays the modified files along with the correction statistics. The Git log pretty one line parameter is used to display each commit in the repository history in a compact format where each commit is displayed on a separate line. The pretty one line parameter instructs Git on how to format the output of the commit history. With this parameter, we see a convenient view with the Commit has and the message in one line. The Git Log pretty format parameter is used to display Commit history with the ability to customize the output format. This command allows specifying a custom output format using special placeholders. You can use these placeholders to display various Commit attributes such as the Commit, has, author, commit message, date, and more. For example, I display just the author's name. In this variant, I show the abbreviated hash and aors name for each commit. Let's make the output more convenient. Here I display the abbreviated hash, aors name, the date the commit was made, and the message for each commit. Well, you can further enhance it by adding a graph. That is, we do almost the same, but with the addition of the graph flag, and we see beautiful and convenient log output. The Git log, since command is used to display the commit history, starting from a specific point in time. Now let's look at the log. For example, for the last three days. The Since parameter allows you to specify a day or a period of time from which you want to view the commit history. This parameter accepts various date formats. You can specify either an absolute date such as January 1, 2023 or relative time range such as two days or one month. And in the last 4 hours, we made only two emits. Or let's say, for example, the last week, or for the last day and 3 hours, we can also mix it. I'll write a command that will make a selection in one line where we can see the hash, abbreviated commit message, and where the author is Denis, ensuring these are fresh commits from the last two days. And of course, if you're working with Git in a graphical interface, you may not need this, but it's still good to know. Let's talk about Git aliases now, how to create and delete them. The Command Git config Global minus L is used to view Git settings globally. The global parameter indicates that we are working with global Git settings that apply to all repositories in your system. This command will list all git settings that have been set on your system. Now let's move to the Git aliases. An Aas is a mechanism that allows you to create shortcuts or custom commands that use a sequence of other Git commands. With aliases, you can create your own commands instead of manually entering long of complex commands. Here we can see that I've previously created several aliases. And let's take the first one. Instead of writing the full command git status, I can type ST. This is a shortcut. Or here's another alias where I can simply type GID IF and get all information I would get if I entered this command fully into the command line. Let's practice creating these aliases. For example, I will take a command that displays branches, Git branch, and take an alias for it, replacing it with the abbreviation BR. Now I will use my previous alias IF and we see new alias BR and it works. If I use this abbreviation, we will see our branches exactly as if we entered the full command. Now, let's try to delete these aliases. The unset command removes what we've already created. I can delete our alias that shows all branches. Now there is no such alias, and the command doesn't work. If we want to see all branches, we need to enter the command fully again. Besides creating your ***, there is an extension for the SH shell. For those who work with Mac and have SH on their computers, you can take advantage of additional functionality, which allows you to use aliases or short commands for more convenient and quicker execution of frequently used operations and Git. Having a list of ready made shortcuts makes it easier and faster to use Git. In the Git documentation, you can see the list of available aliases. For example, the simple command GB will show all Git branches. This abbreviation stands for branch. The abbreviation GCF will show us Git settings, and the command GST will show the status of the working directory. So for now, that's all. See you in the next lesson. Sea. 14. Understanding Git Rebase: What It Is and Why You Should Use It: Welcome back, guys. And now I'm going to talk about what rebase is in git. Rebase is the process of moving or merging a sequence of kamits into a new base mite. The main reason for using rebase is to preserve a linear history of a project. For example, imagine a situation where the main branch has progressed since you started working on a feature branch. Now, you want to incorporate the latest updates from the main branch into your feature branch while keeping its history clean, making it appear as though you are working based on the latest changes from the main branch. This makes it easier to merge your feature branch back into the main branch later. Rebase is especially useful and easiest to understand in workflow involving future branches. So let's get started. If you look at a typical Git graph structure, you will see history of merged and developing branches forming a graph. Over time, this graph can become quite tangled, making it difficult to attract specific changes. The git rebase command helps maintain a cleaner and more organized history. I will demonstrate rebase on a project where we've been working with simple mergers. Right now, our history contains many merged branches, making it somewhat messy. While working on a project, there is usually a remote repository where code is constantly being updated to ensure that your local version of the project stays up to date. With the remote version, you need to pull the latest changes before performing a rebase. The first step is to fetch the latest changes from the remote repository and update your local main branch. Since my test project isn't connected to remote repository, I don't have any new changes to pull. However, in your case, this step ensures that your local main branch is identical to the one in the remote repository. Next, I switch to my feature branch, which already contains commits. Pay attention to the Commit hashes. This is important for understanding what happens during rebase. At this point, the local main branch contains new changes that are missing from the feature branch. While working in a team, other colleagues have merged their feature branches into the main branch, and you have pulled those changes from the remote server into your local main branch. Your task now is to merge your feature branch using rebase. The Git re base command essentially makes it look as if you had started working on your feature branch from the latest Camt in mind branch. Visually, it appears as if the feature branch is moved on top of the latest Camt. However, in reality, Git rewrites the mites, which is why I asked you to know the Commit hashes. When rebase starts, it moves the head to the latest commit of the main branch and begins replaying the commits from the feature branch one by one onto this latest commit. In our case, a marriage conflict occurs, which is totally normal. At this point, you have three options. Resolve the conflict manually and continue the rebase using the command G base dash dash continua, skip the conflict mit, and move on to the next one using the base skip. Or abort the rebase and return to the previous state using the command git rebase, dash, dash, abort. I will resolve the conflict and continue rebase. After fixing the issue, GIT opens a text editor, allowing us to modify the commit message, but we will just save it as it is. Once the rebase is complete, the head moves back to our feature branch. It shifts along with Git actions, first from the last commit of the main branch to the first rebase commit of the feature branch. Then to the next rebased commit, and finally to the last rebased commit. Even though all the commits remain unchanged in terms of content, their comite hashes have been modified. The original commits still exist in the repository, but are no longer visible. Over time, they will be removed by garbage collection. After rebasing, we switch to the main branch and execute the command, git rebase feature branch. Git will analyze the main brranch, identify any missing changes, and apply these three commits from the feature branch onto the latest commit and the main branch. At this point, we can push our updated main branch back to the remote repository. But since my my project version isn't connected to remote repository, I will skip this step when making commits during rebase, it often opens win by default, which may not be convenient for everyone. If you prefer a different editor, you can set it using the command. Git config global core editor, and in my case, nano. Or if you prefer to use VS code as the default editor, you can use this command. If you don't use the weight flank, the editor might open as a blank page instead of allowing you to edit the commit message. Or you can replace it with any other editor you prefer. Since I'm comfortable with nano, I will stick with it. Guys, we learned how to use git rebase to maintain a clean linear commit history. We saw how to resolve conflicts, handle rebase operations, and change Git's default editor. Congratulations on completing the course. You made great progress, and now have a solid understanding of GID. The next step is to keep practicing. The more you use Git, the more confident you'll become. Don't just rely on theory. Apply that you've learned in real projects. Explore different git features and try using them on personal projects to deepen your understanding. Remember that Git is an essential tool for developers, and the more you practice, the better you'll be at using it efficiently in various workflows. Good luck and keep coding.