# Basic Git & GitHub for DevOps Engineers Contents: 1. What is Git? 2. What is GitHub? 3. What is Version Control? How many types of VC? 4. Distributed Version Control Vs Centralized Control Version 5. Git cheat sheet **What is Git?** Git is like a super-smart photo album for computer programmers. Imagine you're drawing a huge picture or writing a story, and every time you make a change, you take a snapshot and put it in your album. Git does something similar with computer code. When programmers make changes to their code, Git helps them save each set of changes as a snapshot. This way, they can look back at previous versions of their work anytime they need to. It lets many people work on the same project from different places. Each person can take their own snapshots of the project, and then Git helps blend all those changes together smoothly. This makes building software faster and lets teams collaborate without getting in each other's way. **What is GitHub?** In simple words, GitHub is an online platform where programmers store their projects, work together, and share their creations with a big community of other programmers. When someone uses Git (the super-smart photo album for code) to keep track of their coding project, they can put their project on GitHub. This lets other people see their work, suggest changes, or even add to the project from anywhere in the world. It's like having a shared Lego table where everyone can see your creation and help make it better. **What is Version Control? How many types of VC?** Version control is like a time-travelling magic wand for coders. It helps keep track of changes in your code over time without messing up your original draft, letting you rewind, fast-forward, and collaborate seamlessly. 1. **Local Version Control Systems**: These systems keep track of file changes in a simple database on the same computer where the files are located. It's a straightforward approach, allowing a single user to track their file changes over time. One example is the Revision Control System (RCS). 2. **Centralized Version Control Systems (CVCS)**: With CVCS, there's a single central server that stores all the versioned files, and a number of clients check out files from that central place. This setup facilitates collaboration among team members by allowing everyone to see what others are working on. It also helps in managing permissions and roles. However, the central server represents a single point of failure. If the server goes down or the data is lost, the history could be gone unless backups are in place. Subversion (SVN) and Perforce are examples of centralized VCS. 3. **Distributed Version Control Systems (DVCS)**: In this system, clients fully mirror the repository, including its full history, so if any server dies, any of the client repositories can be copied back to the server to restore it. Every clone is a full backup of all the data. It allows for more flexible workflows and more robustness against data loss. Git and Mercurial are examples of distributed VCS. Distributed Version Control Systems (DVCS) and Centralized Version Control Systems (CVCS) are two types of version control systems that are used to manage changes to source code or other collections of files and directories. Here are some key benefits of DVCS over CVCS: 1. **Full Local Copies of Repository**: * **DVCS**: Each user has a full copy of the repository, including its history, on their local machine. This allows for operations like commits, branches, and history viewing without requiring network access. * **CVCS**: Users only have a single version of the project on their local machines. Most operations require connectivity to the central server. 2. **Enhanced Collaboration and Branching**: * **DVCS**: Branching and merging are easier and more efficient, encouraging workflows that leverage these features for feature development and experimentation. This can lead to more innovative and safer coding practices. * **CVCS**: Branching is supported but can be more cumbersome and resource-intensive, often discouraging frequent use. 3. **Robustness and Redundancy**: * **DVCS**: Because every user has a full repository copy, the loss of a server or central repository does not risk the project's history. Any client repository can be used to restore the server. * **CVCS**: The central server is a single point of failure. If the server's repository is lost and there are no backups, the project's history could be lost. 4. **Flexible Workflow**: * **DVCS**: Supports more flexible workflows. Users can work independently and only share changes when necessary. This is ideal for open-source projects or projects with remote teams. * **CVCS**: Typically requires a more linear workflow with all changes flowing through the central server. This can introduce bottlenecks. 5. **Performance**: * **DVCS**: Operations like committing, branching, and viewing history are performed locally, offering faster performance for those actions compared to CVCS. * **CVCS**: Operations that alter history require communication with the central server, which can be slower, especially for large projects or when the server is under heavy load. 6. **Offline Accessibility**: * **DVCS**: Users can commit changes, create branches, and perform other repository actions even when offline since they have a full repository copy. * **CVCS**: Limited to no functionality when offline since actions typically require communication with the central server. ### **Git Commands Cheatsheet** 1. **git init** To initialize an empty git repository .git 2. **git status** To check what changes have been made 3. **git add filename/git add .** To maintain the changes made, to keep it in the project history 4. **git diff** Tells what are exact changes made 5. **git commit -m "message"** To commit changes made 6. **git restore --staged filename** To remove saved changes without committing them 7. **git log** To check history 8. **git reset --hard commit\_id** To go back to the previous version 9. **git stash** To stash an item(To keep in temporary storage) 10. **git stash list** To see the stashed items list 11. **git stash pop** To get changes previously made 12. **git stash clear** To clear the stashed items 13. **git clone <url of git repo>** To clone the repository from GitHub to the local machine 14. **git pull origin <branch>** To fetch changes from the specified branch on the remote repository and merge them into your current local branch. 15. **git push origin <branch>** To push local commits to a remote branch on GitHub 16. **git tag -a <tagname> -m <message> <commit\_id>** To apply tag 17. **git tag** To see the list of tags 18. **git show <tagname>** To see particular commit content by using the tag 19. **git tag -d <tagname>** To delete a tag 20. **git branch** To list all branches in the repository 21. **git checkout <branch>** To switch to a different branch 22. **git merge <branch>** To merge changes from a specific branch into the current branch 23. **git log --oneline** Displays a condensed history of commits, showing each commit as a single line with a shortened commit hash and commit message.