# Ultimate GitHub Guide : devops-3 ### Git Lifecycle Working directory → Staging Area → Git directory 1. **Untracked** * A file that has been created in the working directory but **has not yet been added** to the Git repository. * Git doesn’t track changes to this file because it hasn’t been added to the repository. * **Example**: You create a new file, `file.txt`, in your project folder. Until you add it with `git add`, it remains untracked. 2. **Tracked Files (Unmodified)** * A file that has been **added to the repository** and is now being tracked by Git. However, **no changes** have been made to this file since the last commit, so Git doesn’t consider it “modified.” * **Example**: If `file.txt` has been added to Git using `git add`, and there haven’t been any changes to it since, it will be in the "unmodified" state. 3. **Modified** * A file that was being tracked by Git but has since been **changed**. Git sees that the content of the file is different from the last commit, but the changes have **not yet been staged**. * **Example**: You modify `file.txt`, which was already added to Git. Git knows it has been changed, but the changes are not yet ready to be committed. 4. **Staged (Index)** * A file that has been modified and is now **staged for commit**. Staging a file means you’re telling Git, “I want to include these changes in the next commit.” The staging area (index) is where Git collects files that are marked for committing. * **Example**: You use `git add file.txt` to stage the modified file. It is now ready to be committed. 5. **Committed** * After a file is staged, it can be **committed** to the repository. A commit is a snapshot of your staged changes. Once a file is committed, the changes are stored permanently in the Git history, and the working directory returns to the **Unmodified** state. * **Example**: When you commit `file.txt`, Git saves this version of the file in the repository history. ### Content of .git folder **→** `.git` **folder is created at the time of initiating git repository by** `git init` . 1. `branches` Legacy directory for branch storage (now unused). 2. `config` Stores configuration settings specific to the repository. 3. `description` Stores a short description of the repository (used by GitWeb). 4. `HEAD` A reference to the current branch or commit being worked on. 5. `hooks` Directory for Git hook scripts (e.g., pre-commit, post-commit). 6. `info` Contains additional information, such as ignored files specific to the repository. 7. `objects` Stores all the content and history of the repository as objects (blobs, trees, commits). 8. `refs` Contains references to commits for branches, tags, and remotes. ### Centralized Distributed Version Control System **1\. Centralized Version Control System (CVCS)** In a **Centralized Version Control System**, there is a **single central repository** that contains all the code and version history. Developers interact with this central server to commit and pull changes. * **Single central repository**: There is only one server where the entire project and its history are stored. * **Clients pull and commit to the central repository**: Developers (clients) must connect to the central server to get the latest version of the code and commit their changes. * **Requires network access**: Since the central server holds all the version history, developers need to have network access to interact with the repository (pull, commit, etc.). * ***Single point of failure*** : If the central server goes down, no one can commit changes, and developers may lose access to version history. * ***Limited offline work*** : Since the full history is stored on the server, you need network access to commit or view past versions. Offline development is limited. 2\. **Distributed Version Control System (DVCS)** In a **Distributed Version Control System**, every developer has a **complete copy** of the repository, including its entire history. The concept of a "central" server still exists, but it is not essential for working with the code. * **Each developer has a full copy of the repository**: Every developer has their own local version of the repository, including the entire commit history. * **No need for constant network access**: Developers can work locally, commit changes, and view version history without needing access to a central server. * **Push and pull between repositories**: Developers can share changes with each other by pushing and pulling to/from other repositories, often using a central repository for synchronization. * **Branching and merging are easier**: DVCSs are designed to make working with branches and merging changes much simpler and more efficient. * ***Larger local storage required***: Since every developer has a full copy of the repository, large projects may require more disk space on individual machines. **Summary:** * **Centralized Version Control Systems (CVCS)**, like Subversion (SVN), rely on a central server where the repository is stored and there are no concept of local repository. Developers work by pulling code from and pushing code to this central repository. It’s simpler to manage but can suffer from issues like a single point of failure. * **Distributed Version Control Systems (DVCS)**, like Git, give every developer a full copy of the repository. This allows them to work independently and offline, and later sync their changes with other developers. It's more resilient and offers better performance for large teams, but it has a steeper learning curve. ### What is branch ? Branch is a new/separate version of the repository from which the branch has created. ### Important git command **Basic Git Commands** 1. `git init` * Initializes a new Git repository in your project directory. 2. `git clone ` * Creates a copy of an existing repository from a remote server (e.g., GitHub, GitLab) to your local machine. 3. `git status` * Displays the current state of your working directory and staging area, showing which files are modified, staged, or untracked. 4. `git add ` * Adds the specified file to the staging area, preparing it for the next commit. 5. `git commit -m "message"` * Commits the staged changes with a descriptive message. 6. `git push ` * Uploads your local commits to a remote repository (e.g., pushing changes to GitHub). 7. `git pull` * Fetches and merges changes from a remote repository to your local branch. 8. `git fetch` * Retrieves the latest changes from a remote repository but does not merge them. 9. `git merge ` * Merges the specified branch into the current branch. 10. `git log` * Shows the commit history for the repository. --- **Branching and Tagging** 11. `git branch` * Lists all local branches in the repository or creates a new branch. 12. `git checkout ` * Switches to the specified branch or commit. 13. `git checkout -b ` * Creates and switches to a new branch. 14. `git tag ` * Creates a new tag (used for versioning, like marking a release). 15. `git branch -d ` * Deletes the specified branch (only works if the branch has been merged). --- **Staging, Stashing, and Resetting** 16. `git reset ` * Unstages the specified file but keeps the changes in the working directory. 17. `git reset --hard ` * Resets the working directory and staging area to the specified commit, discarding all changes. 18. `git stash` * Temporarily saves changes that are not ready to be committed, keeping the working directory clean. 19. `git stash pop` * Applies the stashed changes back to the working directory. --- **Remote Commands** 20. `git remote add ` * Adds a new remote repository with the given name and URL. * `git remote set-url ` : Use to change remote url. 21. `git remote -v` * Shows the list of remote repositories with their URLs. 22. `git push origin ` * Pushes the specified branch to the remote repository named `origin`. 23. `git fetch ` * Fetches changes from the specified remote without merging. --- **Inspecting and Comparing** 24. `git diff` * Shows the differences between your working directory and the staging area, or between commits. 25. `git diff ` * Shows the differences between your current branch and the specified branch. 26. `git blame ` * Shows which commit and author last modified each line of a file. 27. `git show ` * Displays detailed information about a specific commit (including changes made and commit metadata). --- **Undoing Changes** 28. `git revert ` * Creates a new commit that undoes the changes from a previous commit without altering the commit history. 29. `git reset HEAD~` * Moves the HEAD pointer back `n` commits, allowing you to undo recent commits. 30. `git checkout -- ` * Discards changes in a specific file in the working directory, resetting it to the last commit. --- **Collaboration and Advanced Commands** 31. `git rebase ` * Reapplies commits from one branch on top of another, changing the commit history. 32. `git cherry-pick ` * Applies the changes from a specific commit onto the current branch. 33. `git log --oneline --graph` * Shows a condensed, visual representation of the commit history, with a graph of branch and merge activity. 34. `git config --global user.name "Name"` * Configures the username for Git commits (globally or per repository). 35. `git config --global user.email "`[`email@example.com`](mailto:email@example.com)`"` * Configures the email address for Git commits. --- **Git Cleanup Commands** 36. `git gc` * Runs Git’s garbage collector to clean up unnecessary files and optimize the local repository. 37. `git clean -f` * Removes untracked files from the working directory.