On Sat, Apr 25, 2015 at 10:30 AM, boB Stepp <robertvst...@gmail.com> wrote: > On Fri, Apr 24, 2015 at 7:36 PM, Steven D'Aprano wrote: >>On Fri, Apr 24, 2015 at 02:09:45PM -0500, boB Stepp wrote: > > [...] > >>> And what would be the best approach to integrating Git with these >>> efforts? Just how often does one commit one's code to the version >>> control system? Or do I have some GCEs (Gross Conceptual Errors) here? >>> Can Git be set up to automatically keep track of my code as I create >>> and edit it?
[...] >>The executive summary of how I use version control: > >>- work on bite-sized chunks of functionality >>- when the tests all pass, commit the work done >>- push changes to the master repo at least once per day > > >>The way I use version control on my own is that I have typically use a >>single branch. I rarely have to worry about contributions from others, >>so it's just my changes. Make sure that all the relevent files (source >>code, documentation, tests, images, etc.) are being tracked. Static >>files which never change, like reference materials, should not be. > >>Starting from a point where all the tests pass, I decide to work on a >>new feature, or fix a bug. A feature might be something as small as "fix >>the documentation for this function", but *not* as big as "control >>remote controlled space ship" -- in other words, a bite-sized chunk of >>work, not a full meal. I write some tests, and write the minimal amount >>of code code that makes those tests pass: > >>- write tests >>- save tests >>- write code >>- save code >>- run tests >>- fix bugs in tests >>- save tests >>- write some more code >>- save code >>- run tests again >>- write some more code >>- save code >>- run tests again > > >>etc. Once the tests pass, then I have a feature and/or bug fix, and I >>commit all the relevent changes to the VCS. hg automatically tracks >>files, git requires you to remind it every single time what files are >>being used, but either way, by the time I run `hg commit` or `git >>commit` I have a complete, and hopefully working, bite-sized chunk of >>code that has an obvious commit message: > >>"fix bug in spam function" >>"correct spelling errors in module docs" >>"rename function ham to spam" >>"change function eggs from using a list to a dict" >>"move class K into its own submodule" > >>etc. Notice that each change is small enough to encapsulate in a short >>description, but big enough that some of them may require multiple >>rounds of back-and-forth code-and-test before it works. > >>I run the tests even after seemingly innoculous changes to comments or >>docstrings, especially docstrings. Edits to a docstring may break your >>doctests, or even your code, if you accidentally break the quoting. > >>Then, when I am feeling satisfied that I've done a sufficiently large >>amount of work, I then push those changes to the master repo (if any). >>This allows me to work from various computers and still share the same >>code base. "Sufficiently large" may mean a single change, or a full >>day's work, or a whole lot of related changes that add up to one big >>change, whatever you prefer. But it shouldn't be less than once per day. Thanks for taking the time to share your workflow. It is very helpful for me. > [...] > >>> And I would like to have all of that under version control, too. But >>> while I am allowed to write my own programs for this CSA, I am not >>> allowed to install anything else, strange as this may sound! Since the >>> only functional editors in these bare-bones Solaris 10 environments >>> are some simplistic default editor that I do not know the name of and >>> vi, I long ago gravitated to doing my actual coding on my Windows PC >>> (Being careful to save things with Unix line endings.) and FTPing to >>> the environments where these programs will actually run. I AM allowed >>> to install anything I want (within reason)on my PC. So I am thinking >>> install and use Git there? > >>Yes. This is what I plan to do. I have started reading the free online book, "Pro Git--Everything You Need to Know About Git, 2nd ed., c2014, which is accessible via the Git website. I also watched the video about Git for 4-year olds. Long video, but it gave a good overview of the Git way of implementing things. Again, thanks! I think that after reading the first two chapters of the book, I will know more than enough to get started. In actuality, after watching the video last night, I could probably get going now. But I am an inveterate book reader... boB _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
