[SOLVED] How to use code condition markers in Git?

catnap · 2018-09-24 12:08:15

I'm interested to learn if there are standard best practices for creating easy and quick visual cues to indicate the condition where the code was left after the last programming session or when it was committed to a Git repository. I call these visual cues "code condition markers" in my own personal nomenclature, although I'm not sure if that is the industry standard. The idea is that one glance to the commit message or to the first few lines in the code would suffice to tell if a code is in an experimental stage or if it has been thoroughly tested and debugged. Please let me know if there is some native functionality in Git to implement this or another tool that will approximate the same functionality. I know that I could just invent my own code condition markers as I see fit. But I would like a system that is standard enough for others to understand it immediately.

Last edited by catnap (2018-09-25 15:21:37)

jaergenoth · 2018-09-24 12:44:55

Create a branch for experimental code, and use the master branch as a "thoroughly tested and debugged" branch, maybe?
Or just comment experimental code as such, and use some kind of prefix in commits, like "[EXPERIMENTAL] This commit does something".
I didn't really get what kind of visual cue you are after.

Last edited by jaergenoth (2018-09-24 12:47:03)

Trilby · 2018-09-24 13:46:19

Are you asking about git, or github? There's nothing 'visual' about the former, so there'd be no way to add visual cues.

If you are actually asking about git, I'd second the answer of using a branch. Once the experimental features are tested, you can merge them into master. If not a formal standard, this is the defacto standard of how to commit experimental features to code in git.

catnap · 2018-09-25 10:06:18

jaergenoth wrote:

Create a branch for experimental code, and use the master branch as a "thoroughly tested and debugged" branch, maybe?

I have used this technique to some extent but it does not seem to answer all of the problems that can arise. The code that I'm currently developing is to be embedded on a physical instrument---Teensy in paricular---and it can therefore have several different well-tested versions that implement somewhat similar but slightly different functionalities. These well-tested versions cannot reside in the same master branch. However, I could consider using several branches that serve as analogs of the master branch. I only worry that this method might make the commit tree look immensely complex, but let's see.

jaergenoth wrote:

Or just comment experimental code as such, and use some kind of prefix in commits, like "[EXPERIMENTAL] This commit does something".

This approach could have the problem that it is possible to test the code without making any changes to the code itself. Re-committing the code with a new prefix might seem superfluous if the code has just been tested but it has not been changed after the last commit. Still, I have used a somewhat similar system as a temporary thing. Maybe adding the prefixes to Git tags could work. Tags can be changed without committing anything new. This might not be the industry standard, though.

Trilby wrote:

Are you asking about git, or github? There's nothing 'visual' about the former, so there'd be no way to add visual cues.

By visual cues, I don't mean that the cues must be advanced computer graphics necessarily. Text that stands out clearly counts as being visual enough for me.

progandy · 2018-09-25 11:13:56

Git has the option to add notes to a commit. I never used it though, so I don't know how they are displayed in the commit log.

https://jlk.fjfi.cvut.cz/arch/manpages/ … notes.1.en

Edit: If you have different stable versions, then they should have a branch. How would you store and reference them without that?

Last edited by progandy (2018-09-25 11:18:36)

catnap · 2018-09-25 11:53:21

progandy wrote:

If you have different stable versions, then they should have a branch. How would you store and reference them without that?

They are in their separate development branches. I would just want to make the stable versions stand out without introducing extra branching. To me, the branch tree seems a bit complex even at its present stage.

progandy · 2018-09-25 12:32:51

Maybe start tagging your stable releases?

ayekat · 2018-09-25 12:41:24

If you want versioning, I usually follow the following approach (works well for not-too-complicated projects, and I consider it rather simple, but not sure if there are better ways):

Principal development in master (maybe with feature branches for developing and/or testing new stuff, which is then merged back into master once it somewhat works). Essentially, the master branch should be reasonably usable (i.e. stuff should compile, and it should work more or less, but expect things to break occasionally). People should be able to grab the latest master build for testing and/or developing.
Once the code in master is deemed stable enough, a stable release is made by tagging a commit (e.g. with `v0.3`). The release also gets a branch associated (e.g. `v0.3.x`); for the initial release this doesn't contain any new commits on its own, but…
After making a release, development continues in the master branch, nothing new. However, commits that fix a bug that also affects the last stable release are also backported (i.e. cherry-picked) to the v0.3.x branch. After backporting one or more bugfix commits, the latest commit in v0.3.x is tagged again, with `v0.3.1`.
- The v0.3.x branch thus contains the last stable release + bugfix commits made after that release, and is intended for general use.

Rinse and repeat: once the features for the next release are ready, you tag a commit in your master branch with `v0.4`, create a `v0.4.x` branch there, and continue the same process (and at that point, I typically discontinue the v0.3.x branch, but if you want to provide better legacy support, you could also try to backport bugfixes onto 1 or more previous releases as well—that'll be up to you to decide).

Last edited by ayekat (2018-09-25 12:55:48)

Trilby · 2018-09-25 14:16:11

Even if you have a bunch of branches - say flavorA, flavorB, flavorC ... then doubling the number of branches need not add unreasonable complexity as long as you chose a good naming scheme for your branches: flavorA, flavorA-testing, flavorB, flavorB-testing ...

And odds are, that the *-testing branches wouldn't have to stick around long, and you may never even need more than one of them to exist at the same time.

catnap · 2018-09-25 15:20:39

These are all great suggestions. I will try to implement them to my workflow.

progandy wrote:

Git has the option to add notes to a commit.

This solution has the advantage that you can dynamically change the code stability status of an old commit after testing without making another commit just for that.

progandy wrote:

I never used it though, so I don't know how they are displayed in the commit log.

The notes seem to be included in the log messages by default.

 $ git log

Author: *** <***@yahoo.co.uk>
Date:   Mon Sep 24 16:31:55 2018 +0300

    removed obsolete arguments in operation research implementation

Notes:
    Thoroughly tested

Arch Linux

#1 2018-09-24 12:08:15

[SOLVED] How to use code condition markers in Git?

#2 2018-09-24 12:44:55

Re: [SOLVED] How to use code condition markers in Git?

#3 2018-09-24 13:46:19

Re: [SOLVED] How to use code condition markers in Git?

#4 2018-09-25 10:06:18

Re: [SOLVED] How to use code condition markers in Git?

#5 2018-09-25 11:13:56

Re: [SOLVED] How to use code condition markers in Git?

#6 2018-09-25 11:53:21

Re: [SOLVED] How to use code condition markers in Git?

#7 2018-09-25 12:32:51

Re: [SOLVED] How to use code condition markers in Git?

#8 2018-09-25 12:41:24

Re: [SOLVED] How to use code condition markers in Git?

#9 2018-09-25 14:16:11

Re: [SOLVED] How to use code condition markers in Git?

#10 2018-09-25 15:20:39

Re: [SOLVED] How to use code condition markers in Git?

Board footer