2

Today I was working on something and a test was not passing. Later I was trying to remember why it was not working, because I wanted to go back and figure out why it was doing that. Of course, I did not have a commit that captured it broken because we are trained to not checkin broken things. However, Git is different: you can do commits and hold them and then only push after you have the code working. Seems like a really good idea? No? (I know I could even squash them down with Rebase.)

Rob
  • 11,446
  • 7
  • 39
  • 57
  • 1
    You can have 2 branches. One is mainline ready, i.e., stable. The other one is devel branch, which should be used for testing and stabilizing purposes. You can have a look at this article[1] on how you can organize your development with git. [1] http://nvie.com/posts/a-successful-git-branching-model/ – positron May 25 '12 at 04:01
  • I've done that approach before. And I have done Forks/Pull Requests too. The idea in this question though is why even worry about committing something that doesn't work if you are not pushing it! That's one of the great things about Git in a CI soaked world. – Rob May 25 '12 at 04:47
  • @positron: in fact, you can (and I often do) have way more than two branches. I create branches all over the place, to stash all kinds of temporary stuff. I give them names that are supposed to remind me what they are for and to keep me from pushing them anywhere, although sometimes my own abbreviations puzzle me a month later. :-) You can also use "git stash" but I find names are helpful, even with the occasional "uhh... what was THIS for again?". – torek May 25 '12 at 05:08
  • Yeah I am not against branches, I am talking about the fact that the absence of anxiety about committing broken stuff is one of git's strengths and capturing things that didn't work is beneficial to the history (/team). – Rob May 25 '12 at 13:40

1 Answers1

1

However, Git is different: you can do commits and hold them and then only push after you have the code working. Seems like a really good idea?

Yes it is a good idea, as it takes advantage of the fact a DVCS offers two orthogonal features:

  • Versioning (commits, branches, merges)
  • Publication (push / pull)

As mentioned in the comments, isolate your intermediate commits in a branch you don't intent to push (in which case a rebase --squash can be more useful than a rebase --interactive).

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • But if I don't intend to commit them, then they don't become part of the dialog. I was thinking about making an issue in github about the failing test, putting a link in to the commit, and immediately marking it as resolved. So everyone on the team can see. – Rob May 25 '12 at 13:38
  • @Rob I would argue that keeping the tests versioned allows for a close link between the tests and the exact code on which said tests were applied at any given time: they should be tightly coupled in their respective versioned history. – VonC May 25 '12 at 15:31