This blog will focus on git and the basics of how it functions. There is sooo much information on the internet about git and how to get things done with git. So to that end, I would imagine a lot of developers and engineers might not take that much time to worry about the tediousness of git. I would, however, argue that it is important to understand what one is doing when using git because it is a powerful and expansive tool.
When I first started using git I had no idea what was going on. I immediately searched for an "easy" git tutorial. I quickly found out that while getting what you need done with git is not always too difficult, understanding what was happening was a different story. I tried to dive a little deeper and realized that the more I read the more I got confused. If you feel this way, I would advise to take a step back, concentrate on the basics of what to do and move forward one small step at a time.
First, what is git? How are git and Github different?
Git and Github are different things, but they do work together. Git is a version control system that helps one manage and work with code. Github is a storage system for git repositories. Ok so what does that mean?
First of all Github is just a storage area. It is a cloud based database where one can store their work or get other peoples work to make changes. These files are stored as "repos" or repositories. Repositories are essentially folders with files in them. Github makes what we have done with git a little more visually intuitive than working inside our git shell. It makes working on projects (especially when working with a team) much more collaborative and understandable. However everything that we add to Github is modified through Git's version control system.
Version control systems are ways to save, change and look over changes that one might make to a project. Git is not the only one, but it is widely used because of how powerful it is. Git does not require the internet. It is all locally based on your machine. Git is extremely powerful because of its branching model and the way that it stores data. Other VCS(version control systems) previous to Git would save changes made to filesystems as a whole. In other words, any time a change was made the whole filesystem would be re saved.
Git does not do this. Whenever one makes a committed change to a project git will take a "snapshot" and if certain files have not been changed, they will not be stored. If they have been changed, they will be. The snapshot however will be recorded as a link of sorts to the previous file. This makes git much more efficient and faster than other VCS. Git will only save and store data that has been modified specifically.
Git is also very powerful because of its branching system. Git branches can be quite complex, but they are very useful. When working with branches, we have to remember that git make "snapshots" of files when changes are made. Whenever one is working with files and making commits they are on a branch. Unless one has switched branches they would be on the master branch. Think of this "branch" as a series of points. Each of these points will be the stages of files that have been modified and saved. When one makes a change, only the things that are changed will be changed but there will always be a reference to previous changes.
When we make another branch we make a point with where we are at on our new branch with a reference to our current commit. To check what branch we are on we can use the command 'git branch'. The command 'git checkout (branch name)' will switch us to whichever branch we want to be on. To create a new branch we use the command 'git checkout -b (branch name)' which will also switch us automatically to this new branch.
When we make a new branch and make a committed change, we will move up the branch past the master. What makes this interesting is that we can change branches, make changes and then move back to the master branch on a previous commit and make other changes (or more branches). This way we can test multiple things without changing the integrity of the original master branch. When we decide what changes we want we can go ahead and merge them with the master branch.
I hope this has been informative in some way although it is very basic. I think that even this small amount of knowledge on how branches and git works can be useful in understanding what one is doing when making commits and changes to our projects. By knowing more about what we are actually doing rather than just typing out commands to get things done can help us when we inevitably run into merge conflicts or other such issues. Thanks for reading.
Top comments (1)
FYI on the other version software it was not the whole file system being saved but could have been the entire modified file. Branches where an entire file system copy, but I believe SVN eventually changed this in the backend storage (front end still operated as separate folders).
SVN was at one point even worse, in order to merge branches you would need to track the commit you branches from (the base) and specify it in the merge.
Git forced competition in how version control was done so tools such as SVN aren't as bad as when git started, today rewriting history is more acceptable and the trend I believe will keep git leading version management.