Programmers - teach me about version control

In My Humble Opinion
1

Hi folks.

I’m in the process of teaching myself to program, using Python. This isn’t for any career reasons, but just for my own pleasure. I’m somewhere between “hello world” and writing useful programs.

Most of my coding is done using Cloud 9, which is a cloud-based IDE and hosted Linux environment. This works well, because I find myself using different computers, and I can access and run my programs from any internet-connected PC. My main portable computer is a Chromebook, so a cloudy IDE is a good fit.

Anyway, I find myself editing a file, running it, changing it and then forgetting how to put it back the way it was - so I end up with lots of incrementally saved files - version 1, version 2 etc. And it occurs to me that this is exactly the sort of thing git and the like are supposed to address. The problem is, I seem to have a git-shaped hole in my brain. I’ve read various tutorials online and it never seems to stick. There are folders, commits, pull requests… It might not help that I don’t come from a command-line background, but it all seems a bit impenetrable.

So, some questions:

  • is it worth pursuing version control for a hobbyist programmer?
  • is one VCS platform better than the others? Git is the one I read about most
  • anyone know of an idiot proof guide which doesn’t assume much in the way of prior knowledge?
  • where does GitHub fit into all this?

Thanks,
Rich

2

Version control is hard for most people to get their minds wrapped around so don’t feel dumb for not getting it at first. It’s not until you collaborate on a large team of programmers that you start to fully understand why a lot of the features are the way they are. For a single programmer, the cost/value of version control is pretty neutral. pretty much the only thing that’s useful is the ability to commit and browse through past commits. But as a team scales, VCS becomes the primary communication tool through which programmers collaborate and things like bundling discrete changes, writing good commit messages and knowing when to branch/merge become much more important.

Personally, I’ve found the best way to ease into it is to get an account on Github and use the Github app. If you intend to be a single hobbyist programmer the rest of your life, then just use VC as a fancier alternative to renaming folders every so often. If you want to learn it for the sake of learning it, then it’s good to do it now as building in good habits from the very start help you later if you ever want to play well with others.

3

It is mandatory for anyone writing anything more complex than Hello World.

They all have different advantages and disadvantages. But everything is better than CVS. Git is very popular in the open-source world right now, and is what I use the most.

Git has some nice videos explaining some of the conceptual ideas. But if you want to learn it you just have to start setting up repositories and making commits. You’ll start to learn the commands and get the concepts as you go along. Keep in mind that git is a very powerful tool, but like most such things, 90% of the time you only need 10% of what it can do. It’s perfectly fine to use that 10% and only figure out the odd cases when you need them.

GitHub is a service for storing git repositories on the interwebs. If you make your repositories public, it’s free. It’s a very convenient way to collaborate on projects because tons of other people are on GitHub, and they provide some very nice GUI-based tools for doing certain operations, like diffs and merging. (“Pull requests” are a GitHub concept.)

Even if you’re not collaborating on anything, GitHub can be useful to store your repositories so you can work on the same project from multiple locations, by syncing all your changes up to GitHub. It’s also useful if you run into problems because you can give people a link to your code and ask for help.

4

+1 to friedo. Get a free GitHub account, and store your projects there.

5

Thanks all, some good advice there. Looking forward to watching those git videos.

I’m off to explore GitHub :slight_smile:

6

I’m a programmer and also come from a command line background. Do look into version control, though I don’t use it. In my job (County Gov) I’m the only one working on my projects. I should still use version control but I don’t (I do back things up constantly) And will be following this thread.

In the mean time, a suggestion to the OP. Comments are very useful. AND, don’t change working code in a program, just comment the existing code out and replace it with what you are testing. You can always jump back to the previous ‘version’ by un-commenting the working code.

7

Store your projects in a Dropbox folder. It will keep a change history of each file and allow you to restore them to any point. Sort of a lazy man’s version control.

8

That’s interesting. I work in Visual Studio, and it has version control options. Admittedly I need to look into that. I am in maintenance mode right now, with a few bells and whistles added every few months.

Version control is very important when multiple people work on the same code.

I was mostly addressing the OP’s concerns when trying to get beyond ‘Hello World’. Comment out/Copy/Paste/modify is a poor mans ‘version’ control that the OP may not have considered.

9

Version control is great fun - it can save your ass from going in very strange directions and give you way back. Team work needs it; I used CMVC at IBM (no, don’t use CMVC even if you could find it). It takes a while to get used to but isn’t too bad.

On a similar question: I have several students in my computer programming classes. Would GitHub be appropriate place for students to (easily) place files for me to examine and try to run? How about for teamwork? I don’t necessarily want the files to be available to everyone in the world though.

One reason this could be useful in programming classes is that we have lots of programs that scaffold on top of each other: do this in week 1, add this feature in week 2, now tweak it in week 3, etc. I’ve never considered version control as a method to distribute the requirements and review their updates. Is this practical?

10

I’m a single programmer for a couple of products in the Mac App Store, and version control is simply awesome. It’s not just about being able to go back and look at history (although that’s cool, too). It’s about being able to effortlessly branch out and try things without having to go through manual backup processes that are, well, version control, too.

I want to try to add a new feature to my application, I can


git checkout -b my_new_feature

. I can


git add

and


git commit

as I’m happy with my progress, or


git branch -D my_bad_branch

if I don’t like it. Oh? There’s a bug in master?


git checkout master

, fix it, push it to Apple, checkout my feature branch, merge in the master change, and keep working on my feature.

Because my repo is public, I can


git rebase -i shahash

to flatten it, checkout master, then merge my feature branch as a single set of changes.

Before Git I would zip the folder, name it, and work from there. It was acceptable at the time, that time being the time before I knew about Git. I won’t work without it now. It’s really an incredible, indispensable tool, even for a single programmer.

11

XKCD on git.

12

If you don’t want the repos to be public, you can set of an Organization which allows you to add the users you want, and members of the org can see the repos in it. You have to pay for that if the repos are private to the org, but it’s not expensive.

13

Consider subversion (svn) as well. I have to say I much much prefer git, but for your needs, which don’t involve collaboration with other people or merging (or even branching really by the sounds of it), subversion should provide you with everything you need and has a much shallower learning curve.

14

Last time I checked (not recently) Github didn’t allow private repos without paying. Bitbucket on the other hand does. (Limited to 5 I think)

15

Totally disagree. Version control is immensely useful for anyone (and not just programmers). There are certainly features that are only useful on teams, but it’s far from neutral even for a single user.

I never quite “got” Git; I personally use Perforce, which is an “industrial strength” version control system. It’s free for small numbers of users, and you can either run your own server (which I do) or use free-to-cheap hosted systems.

16

Unless/until you start writing programs which interact with other programs, version control is simple:
The first one that runs gets the number 001 and date appended to it.
myfirstprogram001051118

When you want to tweak it, you open it and then save it as myfirstprogram.

This way, the most obvious name is the one you will be tweaking and saving.

Once it gets running to your satisfaction, it gets the 002110617 name.

So: immediately after creating the numbered version, you have two copies of exactly the same program.
One you play with, one you don’t.

Keep all versions in the same folder. Eventually, you will decide that 001 and 002 are ancient enough to delete.

For large systems, you get into configuration management.
You can worry about that when you are getting paid to code.

17

userid.SOURCE.COBOL

userid.SAVE.COBOL

Worked for me for 30 years.

18

Subversion is actually far worse for a beginner working alone, because it requires an HTTP server and (if not running locally) a network connection just to set up a repository and make a commit.

Git requires none of that, and works with zero setup.

19

Or you could worry about doing things the non-stupid way from the beginning, instead of spending 30 years maintaining a shitheap of COBOL files.

20

WOW! Why don’t you jump back to 1980 and explain all your wonderful thoughts on version control to the folks who created the systems back then!

Hint: the Configuration Management people were NOT the sames as the coders.

And the real software was on drives (in banks, on separate machines (now known as “air gaped”)) which the coders couldn’t touch.

And let me know how you folks handle what we did with GDG’s (Generation Data Groups*)

    • IBM called files “data groups”

p.s. - most coders did not use any backup. We took the production, made the required modifications, and put it back. We didn’t have any reason to create our own individual “version controls”.