GIT

 


What is Git?

Git is a distributed version control system designed to track changes in source code during software development. It allows multiple developers to collaborate on projects, managing their revisions and integrating their work seamlessly. Git provides mechanisms to handle various aspects of version control, such as branching, merging, and conflict resolution.

What is Git lifecycle?

The Git life cycle refers to the various stages that files and projects go through when using Git for version control. Here are the key stages:

  1. Working Directory: This is where you create, modify, and delete files in your project. Any changes made here are not tracked by Git until you explicitly tell Git to do so.

  2. Staging Area (Index): This acts as a middle ground between your working directory and the Git repository. Files here are ready to be committed to the repository. You use the git add command to move changes from the working directory to the staging area.

  3. Local Repository: This is the Git directory on your local machine where Git permanently stores the snapshots of your project. When you use the git commit command, Git takes the files from the staging area and stores them as a permanent snapshot in the local repository.

  4. Remote Repository: This is a Git repository that is hosted on a remote server, such as GitHub, GitLab, or Bitbucket. You can push your local repository changes to the remote repository using git push and fetch changes from the remote repository to your local repository using git fetch or git pull.

Here's a brief overview of how the Git life cycle works in practice:

  • Modify files: Make changes to files in your working directory.

  • Stage files: Use git add to move changes from the working directory to the staging area.

  • Commit changes: Use git commit to take the files from the staging area and permanently store them in the local repository.

  • Push changes: If working with a remote repository, use git push to send committed changes from your local repository to the remote repository.

  • Fetch/pull changes: Use git fetch to retrieve changes from the remote repository to your local repository without merging, or use git pull to fetch and automatically merge changes from the remote repository into your current branch.

This cycle repeats as you continue to make changes, stage them, commit them, and synchronize with remote repositories as needed. Git's flexibility and power come from its ability to manage changes across different stages efficiently.




Different Branching Strategies in Git

Branching strategies in Git define how branches are created, managed, and integrated within a repository. Here are some commonly used branching strategies:

  1. Feature Branch Workflow:

    • Explanation: In this strategy, each new feature or task is developed in a dedicated branch.
    • Workflow:
      • Create a new branch from main (or master).
      • Implement the feature or fix in the branch.
      • Test and review the changes locally.
      • Merge the feature branch back into main (or master) after completion.
  2. Git Flow:

    • Explanation: Git Flow is a branching model that defines a strict branching structure for larger projects.
    • Workflow:
      • master: Represents production-ready code.
      • develop: Integration branch for ongoing development.
      • feature/*: Feature branches branched off develop.
      • release/*: Preparation for a new production release.
      • hotfix/*: Fixes to production code directly on master.
  3. GitLab Flow:

    • Explanation: Simplified version of Git Flow, primarily aimed at Continuous Integration/Continuous Deployment (CI/CD) pipelines.
    • Workflow:
      • Single branch (main or master).
      • Feature branches are directly merged into the main branch after review.
      • Tags mark releases.
  4. Trunk-Based Development:

    • Explanation: Development directly on the main branch (main or master), with short-lived feature branches.
    • Workflow:
      • Create feature branches for short-lived changes.
      • Merge back into the main branch frequently.
      • Use feature flags for unfinished work.

Managing Conflicts in Git

Conflicts in Git occur when changes from different branches cannot be automatically merged. Here’s how to manage conflicts:

  1. Identify Conflicts:

    • Git will notify you of conflicting files during a merge or rebase operation.
  2. Resolve Conflicts:

    • Open conflicting files in your code editor.
    • Git marks the conflicting sections (<<<<<<<, =======, >>>>>>>).
    • Edit the files to resolve conflicts manually, keeping the desired changes and removing markers.
  3. Stage Changes:

    • After resolving conflicts, stage the modified files using git add.
  4. Commit the Merge:

    • Complete the merge commit with git commit.
    • Git provides a default merge message, which you can edit if needed.
  5. Continue Rebase or Merge:

    • If conflicts occur during a rebase, resolve conflicts similarly after each commit in the rebase process.
  6. Aborting:

    • If you encounter too many conflicts or make mistakes, you can abort the merge or rebase with git merge --abort or git rebase --abort.

Best Practices for Conflict Resolution:

  • Regular Updates: Fetch and merge upstream changes frequently to minimize conflicts.
  • Clear Communication: Coordinate with teammates to avoid conflicting changes.
  • Testing: After resolving conflicts, thoroughly test the merged code to ensure functionality is not compromised.

Here are the top 25 Git commands that are commonly asked about in interviews:

  1. git init

    • Initializes a new Git repository.
  2. git clone <repository URL>

    • Clones a repository from a remote server to your local machine.
  3. git add <file(s)>

    • Adds file(s) to the staging area for the next commit.
  4. git commit -m "<commit message>"

    • Records changes to the repository with a commit message.
  5. git status

    • Displays the state of the working directory and staging area.
  6. git diff

    • Shows the differences between the working directory, staging area, and the last commit.
  7. git log

    • Displays the commit history.
  8. git branch

    • Lists all local branches in the repository.
  9. git branch <branch-name>

    • Creates a new branch.
  10. git checkout <branch-name>

    • Switches to the specified branch.
  11. git checkout -b <branch-name>

    • Creates a new branch and switches to it.
  12. git merge <branch-name>

    • Integrates changes from another branch into the current branch.
  13. git remote

    • Lists remote repositories.
  14. git remote -v

    • Lists remote repositories with URL details.
  15. git push <remote> <branch>

    • Pushes the specified branch to a remote repository.
  16. git pull <remote> <branch>

    • Fetches and integrates changes from a remote repository.
  17. git fetch

    • Downloads objects and refs from a remote repository without integrating.
  18. git reset <file>

    • Unstages the file, but preserves its changes locally.
  19. git reset --hard HEAD

    • Resets the working directory to match the last commit.
  20. git revert <commit>

    • Reverts a commit by creating a new commit with the inverse changes.
  21. git stash

    • Temporarily stores modified tracked files.
  22. git stash apply

    • Applies the most recently stashed changes.
  23. git tag

    • Lists tags in the repository.
  24. git tag <tag-name>

    • Creates a lightweight tag at the current commit.
  25. git remote add <remote-name> <repository URL>

    • Adds a new remote repository.

Comments