Bifalgorithm post
Let's do a Git crash course. And no, Git and GitHub are not the same thing. Git is a version control system. GitHub is a website that can host Git repositories. Now let's say you create a new project. You run git init. That turns the folder into a Git repository. Git now starts tracking the history of that project. But Git doesn't automatically save every change you make. There are basically three important areas you need to understand. Your working directory, the staging area, and the repository. Let's say you edit app.js. That change exists only in your working directory. If you run git status, Git will show you that the file has changed. Now you run git add app.js. That moves the change into the staging area. Think of staging as, these are the exact changes I want in my next snapshot. Then you run git commit dash m add login page. Git creates a commit. A commit is basically a saved snapshot of your project at that moment. And every commit gets its own unique identifier. Now imagine you want to build a new feature without messing up your main code. That's where branches come in. You can create one with git switch, mine's key new feature. Now you have a separate line of development. You make changes, add them, commit them. Meanwhile, the main branch stays untouched. Once the feature is ready, you can switch back. Git switch main and merge the branch. Git merge new feature. Git tries to combine both histories automatically. But sometimes two branches modify the same part of the same file. Git doesn't know which version you want. That's a merge conflict. Git marks the conflicting sections. You choose what the final code should look like and then commit the result. Now let's add GitHub. You create a repository online and connect it to your local repo using something called a remote. Usually that remote is called origin. When you run git push, your local commits are uploaded to the remote repository. When you run git pull, git downloads new changes from the remote and integrates them into your branch. And git clone, that simply downloads an existing repository and it's git history onto your machine. Now here's one command that saves people constantly. Git log. It shows the history of commits and if you break something, git gives you several ways to go backwards. Git restore can discard changes in files. Git revert creates a new commit that undoes an older commit. And git reset can move your branch pointer backwards, which is powerful but also much easier to misuse. So if you only remember the basic workflow, remember this. Edit your files, git add, git commit, git push. And when working with other people, git pull before you start pushing new work. Git sounds complicated because it has hundreds of commands. But 90% of the time, you're really doing one thing. Creating a clean history of how your code changed over time.
Let's do a Git crash course. And no, Git and GitHub are not the same thing. Git is a version control system. GitHub is a website that can host Git repositories…
Ideas in this flowchart
- Git Crash Course
- Git vs GitHub
- Git
- GitHub
- Git Basics
- Create New Project
- git init
- Tracking Changes
- Working Directory
- Staging Area
- Repository
- Edit app.js
- git status
- git add app.js
- git commit
- Commit
- Branches
- Create Branch
- git switch
- Merge Branch
- git merge
- Merge Conflict
- Resolve Conflict
- GitHub Integration
- Create Remote Repository
- git push
- git pull
- git clone
- Git Commands
- git log
- git restore
- git revert
- git reset
- Basic Workflow
- Edit Files
- git add
- Collaborative Workflow