When to git?

November 11, 2015 7:35 AM

I write a lot of my own programs, and I want to start using version control (git) instead of creating lots of versions of things. I'm not sure, though, when to be doing git-type operations along the way.

I mostly work alone. I'm not clear at what point(s) along the way I should be adding files to the repository. For example, I primarily use Python, which requires me to save changes to a file every time I run it. Does this mean I need to "add" the file to the git repo every time I run the code in Python?

Do I just spend some time at the end of each day adding and committing things?

I want to get up and running and I understand the basics of how git works, I just don't know how to integrate it with the way I normally do things, which is something like:

1. write code
2. debug code
3. fix something
4. re-run it (repeat 3 and 4 as necessary)
5. do something big to it and name the file something else (and start again at #2)

posted by stinker to Computers & Internet (13 answers total)

I would say, for your use case, it probably makes sense to replace step 5 with a commit, and then just do a push every few commits (or even every commit, no real reason not to). That way each commit will give you a version in case you need to rollback or reference your old code.
posted by protocoach at 7:46 AM on November 11, 2015 [1 favorite]

Best answer: You don't need to to add and commit each time you save a file, but doing it at the end of the day isn't a great strategy either.

There's this SO question about it, but my general advice, especially as you're working alone, would be to commit when you'd normally do #5, or a little more often, say, on a medium sized #3 as well.
posted by zazerr at 7:47 AM on November 11, 2015

Best answer: Commit early, commit often. I'd strongly consider committing at the end of steps 1 and 3 in your scenario. The commit can just be "implemented x" or "fixed spelling error" or "refactoring y". Bigger is not better.
posted by It's Never Lurgi at 7:48 AM on November 11, 2015 [2 favorites]

it's a tool. it's meant to help you, not give you extra problems.

so, how can it help you?

it can help you find old version of the code when you want to go back to something interesting. it can help you recover files when a disk crashes. it can help you find old versions of the code when you realise you took a wrong turn.

so use it in a way that makes those things work for you. commit when you have some code that seems interesting. commit (and push to github) when you would be mad if the disk crashed and you lost all your work. commit before you make a big change that might turn out to be a dumb idea. and learn how to look back in the history, how to retrieve old versions, etc, so that you can do all these things.

again: it's supposed to help you. not impose arbitrary extra constraints.

more generally, this should be true of everything you do in software development. you don't have to follow arbitrary rules. instead, you understand how something can help you and then use it in a way that makes most sense to you. same with oop. same with unit tests.
posted by andrewcooke at 7:57 AM on November 11, 2015 [1 favorite]

Adding to the excellent answers above, definitely make sure you regularly push your changes to a remote server (like Github, Bitbucket, etc) or at least a different location from your working copy. Starting out just learning git I almost guarantee you'll do something that makes everything go haywire, and in many of those cases it will be easier to just blow away your working copy and pull down a new version from the remote repository.
posted by ndfine at 7:59 AM on November 11, 2015

if i *have to* rollback, here is a nice a place.
posted by j_curiouser at 8:16 AM on November 11, 2015

Basically I agree with It's Never Lurgi. I like to do a lot of "for now" commits, and then if I'm sure a "unit" of stuff is working I'll go back and squash a bunch of mini-commits together (using rebase --interactive). I'm generally working with other people, though - if I were on my own I'm not sure I'd bother with the squashing. But on the other hand, even if you're on your own if you're going to be cherry-picking at all it is nice to have the commits represent functional units rather than "a thing I spent an hour or two on."
posted by mskyle at 8:31 AM on November 11, 2015

Best answer: For my workflow, there are three main things I do with source control (aside from collaboration with other programmers)

1. Save point so I can roll back if I am making a big risky change. Since I don't always know which changes are big and risky beforehand, I generally commit more often.

2. Backups / working remotely. I can always pull down a copy of my code, whether I am on my girlfriend's computer or my computer blew up or whatever.

3. Working on simultaneous big changes. Like, I need to translate everything, but the project will be half broken while I am in the middle of that. But I still need to be able to make little fixes and roll them out without including the half translated version.

You might have other use cases. But those are mine, and #1 is a commit, #2 is a push, and #3 is a branch.
posted by Nothing at 8:41 AM on November 11, 2015 [1 favorite]

Commits are free. Make lots. Any logical unit of work you might ever want to inspect, reconsider, revert, see the rationale for, or assign blame to, you should give its own commit. Usually I get 3-5 commits out of a workday. If it's more original work, maybe 1. If it's more fiddly maintenance work with lots of little tweaks, maybe 10.
posted by ead at 9:18 AM on November 11, 2015

Are you writing tests? Or doing some kind of verification process to test that it works? If so, just commit after that step, and name your commit with a description of whatever you changed.
posted by deathpanels at 9:29 AM on November 11, 2015 [1 favorite]

I come from the Linux kernel tradition of small self-contained commits, which:

1) must not break anything: the code has to continue building, every feature that worked before has to work after, etc. Bugs happen, but this is the ideal you aim for.
2) given requirement #1, must basically be as small as possible (within reason).

Figuring out how to break up a complicated change into small pieces like this is sometimes a challenge, and often requires going back and rewriting history after the fact (I usually use "git rebase -i" for that).

For less critical work I still try for some loose version of the above. In particular I try to only commit when things are in a working state, so I have a nice recent spot to go back to if I screw things up.

Mainly though, I think you should just go ahead and start using it. Any revision control is better than nothing, and you'll figure out what works best as you go.
posted by bfields at 10:55 AM on November 11, 2015

Best answer: Ever been working on a program and it really isn't working and think to yourself, "I really wish I remembered how this was when it was only half broken"? That's one of the key features for git teams of size one.

One methodology that might help you out is Test Driven Development. You start by writing a lot of tests, no code. They all fail, because there's no code. Each feature gets a set of tests, and you can bundle that as one commit. Now as you add code, your workflow is only slightly modified:

0. Write tests
1. Run tests
3. Write code to fix one test
4. Run tests again.
5. If you fix the test without breaking any others, commit.
6. Go to step 3.

That's for simple stuff. But imagine you have an idea for a new feature or optimization that requires a lot of code rewriting. Instead of renaming files, Git can help here too.

0. Ensure all the tests on master pass
1. Make a new branch from master
2. Write new tests for your new feature
3. Rewrite your application in small logical chunks. Add new classes, change their structure and inheritance, or generally refactor. Make lots of commits, but ensure that no original tests are failing during this process.
4. Add your feature by fixing tests.

The key point in all of these is that you can roll back to a less broken version. Test Driven Development gives you concepts and principles to rest your commit policy upon. There are many other development methodologies, with slightly different resulting git workflows.
posted by pwnguin at 1:58 PM on November 11, 2015 [1 favorite]

One other advantage of making lots of small commits is that if you've introduced a subtle bug somewhere in your code but you're not sure when you introduced it, you have a better opportunity to track it down with git bisect if you have lots of small commits to work with.

For small personal projects I tend to commit changes after every few edits where things are compilable / not broken. When you're collaborating with other people your commit habits might change somewhat - some shops that use pull requests for code reviews might want you to squash things down to a single commit before you submit the pull request, since in theory that makes the logs a little more concise and easier to scan. It's one of those areas where you'll probably eventually develop a stylistic preference, so you should experiment a bit and see what makes sense to you.
posted by whir at 10:53 PM on November 16, 2015