4 ms·

Using version control like git kinda forces you to change the way you are developing. You start to think more about building logical pieces and also really thin

Using version control like git kinda forces you to change the way you are developing. You start to think more about building logical pieces and also really think about how the software is coming along. I would recommend learning git for anyone. Sure, it's a big hassle, because it forces you to rethink your habits. But in the end, learning it has done me nothing but good and using it enforces me to follow good practice at the same time. Also, just the support of 'git stash' to throw away experiments that didn't work easily is worth it. Tagging versions for release, demos, whatever .. git can help there too.

the8472 11y ago
> Using version control like git kinda forces you to change the way you are developing. It doesn't. Nothing prevents you from adding/committing several days worth of work with a "changed stuff. fixed some other stuff" commit message.
- imdsm 11y ago
  Ok, using SCM like git _allows_ you to change the way you are developing. You will still need to use the tool correctly. If people have good reasons for not doing certain things, then fine, but when people are just averse to it because they're lazy, well, that irks me (when I have to deal with them.)
- cableshaft 11y ago
  Very true. I knew a lead developer once that with the majority of his commits to TFS would give it some variation on the commit "latest and greatest" (If he didn't want to type that it might be "l&g"). I didn't speak up about it because I was only a contractor at the time, but it made me wince to see a whole history list of his commits with like 20 "latest and greatest" and maybe three commits that actually said what he did. But most places I've been to, people have been pretty good about explaining what they've committed, when version control was being used.
  - Shorel 11y ago
    I use this in an alias: git log --pretty=oneline --abbrev-commit --graph --stat Seeing the names of the changed files in each commit gives me a lot more of context than simply the commit description.
    - cableshaft 11y ago
      And I could double-click any commit and get the 'changeset details' with all the files modified and their diffs, but it's still better to provide an overview of what you're checking in instead of forcing people to interpret your code. At my current job we have dev tasks associated with the changesets (if applicable), so that helps provide context also.

the8472 11y ago

> Using version control like git kinda forces you to change the way you are developing. It doesn't. Nothing prevents you from adding/committing several days worth of work with a "changed stuff. fixed some other stuff" commit message.

imdsm 11y ago
Ok, using SCM like git _allows_ you to change the way you are developing. You will still need to use the tool correctly. If people have good reasons for not doing certain things, then fine, but when people are just averse to it because they're lazy, well, that irks me (when I have to deal with them.)
cableshaft 11y ago
Very true. I knew a lead developer once that with the majority of his commits to TFS would give it some variation on the commit "latest and greatest" (If he didn't want to type that it might be "l&g"). I didn't speak up about it because I was only a contractor at the time, but it made me wince to see a whole history list of his commits with like 20 "latest and greatest" and maybe three commits that actually said what he did. But most places I've been to, people have been pretty good about explaining what they've committed, when version control was being used.
- Shorel 11y ago
  I use this in an alias: git log --pretty=oneline --abbrev-commit --graph --stat Seeing the names of the changed files in each commit gives me a lot more of context than simply the commit description.
  - cableshaft 11y ago
    And I could double-click any commit and get the 'changeset details' with all the files modified and their diffs, but it's still better to provide an overview of what you're checking in instead of forcing people to interpret your code. At my current job we have dev tasks associated with the changesets (if applicable), so that helps provide context also.