How is version control handled in Git?

01 Tem 14:30

Git’s version control works by saving each change as a "commit" and progressing through independent branches. Changes you make locally are first committed via the staging area (index) before being pushed to a remote repository (e.g., GitHub) with `git push`. To pull changes from the remote, I use `git pull` or `git fetch` + `git merge`, which automatically or manually merges the commit history. For branching, I create a new branch with `git branch` and switch to it using `git checkout <branch>`. To bring changes back to the main branch (main/master), I use `git merge` or `git rebase`—merge is simpler, while rebase keeps history clean but requires caution. My advice? Start using branches even for small projects—it makes rolling back mistakes much easier!

01 Tem 15:06

Last year, while working on a team software project, I used to manually copy everything into folders and name them things like "backup_2" or "final_version," but I kept losing things along the way. One of my teammates said, "There’s this thing called Git—you should try it." At first, I was all in—I created a repo, made commits, everything seemed great, but then I got lost in the branches. Dealing with conflicts, especially when using commands like `git checkout` and `git merge`, wasn’t exactly fun. Eventually, I figured out the branching logic: the main branch (main/master) is where the unbroken, working code lives. If you’re adding a new feature, you create a new branch with `git checkout -b new_feature`, experiment there, and make commits. Once you’re done with the feature, you switch back to the main branch and merge the changes with `git merge new_feature`. If conflicts pop up, you just manually fix the files and then commit. Long story short, thanks to Git’s version control, I no longer lose my code, can track changes easily, and stay in sync with my team without a hitch.

01 Tem 16:54

Git’s version control works by tracking every change made in the source code over time. While other systems (like SVN, a centralized version control tool) store the current state of files on a server, Git gives each developer a *local repository* on their own machine that contains the entire history (past commits, branches, etc.). This is a huge advantage—you can keep working on changes, revert mistakes, or even work offline without needing a connection. To send changes to a remote repository, you use `git push`, and to fetch updates, you use `git pull` or `git fetch`. `git push` sends your local branch’s commits to the remote, while `git pull` or `git fetch` + `git merge` brings in changes from the remote and merges them into your local repository. Branching and merging are at the heart of Git. In other systems (like Perforce or older CVS), branches are rarely used, but in Git, creating a new branch is cheap and instant. A branch splits off from a specific point in the project, creating an independent line of development—perfect for experimenting with new features, fixing bugs, or testing different ideas. Merging combines two branches, integrating changes back into the main line. The difference between Git’s `merge` and `rebase` commands is important: `merge` creates a merge commit, while `rebase` rewrites the branch linearly to keep history clean. In most projects, work happens in "feature branches," and once the code is reviewed and tested, it’s merged back into the main branch (usually `main` or `master`). This system significantly boosts efficiency for both individual developers and teams.