Why use Git for individual development?

Asked

Viewed 2,113 times

36

In 2008 I asked an OS question about version control for solo developer and received an excellent response from Jon Skeet indicating the use of SVN. Unfortunately it was recently closed and removed.

Today Git is becoming ubiquitous. This alone brings some advantages. If you use some projects open source third party is probably already at least Git client.

I see Git as something complex for those who need version control simply. But I admit there are some advantages too.

Objectively, what is really determining for choosing to trade SVN for Git in an individual development scenario? Which killer feature can define this choice? Remember that some of the advantages of Git do not apply to this scenario.

Is there an advantage to this? I will lose something significant with the exchange?

  • Put the link anyway. Anyone with enough reputation there can see the original question. Put Jon Skeet’s answer too.

  • @Victor, it’s been removed anyway, it’s 404, and it’s not on my profile. He stayed there for years without disturbing anyone with multiple votes, and suddenly, someone decided it didn’t fit. I didn’t even know why it was closed and why it was removed definitively so fast. There was nothing wrong in the question.

  • 3

    I am an extremely disorganized person, I always end up making a lot of copies of the folders of my projects (for backup, to test in other environments, etc). A decentralized version control system (like Git, although I use Mercurial) breaks a gallon in this case - mainly because I don’t always have the "official repository" on the same network from where I make the copies. A system with a centralized server would not bring me much benefit, whereas a decentralized one allows me to merge changes from one environment to another without becoming a mess...

  • 1

    The funny thing is that such a subjective question was: http://stackoverflow.com/questions/138621/best-version-controlfor-lone-developer

  • I know Git fairly well, so much so that I even answered here: http://answall.com/a/43894/101

  • Sometimes git is even easier to use alone. For example, it can be all in . git, it is not required to create a separate repository (such as "server"), and undo actions (including commits) is considered a normal part of the workflow and well documented (not impossible with other tools).

  • I use GIT programming by myself. I only know the right-to-right and I’m ashamed to say I don’t know how to work in a group with it. Hell, sometimes I curl up with myself (denied fast-forwards). All the tutorials I meet focus more on the technical part, on diagrams of what is happening behind the scenes, but forget that some people have difficulty interpreting this kind of thing. Too bad it is not the scope of the topic because it would be a very interesting topic to be in KB.

Show 2 more comments

3 answers

27

Well, I’m going to tell you a little bit about what convinces me that Git has definitely come to be among the best (if not the best) forms of versioning - and that includes individual development.

You’ve probably read about the advantages of Git, its history etc. If this hasn’t convinced you yet, I’ll remind you of some interesting things:

  • Feature branching - Although this is more of a versioning technique than something in Git itself, it’s incredibly easy to do that in Git! Develop soil sometimes it can lead us to waste a lot of time on something not very useful... while we are developing something comes up an amazing idea, easier.. It’s just that since you’re in the middle of another, you’re gonna have to save it for later. It may be something that happens only to me, but it’s much easier to branch to a new one Feature and continue developing in another branch when another idea arises!

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

  • Historic - I don’t know how you set up your SVN, but having all the local history is amazing! Duplicate this history in a quick, simple way (a command) and with all well compressed files is also pretty amazing. This saves you a lot of heartache when you need to look at a history and your server is not available.

  • Base size - Storing a repository in Git is great. I don’t think I need to describe it. For those who go back and forth from version all the time too, or have many binaries (I have) within some library (I’m kind of forewarned, I have all my dependencies committed), that’s very important! How Git works with hashes and different lines of file versioning and history, you can have file duplicates as much as you want that the repository will not grow. And he keeps the history quiet in these files.

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

  • Ease - You can discard all repository changes with 1 command.. will make a drastic change and just want to try? Duplicate the repository with 1 command and without a server. Do commits places and then send everything to a server with 2 commands.

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

I have already listed some maybe someone could add others. There are many people with fear of Git because it has nothing very 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 extra time to learn. I’ve always found SVN/CVS to be too simple... They’re good for protection (they look like a shared network folder. At dawn someone goes in and makes a copy.. not everyone likes that, 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 another command) will be so simple when using something visual... some commands in the terminal can amount to a lot of time looking at versions in SVN/CVS.

  • The answer is interesting but the focus of the question is for the solo developer. Try to meet this point more.

  • @bigown I think this was the focus of my response highlighting only Features that I believe are interesting when developing solo. As already said, speed, base size and Feature branching in git are very interesting.

  • Why "no comments" for Github?

  • @rodrigogq got it. I couldn’t see it like this, I’m gonna reread.

  • @Renan I think that makes it clearer.

5

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

I understand that Git turns out to be the default option even for individual projects for some reasons:

  • Experiment. Probably the developer has worked on a project that uses Git. And if you didn’t work, it is 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 cannot be said of other versioners.

  • The "trunk" (stash). It is very simple to save for later that code you (think you) will need later using the command git stash and come back with it all git stash pop. I don’t know if other versioners have anything like it, but it’s a very useful resource.

  • Staging Area: if you are a person who likes things very well organized, you can use the Staging Area Git to separate into different commits the various changes made to the code, without worrying if another developer is finding an exaggeration :)

There are two more points, which I will explain further below: ease of creating a repository and ease of understanding.

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

git init

And immediately have, without setting up anything else, a fully functional Git repository for that solo project of yours, so you can take advantage of all the tools that Git offers.

Now, let’s imagine the scenario of a developer who’s never seen Git in his life.

Usually many people end up thinking about the SVN as an alternative. But maybe getting an SVN repository to work isn’t as simple as simply learning to use Git.

That said, let’s have doubts:

Objectively, what is really determining for choosing to trade SVN for Git in an individual development scenario? Which killer feature can define this choice? Remember that some of the advantages of Git do not apply to this scenario.

For the reasons I explained above, it can end up being more difficult to get an SVN to work than simply creating a local repository and learning Git. And if you’re familiar with Git, I don’t see the benefit of using SVN in most scenarios.

Is there an advantage to this? I will lose something significant with the exchange?

Now, finally, I’ll explain about what I said about ease of understanding Git. Maybe Git commands aren’t very friendly, but their internal 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 that in a very short time. With Git you can simply think of your repository as a large graph, which makes it easier to understand several repository scenarios in a visual way.

Let me give you an example of how SVN can be confusing and, in advance, I apologize for not bringing more details, because this happened to me a long time ago.

In SVN, sometimes we needed to take individual revisions from a branch of a task any and move to another branch of release. After that, we would merge the task in the branch of release and the SVN simply ignored in the merge all revisions of the task prior to that individual revision. I know this is a behavior of merge, but the fact that SVN allows you to select a crease of revisions (or revisions individually) in this merge process left the situation very confused.

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

3

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

  • less processing is required, since every commit is not required to interact with a central server, in teams with many developers this is a very important factor;

  • faster than operations like commit, diff and log are executed locally;

  • has greater autonomy because all operations can be executed locally and it is necessary to use the network only to exchange revisions with the remote repository (example push of what has already been completed, pull new revisions);

  • reduced processing cost as the processing is distributed on the developers' own machine;

  • reliability increases because there is a more or less up-to-date backup on each developer’s machine, which in the case of the centralized in case of crash stops all development.

A non-compulsory addition is the workflow, which I find very interesting, which is Gitflow, well described in:

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

Browser other questions tagged

You are not signed in. Login or sign up in order to post.