Timeline for What are some good practices before checking in source code?
Current License: CC BY-SA 2.5
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 11, 2011 at 2:59 | comment | added | idbrii | @AviD Good point. Although the output of those tests (even if they're failures) is good content for your commit message. Especially since I haven't had much experience with git bisect. | |
| Feb 10, 2011 at 7:18 | comment | added | AviD | @pydave you could, and you should - but you don't have to, since it's not that important. In fact, some say that you should commit before you start testing and such, just like you would always save beforehand. This way, there is a record of what you originally wrote, what was wrong with it, how you fixed it, etc. But in general I would agree with you, though that's mostly because my head isnt completely wrapped around DVCS yet... | |
| Feb 9, 2011 at 23:19 | comment | added | idbrii | @AviD (original answer): don't you still test your code and check your changes before you commit? While I agree that Git is great for having tiny and frequent commits, I still want to vet what gets committed so I can easily roll back to known good changes. Make sure you're improving the code and whatnot. | |
| Feb 9, 2011 at 23:14 | comment | added | idbrii | @Robert can't you just refer to the work item id in your commit messages? You could even add a reminder for it in your commit message with git config commit.template '~/template-file' | |
| Feb 9, 2011 at 2:10 | history | made wiki | Post Made Community Wiki | ||
| Feb 8, 2011 at 23:50 | comment | added | AviD | @Robert, I agree about Kiln - actually, that's what I'm using, and it is FANTASTIC. Of course, the integration with FB doesn't hurt... | |
| Feb 8, 2011 at 22:39 | comment | added | Robert Jeppesen | +1. Associating with a work item is the one hard thing to do in Git or Hg. You'll need to run a whole package, like Kiln. This is the (only) area in which TFS is good. It is harmful for version control though. | |
| Feb 8, 2011 at 19:36 | comment | added | AviD | @user13278 some of them do, but differently. E.g. Merging is a completely different experience - and, you do while pushing, no need for a getlatest-merge-tryagain cycle. And you can do it for a whole bunch of changesets, and not have to remerge every checkin. In general, a lot of those steps don't have much to do with the checking in anymore - e.g. you pull when you want, not because you're checking in (or pushing). Of course you still need to test - but that can be on its own timeframe. Pushing still remains a lot more lightweight, but of course you want to make sure you dont push crap. | |
| Feb 8, 2011 at 19:30 | comment | added | user13278 | Don't all of those steps just move from when you checkin, to when you push? | |
| Feb 8, 2011 at 19:14 | comment | added | Kevin Vermeer | Agreed - I imagine that Oded's workflow could benefit a lot from version control between each of the steps, or, at the very least, between each of the loops. | |
| Feb 8, 2011 at 19:10 | comment | added | PSU | +1 for commenting on the checkin. It's not policy in my shop, but I try always to leave a descriptive note, if only to jog my memory later on. | |
| Feb 8, 2011 at 19:00 | history | answered | AviD | CC BY-SA 2.5 |