What is Git? What is GitHub? Version Control Explained Simply
A comprehensive introduction to version control using Git and GitHub, emphasizing their importance in modern software development and academic research.
The collection explains that while Git manages local snapshots of code to prevent data loss, GitHub acts as a cloud-based host that facilitates collaboration and public sharing. Key technical workflows are detailed, including forking repositories for independent experimentation, keeping projects synchronized with upstream sources, and using pull requests to propose changes. Beyond basic commands like commit and push, the text highlights the necessity of sharing code for reproduction and reuse in scientific fields to ensure transparency. Ultimately, the materials advocate for manual version control as a superior alternative to disorganized file naming for tracking long-term progress.
Version Control is a method used to save multiple versions of a file or project for future reference, allowing you to track changes, see who made them, and revert to previous states if needed. Without it, developers often resort to manual, error-prone methods like renaming files (e.g., "final_v2.js"), which is ineffective for teams.
Git vs. GitHub: What’s the Difference?
It is a common misconception that Git and GitHub are the same, but they serve different purposes
- Git is the software tool itself. It is a distributed version control system created by Linus Torvalds in 2005 that runs locally on your computer. It allows you to take "snapshots" of your work line-by-line without needing an internet connection.
- GitHub is a cloud-based hosting service built for Git repositories. It acts as a "social network" for developers, providing a web interface where they can store their code online, collaborate with others, and use extra features like issue tracking and pull requests.
| Feature | Git | GitHub |
|---|---|---|
| Type | Local Software | Cloud-based Website |
| Internet | Works offline | Requires an internet connection |
| Primary Use | Tracks code changes | Hosting and collaboration |
| Ownership | Open-source community | Owned by Microsoft |
How Git Works: The Three-Stage Workflow
In Git, your files exist in one of three primary states, which determine where they are located in the workflow:
- Working Directory (Modified State): This is the local folder on your computer where you are actively editing files. Changes here are not yet recorded by Git.
- Staging Area/Index (Staged State): This is a preparation space. You selectively "stage" modified files that you want to include in your next save point.
- Git Directory/Repository (Committed State): This is where Git stores the permanent records and snapshots of your project. Once you "commit" changes here, they become part of the project's history.
The Basic Workflow:
- Modify files in your working directory.
- Stage those files using the git add command to move them to the staging area.
- Commit the staged files with git commit -m "message", which saves a permanent snapshot to your local Git directory.
- Push those local commits to a remote platform like GitHub using git push so others can see them.
Key Collaboration Concepts
- Repositories (Repos): A folder tracked by Git containing all project data and metadata.
- Branching: This allows you to create a separate line of development to test new ideas or fix bugs without breaking the main, working code.
- Merging: The process of integrating changes from one branch back into another (like merging a feature branch into the "main" branch).
- Pull Requests (PRs): A proposal on GitHub to merge changes from one branch to another, allowing teammates to review and discuss the code before it is integrated.
- Forks: A copy of someone else's repository in your own GitHub account, enabling you to experiment or contribute to open-source projects without affecting the original.
Comments
Post a Comment