As a student, I remember the initial challenges I faced when delved into the world of programming. The complexities of version control, especially Git, seemed like a daunting obstacle to conquer. However, as I gradually started understanding Git, I realized it was a powerful tool that could simplify my coding life and even open doors to contributing to open-source projects. So, let’s embark on the world of Git and GitHub in this blog. I’ll walk through my experiences and learnings with Git and GitHub.

Module 1: Introduction to Git

Hello Tech Alchemies! Today, I want to take you on a journey through the world of Git and GitHub. Git is a powerful version control system that allows developers to track changes in their projects efficiently. Whether you're a seasoned developer or just getting started, understanding Git is essential. Let's begin with the basics.

1.1 - Version Control Systems

Before understanding Git, Let’s understand the different version control systems. Version control is like a time machine for your code. It helps you track changes, collaborate with others, and manage your project's history. There are different types of version control systems:

1. Local Version Control: In the early days, developers used simple tools to track changes on their local machines. However, this method had limitations when it came to collaboration.

2. Centralized Version Control System: To improve collaboration, centralized version control systems like Subversion (SVN) were introduced. These systems had a central server that stored the project's history, making it easier for multiple developers to work together.

3. Distributed Version Control System: The game-changer in version control is the Distributed Version Control System (DVCS), and Git is a prominent example of this. It offers a decentralized approach, allowing each developer to have a complete copy of the project's history, enabling efficient collaboration, offline work, and robust version control on their local machine. This independence is what makes Git so powerful and flexible.

1.2 - The History of Git

Git was created by Linus Torvalds in 2005. He designed it to manage the Linux kernel's development, which is one of the largest open-source projects. Git quickly gained popularity and became the go-to version control system for developers worldwide.

1.3 - Git Setup (for Windows)

Before we dive into Git's commands, let's set up Git on your Windows machine:

• Install Git for Windows.

• Use Visual Studio Code as your text editor for Git (optional but recommended).

• Check the Git version: git --version.

• List your Git configuration settings: git config list.

• Set your global username and email (for first-time users):

  • git config --global user.name "Your Name"

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

1.4 - Git Basic Commands

Now Let's discuss about some basic commands to start with Git

1.4.1 - Git init & Git Status:

1. Working Directory and Staging Area: I learned about two crucial concepts: the working directory (my project folder) and the staging area (where I prepare changes for committing).

2. Commit History: Git keeps track of all commits in the commit history.

Now, let's create your first Git repository:

• Navigate to your project's working directory.

• Initialize Git using the git init command. This creates a hidden .git folder that stores your repository's configuration and history.

• Check the repository status: git status (it should show "No untracked changes" since we haven't added any files yet).

1.4.2 - Git Add & Git Commit:

Next, we'll commit changes to your repository:

• Create a file in your working directory (e.g., demo.txt).

• After initializing Git, your local repository (.git) is set up. Use git add demo.txt to stage the file.

• The staging area (or index) is where changes are prepared for a commit.

• Commit the changes with a message: git commit -m "My First Commit".

• You can view commit history using git log.

• Each commit is identified by a checksum, which ensures the integrity of your project's history.

• You can skip the staging area when committing changes by using git commit -a -m "My Second Commit". This command adds all modified files and commits them in one step.

1.4.3 - Git Diff Command:

The git diff command allows you to see the differences between your working directory and the last committed state. Use git diff --staged to view changes in the staging area.

1.4.4 - Git Remove File:

To remove a file from both your working directory and the local repository, follow these steps:

• Use git add . to stage all files. (for suppose I have more than one file like README.md and creds.txt instead of adding file by file individually.)

• Then, use git rm --cached creds.txt to remove the file from the local repository while keeping it in your working directory. Later we can delete that file in the working repository manually.

• Finally, commit the changes with an appropriate message, e.g., git commit -m "Removed the creds".

Module 2: GitHub Repository: Collaborating and Sharing Your Code

In our journey through the world of Git and GitHub, we've covered the fundamentals of version control and the basics of Git commands. Now, let's explore GitHub, one of the most popular platforms for hosting and collaborating on Git repositories.

2.1 - Introduction to GitHub

GitHub is a web-based platform that provides remote repositories for your Git projects. It's widely used by developers to collaborate on open-source projects, share code, and manage software development workflows. Whether you're working on a solo project or with a team, GitHub offers a seamless way to collaborate and track changes.

2.1.1 - Example Use Case

Imagine you're part of a team working on a web application. GitHub would be an ideal platform to host your project. You can collaborate with team members, keep track of changes, and easily manage issues and pull requests.

2.2 - Multiple Remote Repository Options

While GitHub is a popular choice, there are other remote repository hosting services like GitLab and Bitbucket by Atlassian. These platforms offer similar functionalities and can be chosen based on your team's preferences and needs.

2.3 - Setting Up Your GitHub Profile

Before diving into GitHub, you'll need to set up your GitHub profile:

1. Sign Up: If you don't have a GitHub account, sign up for one at GitHub's website.

2. Profile Information: Complete your profile with a profile picture, bio, and other relevant information.

3. Two-Factor Authentication (2FA): Enable 2FA for added security.

Now, let's continue with the practical steps of working with GitHub and Git.

2.4 - Creating and Pushing to a GitHub Repository

1. Clone an Existing Repository:

   • You can clone an existing GitHub repository to your local machine using the command: git clone https://github.com/example/demo.git.

2. Create Your Repository:

   • On your GitHub profile, click on the "New" button to create a new repository. You'll receive a unique link to this repository, e.g., https://github.com/yourusername/git-course.git.

3. Create a Local Repository:

   • On your local machine, create a new directory for your project, e.g., mkdir git-course.

   • Inside this directory, create a file called readme.md to get started.

4. Initialize Git:

   • Navigate to your project folder (cd git-course) and run git init to initialize a Git repository in this directory.

5. Check Status:

   • Use git status to check the status of your repository. It will show that readme.md is an untracked file.

6. Add and Commit:

   • Add the readme.md file to the staging area with git add readme.md.

   • Commit the changes with a meaningful message: git commit -m "first commit".

7. Push to GitHub:

   • After creating your local Git repository and initializing it, you'll want to connect it to your GitHub repository. There are two methods to do this, SSH and HTTPS.

   • Using SSH (Secure Shell)

     1. Generate an SSH Key:

        • To use SSH for secure communication, you'll need to generate an SSH key pair. Run the following command in your terminal:

          ssh-keygen -o

        • The -o flag is used to generate an OpenSSH key format, which is more secure.

     2. Copy the Generated SSH Key:

        • Once the key pair is generated, you'll find them in your ~/.ssh/ directory. Look for id_rsa.pub. This is your public key.

        • Use a text editor or the cat command to display the key:

          cat ~/.ssh/id_rsa.pub

        • Copy the entire key.

     3. Add SSH Key to GitHub:

        • Log in to your GitHub account and go to the "Settings" page.

        • In the left sidebar, click on "SSH and GPG keys."

        • Click the "New SSH key" button.

        • Give your key a title (e.g., "My SSH Key").

        • Paste the copied public key (id_rsa.pub) into the "Key" field.

        • Click "Add SSH key."

     4. Add Remote Origin:

        • Add the remote GitHub repository as the origin: git remote add origin git@github.com:yourusername/git-course.git.

Now, your local Git repository is linked to your GitHub repository using SSH. You can push and pull changes securely.

• Using HTTPS

  Alternatively, you can use HTTPS to connect your local Git repository to your GitHub repository. Here's how:

  1. Copy the GitHub Repository URL:

     • On your GitHub repository's main page, click the "Code" button, and make sure "HTTPS" is selected.

     • Copy the repository URL, e.g., https://github.com/yourusername/git-course.git.

  2. Add Remote Origin (HTTPS):

     • In your local Git repository's directory, add the remote GitHub repository as the origin using the HTTPS URL:

       git remote add origin https://github.com/yourusername/git-course.git

Now, your local Git repository is linked to your GitHub repository using HTTPS. You can push and pull changes over HTTPS securely.

Choose the method that best suits your needs or the organization's security policies. Both methods are widely used and effective for collaborating with GitHub repositories.

1. Push Your Code:

   • Finally, push your code to GitHub's main branch: git push -u origin main.

2. git remote -v command

   The git remote -v command shows the remote URLs associated with your Git repository. This is useful when you want to check where your local repository is connected.

Now, as you continue working on your project, you can add more files, make changes, and use the same Git commands (add, commit, push) to keep your GitHub repository up to date. For example, creating a UserService.txt file, adding it to the staging area, committing, and pushing the changes. For example, add and commit a file: git add UserService.txt and git commit -m "Processing user data". Push your code changes to GitHub as usual: git push origin main.

This workflow is the foundation for effective version control and collaboration using Git and GitHub.

Module 3: Working with Tags in GitHub: Managing Versions with Ease

We've covered the basics of creating repositories and pushing code. Now, let's delve into another essential aspect of version control: tags. Tags are like bookmarks in your project's history, allowing you to mark specific points as significant releases or milestones.

Now, let's understand tags using Visual Studio Code's repository as an example.

3.1 - Introduction to Tags

Tags come in two flavours: annotated tags and lightweight tags.

• Annotated Tags: These are like full releases. They store extra information like the tagger's name, email, date, and a tagging message. They are excellent for documenting significant releases.

• Lightweight Tags: These are just pointers to specific commits. They are simple and don't store any extra information. Lightweight tags are great for marking specific commits without the formality of an annotated tag.

3.2 - Tag Commands

Let's go through the tag commands step by step:

1. View Existing Tags:

   • Use git tag to display all existing tags in your repository.

2. Create an Annotated Tag:

   • To create an annotated tag, such as v1.0 with the message "1st release," use the command: git tag -a v1.0 -m "1st release".

3. View Tag Details:

   • You can view the details of a specific tag, e.g., v1.0, with: git show v1.0.

4. Create Another Tag:

   • Create another tag, e.g., v1.1, with a message: git tag v1.1 -m "22nd Sep release".

5. Push Tags to GitHub:

   • To share your tags with GitHub, use the following commands:

     • git push origin v1.0

     • git push origin v1.1

By pushing your tags to GitHub, you make it easier for collaborators and users to access specific versions of your project. This is especially valuable when you want to provide stable releases or allow users to reference specific points in your project's history.

With tags, you have a way to mark important moments in your project's timeline, making it simpler to manage versions and releases. Whether you're working on a personal project or collaborating with a team, understanding tags is a valuable skill in the world of Git and GitHub.

Module 4: Cloning a Project: Exploring Visual Studio Code's Source Code

Now that you've gained a solid understanding of Git, GitHub, and tagging, it's time to put your knowledge to practical use by cloning a project. In this section, we'll explore how to clone the source code of Visual Studio Code (VS Code) by Microsoft. This hands-on experience will give you insights into how open-source projects are structured and managed.

4.1 - Finding and Understanding the Project

1. Search for VS Code on GitHub:

   • Open your web browser and go to GitHub (github.com).

   • In the GitHub search bar, type "Microsoft VS Code" and hit Enter.

   • Click on the repository that represents the source code of VS Code. This is where all the project's code and history are stored.

2. Exploring README.md file:

   • Take some time to explore the README.md file. It often provides valuable information about the project's purpose, how to set it up, and its contribution guidelines. This file serves as a roadmap to understanding the project.

4.2 - Cloning the Repository

Now, let's clone the VS Code repository to your local machine:

1. Using Command Prompt (or Terminal):

   • Open your command prompt or terminal.

   • Navigate to the directory where you want to clone the repository.

   • Use the command git clone followed by the URL of the project repository. For example: git clone https://github.com/microsoft/vscode.git.

   • This command fetches all the code and project history, creating a local copy on your machine.

2. Alternative: Download ZIP:

   • If you prefer not to use the command line, you can download the repository as a ZIP file directly from the GitHub repository page.

   • Click on the "Code" button and select "Download ZIP."

   • Extract the ZIP file to your desired location.

4.3 - Exploring the Cloned Repository

With the project cloned, you can now explore its contents, make changes, and even use the Git commands you've learned in previous sections. Here are some things you can do:

• Commit and Tag: Make changes to the code, use git add to stage them, git commit to commit changes, and git tag to mark significant points in your local repository.

• View Commit History: Use git log --pretty=oneline to see a concise history of commits and their messages.

4.4 - Contribution Limitations:

While you can experiment with the VS Code source code and learn from it, please note that you can't push changes directly to the remote repository for VS Code since you're not a contributor to that open-source project. Additionally, you won't be able to create branches in the VS Code repository.

This experience is valuable for learning, and you can apply what you've discovered to your projects or open-source contributions in the future. Feel free to explore, experiment, and learn from one of the most popular open-source projects in the world.

Module 5: Git Branch: The Power of Parallel Development

In this section, we'll explore one of Git's most compelling features: branching. Branching is what sets Git apart as an incredibly versatile version control system. Let's dive into the world of branches in Git and GitHub.

5.1 - Introduction to Branches:

In Git and GitHub, branches are parallel lines of development that allow you to work on multiple features, bug fixes, or experiments simultaneously. This powerful feature enables you to isolate changes, collaborate efficiently, and maintain a clean project history.

5.2 - Creating Branches

There are two ways to create branches using the terminal:

• Using git checkout: This is the older way of creating branches. For example, to create a new branch named feature1 and switch to it, you would use the command: git checkout -b feature1. The -b flag indicates branch creation.

• Using git switch (Newer Approach): In recent Git versions, you can use the git switch command. For example, git switch main switches to the main branch. To create and switch to a new branch, use git switch -c feature2, where -c stands for "create."

5.3 - Working with Branches:

You can create as many branches as you need, and there's no strict limit. Each branch is a separate workspace for your changes, allowing you to work on different features or fixes simultaneously.

When you initialize a Git repository with git init, it creates a default branch called main (formerly master). The first commit you make creates a snapshot of your project files and assigns a unique commit number (checksum) to it.

Now, let's explore branch operations and their impact on Git's underlying structure. We'll use the main and feature1 branches as references.

When you make changes in one branch, those changes are isolated to that branch only. For example, if you modify a file like UserService.txt in the feature1 branch, the changes won't affect the main branch until you merge them.

To visualize this, you can use the command git log --all --graph. Alternatively, you can install the VS Code extension 'Git Graph' for a more user-friendly branch visualization.

Branching is a fundamental concept in Git, and mastering it is a key to efficient and organized development. With branches, you can explore new features, fix issues, and experiment without affecting the stability of your main project.

5.4 - Merging Branches:

Now, let's say you've been working in the feature1 branch and made significant changes. How do you get those changes into the main branch? This is where merging comes into play. We'll explore this in detail shortly.

5.5 - Deleting Branches

But before we move on to merging, let's understand how to delete branches:

• To delete a branch, use the command: git branch -d feature2, where feature2 is the branch you want to delete.

• You can also use the shortcut git switch - to quickly switch back to the previous branch.

Module 6: Git Merge: Bringing Branches Together

we've learned about the power of branching. Now, let's understand how to bring these branches together using the git merge command.

6.1 - Introduction to merge in Git

Merging is the process of integrating changes from one branch into another. It allows you to combine the work done in separate branches, creating a cohesive and unified codebase. In our case, let's consider merging changes from the feature1 branch into the main branch.

6.2 - Merging Branches

Here's how to merge branches in Git:

1. Ensure You're on the Target Branch: Before you merge, ensure you are on the branch where you want the changes to be incorporated. In this case, you should be on the main branch since we want to merge feature1 into it.

2. Pull the Latest Changes (Recommended): To avoid potential merge conflicts, it's a good practice to pull the latest changes from the remote repository into your local main branch. You can do this with the command: git pull origin main.

3. Merge the Branch: To merge the feature1 branch into main, use the command: git merge feature1. This combines the changes from feature1 into main.

4. Resolve Conflicts (if any): Git will automatically merge changes if they don't conflict. However, if there are conflicting changes (i.e., changes made to the same lines in both branches), Git will prompt you to resolve them manually.

5. Commit the Merge: After resolving any conflicts, commit the merge changes with a meaningful message. You can use git commit -m "Merged feature1".

6. Push Changes to Remote Repository: Finally, push the merged changes to the remote repository using git push origin main.

By following these steps, you integrate the work done in the feature1 branch into the main branch, making the changes available to others collaborating on the project.

Merging is a crucial part of collaborative development and is essential for keeping your project's codebase organized and up to date. As you work with larger teams and more complex projects, understanding merge processes becomes even more critical.

Module 7: Understanding Merge Conflicts in Git

we've explored the concept of branching and merging. Now, let's dive into a scenario that every developer encounters at some point: merge conflicts.

7.1 - Introduction to Merge Conflicts in Git

A merge conflict occurs when Git is unable to automatically merge changes from different branches. This happens when:

• Changes made in one branch conflict with changes in another branch.

• Git cannot determine which version to accept automatically.

Merge conflicts can be a bit intimidating, but they are a natural part of collaborative development. They arise when multiple contributors modify the same part of a file or when changes in one branch conflict with the changes in another branch.

7.2 - Creating a Demo Merge Conflict

Let's create a simple demo merge conflict and then resolve it step by step using our reference branches main and feature1. In this example, we'll modify the same line of code in both branches.

1. Ensure you are on the feature1 branch using the command: git switch feature1.

2. Open a file, let's say UserService.txt, in your code editor. Make changes to a specific line of code.

3. Commit your changes using: git add UserService.txt followed by git commit -m "Made changes in feature1".

4. Now, switch back to the main branch using: git switch main.

5. Open UserService.txt again. This time, make changes to the same line that you modified in the feature1 branch.

6. Commit your changes to the main branch with: git add UserService.txt followed by git commit -m "Made changes in main".

Now, we've intentionally created a conflict by modifying the same line in both branches. Let's see how Git handles this.

7.3 - Resolving the Merge Conflict

1. On the main branch, attempt to merge feature1 using: git merge feature1.

2. Git will detect the conflict and inform you about the conflicting file(s).

3. Open the conflicted file (UserService.txt) in your code editor. You will see conflict markers <<<<<<<, =======, and >>>>>>> surrounding the conflicting changes.

4. Edit the file to choose which changes to keep. Remove the conflict markers and any unwanted code. Save the file.

5. After resolving the conflict, add the file with conflicts resolved: git add UserService.txt. Commit the merge with a message: git commit -m "Resolved merge conflict".

6. Finally, push the merged changes to the remote repository: git push origin main.

You've successfully resolved a merge conflict. By manually resolving conflicts, you ensure that the final result is consistent with your project's requirements.

Merge conflicts are a part of collaborative development, and mastering conflict resolution is a valuable skill. Remember, communication with your team and clear documentation of changes can help minimize conflicts and ensure smooth collaboration.

Module 8: Feature Branch Workflow: Streamlining Collaborative Development

we've already covered branching, merging, and resolving conflicts. Now, let's delve into an essential workflow for collaborative development: the Feature Branch Workflow. This workflow helps teams work on new features, bug fixes, or improvements collaboratively while maintaining code quality through code reviews.

8.1 - The Problem: Code Reviews

Code reviews are a crucial aspect of maintaining code quality and catching issues early. However, they can become complex when multiple team members work on different features or bug fixes simultaneously. This is where the Feature Branch Workflow comes into play.

8.2 - The Feature Branch Workflow in Action

Let's walk through the steps of the Feature Branch Workflow using our previous example with branches main and feature1. We'll also create a new feature branch named feature2 for demonstration.

1. First, ensure you are on the main branch using git switch main.

2. Create a new feature branch (e.g., feature2) using: git switch -c feature2.

3. Make changes to the code related to your new feature or bug fix within the feature2 branch.

4. Commit your changes within the feature2 branch using git add and git commit.

5. Push your feature2 branch to GitHub using: git push origin feature2.

6. Create a Pull Request (PR):

   • If a pull request isn't automatically generated when you push the fearture2, branch, you can create one manually.

   • On GitHub, navigate to the repository.

   • Click on the "Pull Requests" tab and then click the "New Pull Request" button.

   • Choose the base branch (e.g., main) and the compare branch (feature2).

   • Add a title and description for the PR, outlining the changes made.

   • Reviewers can be assigned to examine the code changes.

7. Code Reviews:

   • Team members review the code, add comments, and discuss changes if necessary. GitHub provides a collaborative platform for code reviews.

8. Merge the Feature Branch:

   • After the code is reviewed and approved, the code owner can merge the feature2 branch into main directly on GitHub.

   • This integration is seamless and ensures that only reviewed and approved code makes it into the main branch.

By following the Feature Branch Workflow, teams can work in parallel on various features and bug fixes, isolate changes, and maintain code quality through code reviews. This process helps streamline development efforts and ensures that only well-tested and approved code is merged into the main codebase.

Remember that the Feature Branch Workflow promotes collaboration and allows teams to be agile in their development process. It's a valuable addition to your version control toolkit, whether you're working on open-source projects or within a corporate environment.

Module 9: Updating Your Local Repository After a Merge

we've covered various aspects of version control and collaboration. Now, let's focus on keeping your local repository up-to-date after a merge. This is crucial to ensure that you're working with the latest code and changes made by your collaborators.

9.1 - The Need for Updates

After a successful merge, where your feature branch has been merged into the main branch (or master branch, depending on your Git version), it's essential to synchronize your local repository. This step is necessary to incorporate any new changes that may have been made to the remote repository.

9.2 - Updating Your Local Repository

Here are two common commands you can use to update your local repository:

1. git fetch

   • This command fetches the latest changes from the remote repository but doesn't automatically apply them to your working branch.

   • To use it, simply run: git fetch.

2. git pull

   • This command combines the git fetch and git merge operations in one step. It fetches the latest changes from the remote repository and merges them into your current branch.

   • To update your main branch (or any other branch), you can use: git pull origin main.

It's important to note that using git pull may automatically merge changes into your current branch, which can potentially lead to merge conflicts if not handled correctly. On the other hand, using git fetch allows you to review the changes fetched from the remote repository before merging them manually.

9.3 - Ensuring Your Local Repository Is Up-to-Date

Whether you choose to use git fetch or git pull, regularly updating your local repository is a best practice to:

• Stay aligned with the latest code changes.

• Minimize potential merge conflicts.

• Ensure you have the most recent code for testing and development.

By keeping your local repository up-to-date, you contribute to a smoother and more efficient collaborative development process. You can confidently work on your tasks knowing that you have the most recent code at your fingertips.

Module 10: Merge Conflicts in Feature Branch Workflow

we've explored various workflows, and branches, and resolved conflicts. Now, let's delve into a common scenario in the Feature Branch Workflow: merge conflicts when merging a feature branch into the main branch. We'll use an example to illustrate this situation.

10.1 - Understanding the Cause of Merge Conflicts

Merge conflicts arise when changes made in different branches conflict with each other. Let's create a scenario using branches main, feature1, and feature3.

1. First, ensure you are on the main branch using git switch main.

2. Create a new feature1 branch and switch to it: git switch -c feature1.

3. Modify the README.md file in the feature1 branch. For example, add some text.

4. Commit your changes and push them to GitHub: git add README.md, git commit -m "Made changes in feature1", git push origin feature1.

5. Now, create a new feature3 branch based on main: git switch -c feature3.

6. Make the same changes in the feature3 branch, modify the README.md file as in feature1 branch.

7. Commit your changes and push them to GitHub: git add README.md, git commit -m "Made changes in feature3", git push origin feature3.

Now, we have two feature branches (feature1 and feature3) with conflicting changes in the same file (README.md). When you attempt to merge feature to main it works perfectly fine. But when you attempt to merge feature3 into main, a merge conflict will occur as feature1 branch is already pushed into the main branch.

10.2 - Resolving Merge Conflicts

When you create a pull request to merge feature3 into main, GitHub will detect the conflict in the README.md file. You'll need to resolve it manually:

1. Open a Pull Request for feature3 into main:

   • On GitHub, navigate to the repository.

   • Click on the "Pull Requests" tab and then create a new pull request from feature3 to main.

2. Conflict Detected:

   • GitHub will notify you that there's a conflict in the README.md file.

3. Manual Resolution:

   • Click the "Resolve conflicts" button.

   • GitHub provides a side-by-side view of the conflicting changes.

   • Edit the file to choose which changes to keep.

   • Remove the conflict markers (<<<<<<<, =======, and >>>>>>>).

   • Save your changes.

4. Commit the Merge:

   • After resolving the conflict, GitHub allows you to commit the merge with a message.

5. Merge the Pull Request:

   • Merge the pull request as usual, and the conflicting changes will be incorporated into the main branch.

By following these steps, you can resolve merge conflicts efficiently, ensuring that your codebase remains stable and that all changes are properly integrated.

Module 11: Resolving Merge Conflicts on Your Computer

Finally, we'll explore how to resolve merge conflicts on your local computer using the same scenario as before. We'll create merge conflicts between two feature branches (feature4 and feature5) that modify the same file (README.md), push them to GitHub, and then resolve the conflicts on your computer.

11.1- Setting Up the Scenario

1. Ensure You're on the main Branch:

   • First, ensure you are on the main branch using: git switch main.

2. Pull the Latest Changes from main:

   • Make sure your main branch is up-to-date by pulling the latest changes from GitHub: git pull origin main.

3. Create the feature4 Branch:

   • Create a new branch feature4 and switch to it: git switch -c feature4.

4. Make Changes in feature4 Branch:

   • Modify the README.md file in the feature4 branch with some text.

5. Commit and Push Changes in feature4 Branch:

   • Commit your changes and push them to GitHub: git add README.md, git commit -m "Made changes in feature4", git push origin feature4.

6. Create the feature5 Branch:

   • Now, create another branch feature5 based on main: git switch -c feature5.

7. Make the Same Changes in feature5 Branch:

   • In the feature5 branch, modify the README.md file with different text than in feature4.

8. Commit and Push Changes in feature5 Branch:

   • Commit your changes and push them to GitHub: git add README.md, git commit -m "Made changes in feature5", git push origin feature5.

11.2 - Resolving Merge Conflicts Locally

Now that we have created conflicting changes in branches feature4 and feature5, let's resolve the merge conflict locally on your computer:

1. Switch to the main Branch:

   • Ensure you are on the main branch: git switch main.

2. Merge feature5 into main:

   • Attempt to merge feature5 into main locally: git merge feature5.

   • This will generate a merge conflict.

3. Resolve the Merge Conflict:

   • Open the conflicted README.md file in your code editor.

   • Manually edit the file to choose which changes to keep.

   • Remove the conflict markers (<<<<<<<, =======, and >>>>>>>).

4. Save and Commit:

   • Save the file after resolving the conflict.

   • Commit the resolved changes: git add README.md, git commit -m "Resolved merge conflict in feature5".

5. Merge feature4 into main:

   • Now, attempt to merge feature4 into main locally: git merge feature4.

   • This should merge without conflicts since we've already resolved the feature5 conflict.

6. Commit the Merge:

   • Commit the merged changes: git commit -m "Merged feature4 into main".

7. Push Changes to GitHub:

   • Finally, push the merged changes to GitHub: git push origin main.

By following these steps, you've resolved merge conflicts locally on your computer. This process ensures that you have full control over resolving conflicts and integrating changes smoothly into your codebase.

Conclusion

In this blog, we've embarked on a journey through the world of Git and GitHub, uncovering essential concepts and workflows that empower developers to collaborate effectively, manage code changes, and maintain code quality. From branching and merging to resolving merge conflicts, we've covered critical aspects of version control and collaboration.

We began by exploring Git's fundamentals, delving into version control systems and Git's history. We set up Git on our local machine, initialized repositories, and understood the concepts of working directories, staging areas, and commit histories.

We ventured into the realm of remote repositories, focusing on GitHub as a popular platform for collaboration. We created repositories, learned how to clone them, and discussed the significance of SSH keys for secure access.

The blog continued with an exploration of Git tags, offering a way to label specific points in the commit history, and we saw how to work with tags, including annotated and lightweight tags.

We ventured into the Feature Branch Workflow, a crucial approach for collaborative development, and understood the importance of code reviews. We created feature branches, uploaded them to GitHub, and learned how to create and merge pull requests.

Additionally, we faced merge conflicts, both on GitHub and locally, and mastered the art of resolving them. These conflict-resolution skills are vital for keeping codebases stable and collaborative.

Now, as you embark on your own Git and GitHub journey, remember that practice and clear communication with your team are key to successful collaboration. You can access the entire workflow covered in this blog on my GitHub repository git-course.

Happy coding and collaborating! 🚀🌟