Why use Git for individual development?

Well, I'm going to tell you a bit about what convinces me that Git certainly came to be among the best (if not the best) versioning forms - and this included individual development.

You probably already read about the advantages of Git, its history, and so on. If this still has not convinced you, I'll remind you of some interesting things:

• Feature branching - While this is more of a versioning technique than something else in Git, it's incredibly easy to do this in Git! Developing solo sometimes can lead us to waste a lot of time on something not very useful ... while we are developing something comes up an incredible idea, easier .. just because it is in the middle of another ends up leaving it for later It may be something that happens to me only, but it is much easier to branch to a new feature and continue developing in another branch when another idea comes up!
  / li>

• Speed - You can not compare the speed of Git. It's extremely fast! Please do not tell me that you use Tortoise on Windows! It's incredibly simple, but I do not know a computer with Windows and Tortoise that makes me happy when I click the right mouse button. Let's be practical .. this is annoying indeed. What's more, the project may be small, but try to start doing file comparisons between branches ... or worse, try to find a specific string in version history ! This is very painful ... Comparisons between whole versions in Git is pretty cool too!

• History - I do not know the way you configure your SVN, but having all the local history is amazing! Duplicating this history in a quick, simple (one command) and with all well compressed files is also pretty incredible. This saves you from a lot of headaches when you need to look at a history and your server is not available.

• Size of the base - Storing a repository in Git is fine. I do not even need to describe it. For those going back and forth all the time too, or have many binaries (I have) inside some library (I'm kind of warned, I have all my dependencies on committees), that's very important! Because Git works with hashes and different file and history versioning lines, you can have duplicates of files as much as you want the repository will not grow. And it keeps history quietly in these files.

• Github - No comments. It is great for individual projects. It has visual tools for Windows and other intuitive platforms.

• Easy - Can you discard all repository changes with 1 command .. will it make a drastic change and just want to try? Duplicate the repository with 1 command and without a server. Make local commits and then send everything to a server with 2 commands.

• Gitk - Blame - This saves jobs. No more comments. I know this exists in SVN / CVS (it's called annotate ). But I think Git's much easier to use and faster.

I have already listed some of them, maybe someone could add others. There are a lot of people with fear of Git because it does not have anything too visual ... let's say the following, programming is something for professionals. Why not invest a little in understanding and using Git?

Git does have a few more things that require more time to learn. I always found SVN / CVS too simple ... They are good for protection (they seem like a shared network folder. At dawn someone goes there and makes a copy .. not everyone likes it, but that's my feeling working with CVS / SVN). Nothing better than starting at home! As soon as some difficulties arise (and memorize one or the other command) it will be as simple as using something visual ... some commands on the terminal can be a lot of time looking at SVN / CVS versions.

Rodrigo's answer brings several advantages of Git, so my answer goes more as a complement, trying to cover some other points.

I understand that Git ends up being the default option even for individual projects for a few reasons:

• Experience . Probably the developer has already worked on a project that uses Git. And if you have not worked, certainly worth learning because this knowledge will certainly be used in your professional career when participating in new projects or working in other companies. The same can not be said of other versioners.

• The "stash" . It is very simple to save for later that code that you (you think) will need later using the command git stash and return with it all with git stash pop . I do not know if other versioners have something similar, but it's a very useful feature.

• Staging Area : If you are a person who likes very well organized things, you can use the Staging Area Git to separate in different commits the various changes made in the code, without worrying about whether another developer is finding it too exaggerated: )

There are two more points that I will explain below: Easy to create a repository and Understanding facility .

About the ease of creating a repository , for me there is nothing simpler than getting into the root directory of your solo project and doing:

git init

And immediately have a completely functional Git repository for your solo project, and you can take advantage of all the tools that Git offers.

Now imagine the scenario of a developer who has never seen Git in his life.

Normally many end up thinking SVN as an alternative. But perhaps putting an SVN repository to work is not as simple as simply learning how to use Git.

That said, let's face it:

  

Objectively, what is really decisive in choosing to switch SVN from Git in an individual development scenario? Which killer feature can set this choice? Remember that some of the advantages of Git do not apply to this scenario.

For the reasons I explained above, it may be more difficult to put an SVN to work than simply create a local repository and learn Git. And if you already know Git, I see no advantage in using SVN in most scenarios.

  

Is there an advantage in this? Am I going to miss anything significant with the exchange?

Now, finally, I'll explain what I said about Git's ease of understanding . Maybe the Git commands are not very friendly, but their inner workings are much clearer (at least for me).

My experience with SVN is old (mid-2011). At the time I was able to understand much better how Git worked than how SVN worked, and this in a very short interval of time. With Git you can simply think of your repository as a great graph, which makes it easy to understand various repository scenarios in a visual way.

I'll give you an example of how SVN can be confusing and, in advance, I beg your pardon for not giving more details because it has been a long time since this happened to me.

In SVN, sometimes we needed to take individual revisions of a branch from any task and move on to another branch of release . After that, we would merge the task branch into the release branch and SVN simply ignored in the merge all job revisions prior to that individual revision. I know this is a merge behavior, but the fact that SVN allows selecting a range of revisions (or revisions individually) in this merge process left the situation quite confusing. / p>

When I finally came to understand how Git was simpler in this scenario, using cherry-pick , and making clear the difference between it and merge or rebase , I passed to sympathize with the tool:).

It is also worth noting that unlike CVS and SVN, which are centralized versioning systems, Git is a distributed versioning system and this gives it the following advantages:

• faster because commits, diff, and log operations are executed locally;

• Reduced processing cost because processing is distributed on the developers own machine;

• Reliability increases as there is a more or less up-to-date backup on each developer's machine, which in the case of crash-centric disrupts all development.

A non-mandatory addendum is the workflow, which I find very interesting, which is GitFlow, well described in:

  

link