2

I work on a major private Python project in an exploratory way for several months using Pycharm. I use git to track the changes in that project. I am the only person that contributes to that project.

Normally I commit changes to that project roughly once a day.

Now I want to track changes of my code every time I execute my code (the background is that I sometimes get lost which intermediate result was achieved using which version of my code).

Therefore I want to perform a git commit of all changed files at the end of the script execution.

As now every commit just gets a 'technical' commit message, I would like to distinguish these 'technical' commits from the other commits I do roughly once a day (see above). The background is that I still would like to see and compare the daily differences from each other. The technical commits might sum up to several dozens per day and would hinder me to see the major changes over the course of time.

Which techniques does git offer to distinguish the technical commits from the daily commits I do?

Is maybe branching a valid approach for this? If yes, would I delete these branches later on? (I am a git novice)

7824238
  • 388
  • 4
  • 14
  • 3
    just add a keyword in the message for commits produced by this script (e.g : '[commitbot] ...') – LeGEC Oct 12 '20 at 22:03

2 Answers2

2

I think even if you work on this project alone it might still be a good idea to adopt typical github flow approach - and start using branches.

The idea is that you distinguish your "technical" commits (many issued throughout the day) from your daily commits (rarely more than one) in terms of Git entities used:

  • your main code stays in master branch
  • your daily commits remain 'normal' commits going into a specific long-running branch (develop is a common name)
  • your 'once-a-day' commit becomes a merge commit, pushing all the changes in develop into master branch

This allows to you to save the history - yet see a clear distinction between those two types. You can opt for 'no fast forward' approach, so that each merge commit becomes clearly distinct from 'regular' ones.

And if you actually don't want all the history to be there (as @antont said, there might be a LOT of commits), you might consider 'squashing' those commits when either merging or rebasing, like described here.

raina77ow
  • 103,633
  • 15
  • 192
  • 229
  • In his case he'd end up with dozens of meaningless autocommits to history though as a script adds a new commit every time he runs the code to test. Ah no the squash at merge does allow for fixing that, am not sure how convenient that would be for a 100 meaningless commits though. – antont Oct 13 '20 at 04:42
  • 1
    "Ah no the squash at merge does allow for fixing that" - well [it does](https://stackoverflow.com/questions/5308816/how-to-use-git-merge-squash), but in this particular case one might consider [using rebase with autosquashing](https://fle.github.io/git-tip-keep-your-branch-clean-with-fixup-and-autosquash.html) – raina77ow Oct 13 '20 at 08:39
  • oh cool that `git commit --fixup` thing might be the best solution for this case indeed – antont Oct 13 '20 at 08:56
2

You could use a branch for that, yes. Just use a working branch when doing your scripted autocommits, and then when you want to make a commit for the history, switch to your main branch.

To get to re-add the final changes as a single commit, one way would be to soft reset the history when you are done with the changes. So you would:

git reset prev-real-commit

Which jumps the history back to before your new batch of wip auto commits, but does not touch the files so you don't loose work. Then you can make a new commit normally for the changes.

That technique also works without a branch. Using a branch might still be nice though so you can easily check what the version was before your new wip commits.

Git also has rebasing which would allow squashing multiple commits to one and rewriting the messages. But for the workflow you describe, I think simply reseting the autocommits away and redoing a normal commit is better.

Also the suggestion to add some tag to the message of the autocommits is good.

That said, I usually just commit the checkpoints that I need in normal dev flow. It can be nicer to have a commit e.g. every hour instead of only once a day. Small atomic commits are good. You can use feature branches and on GitHub pull requests if you want to record and manage larger wholes of work.

antont
  • 2,676
  • 1
  • 19
  • 21