Git and Github Guide

What is Git?

Git is a distributed version control system that tracks changes to code over time. It allows multiple developers to work on a project simultaneously, with features like branching for independent work and merging changes back together. Git is widely used in software development for its efficiency, collaboration capabilities, and robust history tracking.

What is Github?

GitHub is a web-based platform for hosting Git repositories and collaborating on software development projects. It offers features like repository hosting, collaboration tools such as pull requests and issue tracking, and integration with other development tools.

Configuring Git

Configuring Git is an essential step to personalize your development environment and ensure smooth collaboration with others. Here's a brief overview of how to configure Git:

• Setting up user information: Use the git config command to set your name and email address. This information is used to identify your commits.

git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

• Checking configurations: You can verify your configurations by using:

git config --list

Basic Commands:

Clone Command: The git clone command is used to create a copy of an existing Git repository from a remote server to your local machine. Here's how you can use it:

git clone https://github.com/user/repository.git

Status Command: The git status command is used to show the current state of the repository. It displays information about tracked, untracked, and staged files, as well as the current branch and any changes that have been made. Here's how to use it:

git status

Add Command: The git add command is used to add changes in the working directory to the staging area, preparing them to be included in the next commit. Here's how to use it:

You can specify one or more files or directories to add to the staging area. For example, to add a single file:

git add filename.txt

To add all changes in the current directory and its subdirectories:

git add .

Commit Command: The git commit command is used to save the changes in the staging area to the local repository. It creates a new commit containing the changes along with a commit message describing the changes made. Here's how to use it:

git commit -m "commit message"

Push Command: The git push command is used to upload local repository commits to a remote repository, typically hosted on a service like GitHub, GitLab, or Bitbucket. Here's how to use it:

git push origin main

Init Command: The git init command is used to initialize a new Git repository in the current directory or in a specified directory. Here's how to use it:

git init

The git remote add origin <link> command is used to add a remote repository to your local Git repository and name it "origin." This allows you to push your local changes to the specified remote repository or pull changes from it.

The git remote -v command is used to view the list of remote repositories associated with your local Git repository, along with their corresponding URLs.

The git branch command is used to list, create, or delete branches in a Git repository.

The git branch -M main command is used to rename the current branch to "main". This is commonly done when transitioning from using "master" as the default branch name to "main", which is a more inclusive and neutral term.

The git push origin main command is used to push the commits from your local "main" branch to the remote repository named "origin".

git push -u origin main pushes the commits from your local "main" branch to the "main" branch on the remote repository named "origin", while also setting the upstream branch to "origin/main" for future pushes.

Git Branches

Git branches are lightweight pointers to commits that allow for parallel development, isolation of features or fixes, and organizational flexibility within a repository. They enable developers to work on different aspects of a project independently while maintaining the stability of the main codebase. Branches can be created, listed, renamed, deleted, and merged, providing a powerful mechanism for collaboration and version control in software development workflows.

Branch Commands:

1. Create a Branch:

   • git branch [branch_name]: Creates a new branch with the specified name.

2. Switch to a Branch:

   • git checkout [branch_name]: Switches to the specified branch.
   • git switch [branch_name]: Switches to the specified branch (Git 2.23 and later).

3. Create and Switch to a Branch:

   • git checkout -b [branch_name]: Creates a new branch with the specified name and switches to it.
   • git switch -c [branch_name]: Creates a new branch with the specified name and switches to it (Git 2.23 and later).

4. List Branches:

   • git branch: Lists all branches in the repository. The current branch is marked with an asterisk (*).

5. Rename a Branch:

   • git branch -m [new_branch_name]: Renames the current branch to the specified name.

6. Delete a Branch:

   • git branch -d [branch_name]: Deletes the specified branch if it's fully merged into the current branch.
   • git branch -D [branch_name]: Forces deletion of the specified branch, even if it contains unmerged changes.

7. Merge Branches:

   • git merge [branch_name]: Merges the specified branch into the current branch.

8. Visualize Branches:

   • git log --graph --oneline: Displays a visual representation of branch history.

These commands provide essential functionality for managing branches in Git repositories, allowing developers to organize their work, collaborate effectively, and maintain a structured version control workflow.

Pull Request:

A pull request (PR) is a feature provided by platforms like GitHub, GitLab, and Bitbucket that allows developers to propose changes to a repository hosted on these platforms. Here's how a pull request typically works:

1. Create a Branch:
   Before making changes, create a new branch in the repository. This branch will contain the changes you want to propose.

2. Make Changes:
   Make your desired changes to the codebase in your branch. This could involve adding new features, fixing bugs, or making improvements.

3. Push Changes:
   Once you're done with your changes, push your branch to the remote repository on the platform (e.g., GitHub). This makes your changes accessible to others.

4. Open a Pull Request:
   On the platform's website, navigate to the repository and find your branch. Then, click on the "New pull request" button. This will open a page where you can compare the changes between your branch and the main branch of the repository.

5. Review Changes:
   In the pull request view, you and your team members can review the changes made in your branch. You can leave comments, ask questions, and provide feedback on the proposed changes.

6. Resolve Feedback (if any):
   If there are comments or feedback on your pull request, address them by making additional changes to your branch. You can push these changes to the same branch, and the pull request will be automatically updated.

7. Merge Pull Request:
   Once the changes are reviewed and approved, you can merge your branch into the main branch of the repository using the merge button on the pull request page.

8. Delete Branch (Optional):
   After merging the pull request, you can delete the branch you created for the pull request. This helps keep the repository clean and organized.

The git pull command is used to fetch changes from a remote repository and merge them into the current branch in your local repository.

Merge Conflicts:

Merge conflicts occur when Git is unable to automatically merge changes from different branches due to conflicting modifications to the same part of a file or files. Here's how to handle merge conflicts:

1. Identify Conflicts:
   When you attempt to merge branches with conflicting changes, Git will notify you of the conflicts. You'll see messages indicating which files have conflicts.

2. Open Conflicted Files:
   Open the conflicted files in your code editor. Git will mark the conflicting sections within the files, indicating the changes from both branches.

3. Resolve Conflicts:
   Manually edit the conflicted sections within the files to resolve the conflicts. Decide which changes to keep, modify, or discard. Remove conflict markers (<<<<<<<, =======, >>>>>>>) once conflicts are resolved.

4. Save Changes:
   Save the changes to the conflicted files after resolving the conflicts in your code editor.

5. Add Conflicted Files:
   After resolving conflicts, stage the conflicted files using git add [file].

6. Commit Changes:
   Once all conflicts are resolved, complete the merge by committing the changes using git commit. Git will automatically generate a merge commit message summarizing the merge.

7. Verify Merge:
   After committing the changes, verify that the merge was successful by reviewing the merged code and testing the application.

8. Push Changes (if merging in a shared repository):
   If you're merging branches in a shared repository and want to push the changes to the remote repository:
   

   git push origin [branch_name]

Fixing Mistakes:

Case 1: Staged Changes

git reset <filename>

This command unstages the changes in <filename>.

git reset

This command unstages all changes.

Case 2: Committed Changes (for one commit)

git reset HEAD~1

This command resets the HEAD pointer to the previous commit (HEAD~1), effectively undoing the last commit while keeping the changes in your working directory.

Case 3: Committed Changes (for many commits)

git reset <commit-hash>

This command resets the HEAD pointer and the current branch to <commit-hash>, discarding all commits made after that commit. The changes are preserved in your working directory.

git reset --hard <commit-hash>

This command does the same as the previous one but additionally resets the working directory to match the specified commit, discarding any changes not committed. Use with caution as it's an irreversible operation.

These commands are useful for fixing mistakes in different stages of your Git workflow, whether it's unstaging changes, undoing commits, or resetting to a specific commit in your repository's history.

What is Forking?

Forking is a concept commonly used in Git and version control systems like GitHub. It refers to creating a personal copy of someone else's project or repository. When you fork a repository, you create a copy of the original repository under your own account, allowing you to freely experiment with changes without affecting the original project.

Here's how forking typically works:

1. Repository Ownership:

   • The original repository is owned by someone else or an organization, and you want to contribute to it or work on your own version of the project.

2. Creating a Fork:

   • On platforms like GitHub, you can fork a repository by clicking the "Fork" button on the repository's page. This creates a copy of the repository under your GitHub account.

3. Working on Your Fork:

   • Once you've forked the repository, you have your own copy of the project to work with. You can make changes, add features, fix bugs, or experiment with new ideas in your forked repository.

4. Contributing Changes:

   • After making changes in your forked repository, you can propose these changes to be incorporated into the original project by submitting a pull request. This allows the maintainers of the original repository to review your changes and decide whether to accept them.

5. Syncing with the Original Repository:

   • Over time, the original repository may receive updates or changes. To keep your forked repository up-to-date with these changes, you can sync it with the original repository by adding the original repository as a remote and pulling changes from it.

Forking is a powerful feature that promotes collaboration and open-source development. It allows developers to contribute to projects they're interested in, experiment with new ideas, and maintain their own versions of projects while still benefiting from the original codebase and community contributions.