10 ms·

I kind of feel that this kind of git advice is way beyond the point of diminishing returns. As a conscientious developer we have a lot of work. We write code of

by cjfd 5y ago

I kind of feel that this kind of git advice is way beyond the point of diminishing returns. As a conscientious developer we have a lot of work. We write code of good quality. We refactor that code regularly. We write automated tests. We test the program manually. We use linters and type checkers. We talk to people to find out whether what they requested is actually what they need. But the day only has 24 hours. At some point one has to say that enough is enough. I really want to put the 'enough is enough' point before worrying about a good looking commit history. Some years ago we all went from svn to git and I am not really sure the improvement was worth it. Sure, git is objectively the better version control system. One can do a lot more things in git. But then the disadvantage is that one actually gets to think about all of these 'a lot more things'. One thinks about questions like should one merge or rebase and so on. I seems like an activity that falls under what is commonly called 'bike shedding'. But like I was asking before: is this really worth it?

seba_dos1 5y ago
Isn't the answer to "is this worth it" quite obvious when doing code reviews? Properly and logically split commits can make it so much easier and more pleasant, and things like "commit often, perfect later" are in my experience less, not more work. The rest seems like a pretty basic set of tips that I mostly learned over the years because I needed them, so it would be definitely nice to read such article several years ago to save me some time ;)
- danny_sf45 5y ago
  Do people actually do code reviews per commit? I know it's a thing, but in all my years of experience, I haven't met anyone who actually does this. The usual practice is to review all the changes at once (e.g., go to the "Files changed" tab of a PR in GitHub and start reviewing the changes). This, of course, means, that PR are "small". If a PR is too "big" then one politely asks the author to split the PR in many.
  - vlovich123 5y ago
    When I was at FB, there’s no PR as defined at GitHub. Each independent commit was a separate review. So in that sense, all of the 10s of thousands of engineers at Facebook daily review “PRs” at the commit level.
    - angrais 5y ago
      In that case, where you then recommended to only make one commit? Are there guidelines for the average/ideal commit length? Did this add to extra workload in creating "perfect" commits? Likewise, did this mean that pushing "WIP" commits to remote was rare?
      - vlovich123 5y ago
        Felt like less workload because each commit had independent feedback that you could address resolve. Then you could push each commit as it was ready (or whichever part of the stack was). Wip commits we’re often and frequent for CI purposes but as with PRs you don’t want to waste too much review time on WIP unless your asking for some preliminary feedback on a complex change. Ideal commit length was unchanged to any other commit length you might be expected to do on any other team with good commit hygiene.
  - dkubb 5y ago
    My current team does it, and it is so enjoyable. We practice atomic commits that change only one thing, and in one way. We separate Fix, Refactor, Change, Add, Move and Remove commits from each other. Our commit summaries begin with those keywords so we can tell what "type" the change is. Each commit must pass CI 100% on it's own. There are specific characteristics we've noticed. For example, for us, a "pure Refactor" commit either touches code or tests, but not both at the same time. If we touch too much we try to split it, or we call it a Change and it gets even more/different scrutiny. Reviewing by commit allows me to give my full focus to each without having to keep all state in my head at once. I can step through and understand the series of changes. It's like telling a story, once I've stepped through each commit I am better able to understand the whole picture. If I only look at the summary some of the finer points are missed. Also we've found we can extract commits more easily and get those merged early while we work on our main branches. If we see a Refactor, we can just do it, extract it and then keep our main PR focused.
danielheath 5y ago
I find this sort of process useful, but not necessarily for the obvious reasons. Picking apart changesets after the face helps me find issues that are likely to crop up in review, because I am looking at a patch. It also helps me separate contentious changes from obviously correct ones, which means the clearly good stuff isn’t held up waiting for approval on the complex.
- morpheos137 5y ago
  A human edit goes some way to limiting the set of controversial changes – it means there is a small human oversight that we can read through to determine. All those are valuable, and it’s only now starting to get the sort of support that would allow me to say “No, none of those changes are contentious, and no, you can approve it.”. In the absence of that, some changes are contentious enough that I can’t approve it. We can and should argue about the edge cases (especially with some form of non-subjective metrics for controversiality). However, given we are looking to be useful at work, I think the anti-semantic review process is what will get us there. From a technical POV, the major issues would be to introduce syntactic analysis of the text, to support dictionary. I think that is probably fine, given that it won’t happen anyway, and I suspect that the direction of that work will help with parsing and analysis. Of course, we could move past the scope of the syntax.
colordrops 5y ago
Yes, it is worth it. Yes the learning curve was somewhat long, but once you get it, it becomes background. Working with SVN or perforce or CVS or VSS was such a chore and prevented experimentation or simultaneous work on the same code. I suspect it's not even a debate as to whether it's worth it among many of us.
veidr 5y ago
I think your question is two questions: is git (with its massive additional complexity over svn worth it), and then is the level of git fuckery described in the article worth it? Obviously, most of the world thinks git as a whole is worth it. Otherwise, it wouldn't have so thoroughly and totally dominated the software revision control system space. OTOH, probably most of us are using a tiny fraction of the full git feature set, and would perhaps have a different opinion if we were forced to learn and use all of it. But is it worth it to learn, remember, and follow all the guidelines in this article? YMMV and it depends on the project, but personally I would say no, unless it is a project of unusual quality and importance. Life is short and it probably won't matter at all in the end.
avar 5y ago
You're right, for a lot of people it isn't worth it. The linked article contain way more detail than I daresay the vast majority of users of git need to know about these days. If you're a programmer who heavily uses it in your workflow you might find this sort of advice useful, but I've helped plenty of programmers with some issue in git that wouldn't have required my help if they had even intermediate knowledge of it. Does that mean that their time would be best spent knowing more about it? Maybe, but maybe not. In some cases I'd say definitely not. A lot of people are productive with it knowing no more than "git status/add/commit/push/pull". I've got expert-level knowledge on git, but I use plenty of tools that I've got at best a novice or beginner-level amount of knowledge of. You can't know everything. The tricky part is that until you know something you can't know what you're missing.
jackhab 5y ago
As someone who also switched from SVN to git many years ago I understand this "is this really worth it" thing. It came to my mind many times in the beginning when I said to myself "do we really need a distributed SCM if everyone are always working against the same server anyways". But putting git's technical advantages aside, for me, one of its most important values is that it has become de facto industry standard. It's like IP/TCP/UDP protocols which everyone understands be it a tiny IoT device or 10K-core cluster. With all this enormous amount of programming languages, frameworks and tools we have in the industry it's so nice we've managed to agree, at least, upon one very important element of our work.
- sharken 5y ago
  As someone about to move from Mercurial to Git i absolutely agree, even though Git has its quirks, you can always find some help for a specific problem. Refactoring was mentioned and i think a good Git branching strategy is vital in that regard. If you have multiple branches and merge between them, then refactoring tends to not happen due to developers not wanting to have difficult merges. The obvious choice is Trunk-based Development, but it's almost a bigger transition than moving to Git.
- tharkun__ 5y ago
  This just reminded me of when I last didn't use git. It's been so long and really worth it. It must have been around 2010. I was with a client and they were using SVN in the projects I worked on (and some other obscure - to me - versioning system that they literally had "build masters" for that were the only ones allowed to merge and solve conflicts for the entire company, even though they never ever worked on the code itself). I had been using git before that already for some time and couldn't fathom why anyone would not use that. They didn't believe my raving about git. Almost needless to say that they were always complaining about merge conflicts, about not being able to do X or Y or Z or that things were slow or error prone (like branches) or that they messed up a conflict resolution upon merging and needed help because they forgot to copy their entire source tree to a different location before doing so etc. I had zero problems like that because I simply used `git-svn`. Why is this significant? Because I hear so many people complain about how hard a "trunk based development workflow with rebases" is. Well guess what, that's basically what git-svn is. Nobody in their right mind used SVN any other way but with a single trunk, because branches sucked so much (except for release branches and yes, if you had to bring in something from `trunk` it wasn't just a simply cherry-pick). And because of SVN being what SVN was, before committing to SVN git-svn would simply rebase my work on the current SVN trunk automagically and the issue the commit to SVN. Any conflicts could be solved locally on git and because I had to commit anyway before it could do this rebase. In those two years I had literally one conflict and it was easy to solve, while everyone around me kept having problems. Heck even the feature branches were easy for me, because it's just a different 'trunk' to rebase onto and I actually _could_ cherry pick for them :) I learned the one lesson I think everyone just has to keep in mind with git: Commit before you do anything else and you won't ever loose work (save bugs in git or you doing stupid low level stuff). You can always just reset back to your commit and redo the botched attempt to resolve conflicts and this time around it should be easier with the knowledge you gained in the first try. That's also why I never use git-stash to move stuff around. There's no commit to go back to if you accidentally did a `git stash pop` instead of `git stash apply`. Heck there was even this one guy who got some rebasing and squashing so wrong that he force pushed a completely different branch onto his branch. "Lost" all of his week's work. He was so so happy when he learned how to find the commit hash for the 'lost work' and that all branches are in git are labels for those commit hashes and we magically brought it all back by reattaching this label to the right commit and force pushing again.
jrockway 5y ago
It really depends on the timescale of your changes. Change a few lines in an afternoon? Nobody cares about the history. But if you ever have a long-running branch, you will care about your local history. You'll merge in the main branch, and it will conflict. Someone already renamed the thing that you're renaming in your branch. An auto-formatted changed its mind. The API changed. Some stuff was refactored. The difference between "hmm, annoying" and "I'll just delete this work and start over" after struggling for a week pretty much comes down to the history -- remembering what you did and why, and being able to apply pieces of that relative to the new state of the main branch. This is one of those insidious things that will only affect you. Nobody else has your working copy, and nobody cares what you do in it. But they will be doing their thing while you do yours, and to thrive in that environment, you can take advantage of tools. (As for keeping PRs/CLs focused, it is sure nice when you hit some weird bug 3 months later and can identify the candidate commit with a bisect. You don't NEED the history to debug something; just debug it. But it can sure help with the "why" and "how" and get you from debugging to fixing much faster. Bisecting is at the top of our debugging checklist -- do it no matter what once you have a reproduction. It saves so much time that it's not even worth thinking about.)
- ChrisMarshallNY 5y ago
  The old Perforce Mainline Model[0] prescribes regular merges from the mainline into your working branch, in order to reduce the hit, when you merge back down, into the mainline. Basic common sense, and it also applies to git. With git, those regular up-merges are a lot easier. Personally, I have been using git for years, and have never looked back at Perforce, but learning on more primitive VCSes taught me a disciplined, careful approach. I did have to “unlearn” a few things (mostly, relaxing, and having more faith in the tool), but the transition has been fairly smooth. [0] https://www.perforce.com/video-tutorials/vcs/mainline-model-tofu-scale https://www.perforce.com/video-tutorials/vcs/mainline-model-...
  - marton78 5y ago
    I agree with this advice in spirit, but I prefer rebasing regularly onto master, rather than merging. Especially in a long lived branch this keeps the list of changes small. Imagine that someone performed a huge refactor in master, which conflicts with some small thing you did in your branch. If doesn't help to have another commit of the huge refactor in your history: the merge commit. I very much prefer to see only the logical changes I did in my branch.
peakaboo 5y ago
Worth it for a few companies, but not for the majority. Most tests are also useless. Going for 100% test coverage is insanity. I think there is a lot of people in tech with autistic personalities who really hate when things are not perfect.
- runawaybottle 5y ago
  Couple that with adhd meds which induces a state of compulsiveness where one obsesses and marvels delusionally at their code writing ability.
- kossTKR 5y ago
  True, i can also get OCD'ey vibes, myself included, i think it comes with mindset one fosters when looking at a screen for long. Same thing can also happen when doing Music or Digital Art, you can fell into a perfectionism loop, where you spend an exponential amount of time on smaller and smaller tasks, that no one will ever care about. For lots of projects writing some quick end-to-end or story based tests is sufficient, maybe with some randomisation thrown in. I honestly think the current framework hell we're in has pushed so many hyper-complex best practices that we just waste way too much time on perfecting process over actually coding - tests being one of the paradigms that has gone overboard.
  - phone8675309 5y ago
    A widely used, large framework having really good code coverage is important, especially if not everyone uses all of the framework.
tovej 5y ago
Some things are more worth it than others, and you can choose how much effort you put in. Small commits are definitely worth it when debugging. I've lost hours, maybe even days because of long commits that were a pain to bisect. The help you get from singling out a commit of 3 changes compared to one with 20 changes is immense.
Shacklz 5y ago
> I really want to put the 'enough is enough' point before worrying about a good looking commit history. I see where you're coming from, but I'd like to add a counter-argument to that. I'm currently working on a (mono-) repository with 40-something devs working on it, and we've recently switched from a "everything goes"-commit-history-approach to enforced linear history (while only a handful of people are allowed to directly commit on main-lines without a pull request). The main reasoning was this: It became almost impossible to understand why a build broke on the mainline by just looking at the commit-history itself. It was always needed to go through build-logs and such to get the picture of the how and why, and often even to get to the 'who', because the commit-history itself was just riddled with merge-commits. For the few devs who took care of that, this was a huge issue, while everyone else was just happily committing away. So going to the linear-history-approach made "analyze, understand" a breeze, but made "insertion" harder. We had to put in quite a bit of effort to get everyone up to speed (rebase, squash, reset, cherry-pick etc.) and set up some tooling for basic sanity-checks (pre-push-hooks etc.), but it was well-worth it, and a lot of devs were actually happy to be guided through this because for them it's clear that this will also be useful further down the road (in other jobs), not just for the current task at hand. And at last: It's really not that big of a deal. Just before opening a pull-request (or whatever your equivalent is), have a look through your change-set, run a bunch of commands if necessary, and done. Once you get the hang of it, it's pretty straight forward. It might not be worth it for you personally, but if you work on a repository with many other devs, there might be others who are grateful for that.
- deleted 5y ago
  [deleted]
- tharkun__ 5y ago
  This, so much this. Same boat here (for long-ish values of "recent"). I can only second all of what you've said. Rebasing and squashing really aren't that hard. If you ask me, selecting who you want to work with simply based on whether they can be taught to rebase and squash is a really good filter. If someone can't manage that, it is very very likely that you won't be happy to talk to them about small commits (easy to PR), good code hygiene and maintainable code, continuous deployments throughout the day (yes, OMG, you have to keep master green at all time, you have to follow up etc.) and a bunch of other things. That's fine by me, but I'd prefer not to work for the same small company as them or at least a few departments away in a larger one. All of these practices have so many advantages but many people don't or don't want to understand. You can generally teach this to people but it does need everyone to understand and pull on the same string. You can't have a bunch of people in a such a system that just never check the master build after merging.
globular-toast 5y ago
Like anything, this becomes easier with practice. Once you get into the swing with a good workflow, it no longer requires thought. Make the investment once, reap the rewards later when you have to track down a regression that was introduced some time in the past year.
LAC-Tech 5y ago
I agree 100%. I wish we could use a version control tool that didn't require so much attention. I don't want to read article after article for something that should just get out of my way.
- sharken 5y ago
  A set of basic Git commands for everyday use is a good starting point and of course knowing a bit about the staging area and remote/upstream sources as well. But if you move into the enterprise with multiple releases in active development and multiple teams, then it's hard to keep Git out of the way.
- t-writescode 5y ago
  This is honestly where I think good git GUI tools help, and for those I go to Git Extensions, or did until I had to use a Mac for work. I learned enough using it that I can work through most issues in a regular and natural way nowadays.
- bonzini 5y ago
  It's out of your way if you so desire, just squash and commit. What you pay the price for isn't satisfying git's whims; it's a better debugging or learning experience months or years down the line, which is something that git enables you to do.
BugsJustFindMe 5y ago
> But the day only has 24 hours 8. The day only has 8 hours. I'm not getting paid for more than that.
- smartbit 5y ago
  6. you might get paid for 8 hours, but effectively work 6 hours. The rest of the working hours are for mundane tasks.
  - war1025 5y ago
    If we're going down that road, I generally try to be productive from roughly 2pm to 4:30. The rest of the day is for waiting to see if something unexpected catches fire and figuring out what it is I should be working on for my two and half hours of focus time.
kevin_b_er 5y ago
The way the information is organized can often be just as important. Good data keeping practices can be applied to the history of changes in the software code as well. The problem is we're still discussing(arguing) over what good practices are.
dkarl 5y ago
I disagree. Like code, commit history is read much more often than it is written, so care in writing is repaid over time. You don't even have to take that much care and effort. The vast majority of the time, you only need to rebase WIP commits together into a single commit with a descriptive message. The effort of this is insignificant compared to the value of a meaningful, readable commit history.
- Retric 5y ago
  I personally spend significantly more time writing git commit messages than reading them. Spending lots of time looking at old commits is IMO a sign of poor code quality. Similarly, summarizing each change deserves some real thought so when you are reading these messages their actually helpful.
  - SergeAx 5y ago
    When your codebase is 5+ years old and was written by 10+ engineers, 2/3 of those are not working here anymore, all you have is commit history linked to task tracking database. So it is naturally the first step of working on a new feature: get to know the subdomain, find corresponding sub-namespaces, look into commit history of those and find related task and specs. Or you may just punch in a lot of code in hope it will find somehow it's place in codebase and be consistent with other code and readable by your successors and won't break some edge cases not covered by autotests.
    - Retric 5y ago
      Interesting, I favor reading the entire codebase when possible assuming I am going to be working with it for a few months. I only start really looking at old commits only when I need to edit code that’s particularly brittle or incomprehensible.
      - Quikinterp 5y ago
        If I ever have to fix bugs I'll go and look at the commit history to see where it likely started. Especially if it was code that belonged to me but someone inadvertently commited something that broke it, that's why I like a nice commit history.
alecbz 5y ago
You should only ever do things when they're worth it. Which sounds obvious, but a lot of people argue for "correctness" of things in the abstract without tying back to why that correctness matters, how much its worth, and what the cost of getting it is. In the case of git, I think a) a good "published" code history can actually be pretty valuable b) git's UX is bad The fact that a tidy history is valuable should be totally independent from the fact that git's UI doesn't make it easy to do that.
simonw 5y ago
I've realized that as software engineers our work isn't writing code: it's changing code. As such, the unit of work that we produce is the code change. Which means crafting a good commit - with a good commit message - is key to our craft.
TimTheTinker 5y ago
> Some years ago we all went from svn to git and I am not really sure the improvement was worth it. I used svn for years before switching to git. Trust me, git is a huge usability improvement, even for use as an individual developer or small team. Merging in svn was significantly harder. Cherry-picking was unheard of, not to mention diffs and patches.
AtNightWeCode 5y ago
If you work with pull requests, as many companies does, it is essential that things go into separated commits. What junior devs often does is refactor something and then also add functionality in the same commit making it hard to understand if a change is an error in the refactoring or part of the new functionality.

by cjfd 5y ago

seba_dos1 5y ago

Isn't the answer to "is this worth it" quite obvious when doing code reviews? Properly and logically split commits can make it so much easier and more pleasant, and things like "commit often, perfect later" are in my experience less, not more work. The rest seems like a pretty basic set of tips that I mostly learned over the years because I needed them, so it would be definitely nice to read such article several years ago to save me some time ;)

danny_sf45 5y ago
Do people actually do code reviews per commit? I know it's a thing, but in all my years of experience, I haven't met anyone who actually does this. The usual practice is to review all the changes at once (e.g., go to the "Files changed" tab of a PR in GitHub and start reviewing the changes). This, of course, means, that PR are "small". If a PR is too "big" then one politely asks the author to split the PR in many.
- vlovich123 5y ago
  When I was at FB, there’s no PR as defined at GitHub. Each independent commit was a separate review. So in that sense, all of the 10s of thousands of engineers at Facebook daily review “PRs” at the commit level.
  - angrais 5y ago
    In that case, where you then recommended to only make one commit? Are there guidelines for the average/ideal commit length? Did this add to extra workload in creating "perfect" commits? Likewise, did this mean that pushing "WIP" commits to remote was rare?
    - vlovich123 5y ago
      Felt like less workload because each commit had independent feedback that you could address resolve. Then you could push each commit as it was ready (or whichever part of the stack was). Wip commits we’re often and frequent for CI purposes but as with PRs you don’t want to waste too much review time on WIP unless your asking for some preliminary feedback on a complex change. Ideal commit length was unchanged to any other commit length you might be expected to do on any other team with good commit hygiene.
- dkubb 5y ago
  My current team does it, and it is so enjoyable. We practice atomic commits that change only one thing, and in one way. We separate Fix, Refactor, Change, Add, Move and Remove commits from each other. Our commit summaries begin with those keywords so we can tell what "type" the change is. Each commit must pass CI 100% on it's own. There are specific characteristics we've noticed. For example, for us, a "pure Refactor" commit either touches code or tests, but not both at the same time. If we touch too much we try to split it, or we call it a Change and it gets even more/different scrutiny. Reviewing by commit allows me to give my full focus to each without having to keep all state in my head at once. I can step through and understand the series of changes. It's like telling a story, once I've stepped through each commit I am better able to understand the whole picture. If I only look at the summary some of the finer points are missed. Also we've found we can extract commits more easily and get those merged early while we work on our main branches. If we see a Refactor, we can just do it, extract it and then keep our main PR focused.

danielheath 5y ago

I find this sort of process useful, but not necessarily for the obvious reasons. Picking apart changesets after the face helps me find issues that are likely to crop up in review, because I am looking at a patch. It also helps me separate contentious changes from obviously correct ones, which means the clearly good stuff isn’t held up waiting for approval on the complex.

morpheos137 5y ago
A human edit goes some way to limiting the set of controversial changes – it means there is a small human oversight that we can read through to determine. All those are valuable, and it’s only now starting to get the sort of support that would allow me to say “No, none of those changes are contentious, and no, you can approve it.”. In the absence of that, some changes are contentious enough that I can’t approve it. We can and should argue about the edge cases (especially with some form of non-subjective metrics for controversiality). However, given we are looking to be useful at work, I think the anti-semantic review process is what will get us there. From a technical POV, the major issues would be to introduce syntactic analysis of the text, to support dictionary. I think that is probably fine, given that it won’t happen anyway, and I suspect that the direction of that work will help with parsing and analysis. Of course, we could move past the scope of the syntax.

colordrops 5y ago

Yes, it is worth it. Yes the learning curve was somewhat long, but once you get it, it becomes background. Working with SVN or perforce or CVS or VSS was such a chore and prevented experimentation or simultaneous work on the same code. I suspect it's not even a debate as to whether it's worth it among many of us.

veidr 5y ago

I think your question is two questions: is git (with its massive additional complexity over svn worth it), and then is the level of git fuckery described in the article worth it? Obviously, most of the world thinks git as a whole is worth it. Otherwise, it wouldn't have so thoroughly and totally dominated the software revision control system space. OTOH, probably most of us are using a tiny fraction of the full git feature set, and would perhaps have a different opinion if we were forced to learn and use all of it. But is it worth it to learn, remember, and follow all the guidelines in this article? YMMV and it depends on the project, but personally I would say no, unless it is a project of unusual quality and importance. Life is short and it probably won't matter at all in the end.

avar 5y ago

You're right, for a lot of people it isn't worth it. The linked article contain way more detail than I daresay the vast majority of users of git need to know about these days. If you're a programmer who heavily uses it in your workflow you might find this sort of advice useful, but I've helped plenty of programmers with some issue in git that wouldn't have required my help if they had even intermediate knowledge of it. Does that mean that their time would be best spent knowing more about it? Maybe, but maybe not. In some cases I'd say definitely not. A lot of people are productive with it knowing no more than "git status/add/commit/push/pull". I've got expert-level knowledge on git, but I use plenty of tools that I've got at best a novice or beginner-level amount of knowledge of. You can't know everything. The tricky part is that until you know something you can't know what you're missing.

jackhab 5y ago

As someone who also switched from SVN to git many years ago I understand this "is this really worth it" thing. It came to my mind many times in the beginning when I said to myself "do we really need a distributed SCM if everyone are always working against the same server anyways". But putting git's technical advantages aside, for me, one of its most important values is that it has become de facto industry standard. It's like IP/TCP/UDP protocols which everyone understands be it a tiny IoT device or 10K-core cluster. With all this enormous amount of programming languages, frameworks and tools we have in the industry it's so nice we've managed to agree, at least, upon one very important element of our work.

sharken 5y ago
As someone about to move from Mercurial to Git i absolutely agree, even though Git has its quirks, you can always find some help for a specific problem. Refactoring was mentioned and i think a good Git branching strategy is vital in that regard. If you have multiple branches and merge between them, then refactoring tends to not happen due to developers not wanting to have difficult merges. The obvious choice is Trunk-based Development, but it's almost a bigger transition than moving to Git.
tharkun__ 5y ago
This just reminded me of when I last didn't use git. It's been so long and really worth it. It must have been around 2010. I was with a client and they were using SVN in the projects I worked on (and some other obscure - to me - versioning system that they literally had "build masters" for that were the only ones allowed to merge and solve conflicts for the entire company, even though they never ever worked on the code itself). I had been using git before that already for some time and couldn't fathom why anyone would not use that. They didn't believe my raving about git. Almost needless to say that they were always complaining about merge conflicts, about not being able to do X or Y or Z or that things were slow or error prone (like branches) or that they messed up a conflict resolution upon merging and needed help because they forgot to copy their entire source tree to a different location before doing so etc. I had zero problems like that because I simply used `git-svn`. Why is this significant? Because I hear so many people complain about how hard a "trunk based development workflow with rebases" is. Well guess what, that's basically what git-svn is. Nobody in their right mind used SVN any other way but with a single trunk, because branches sucked so much (except for release branches and yes, if you had to bring in something from `trunk` it wasn't just a simply cherry-pick). And because of SVN being what SVN was, before committing to SVN git-svn would simply rebase my work on the current SVN trunk automagically and the issue the commit to SVN. Any conflicts could be solved locally on git and because I had to commit anyway before it could do this rebase. In those two years I had literally one conflict and it was easy to solve, while everyone around me kept having problems. Heck even the feature branches were easy for me, because it's just a different 'trunk' to rebase onto and I actually _could_ cherry pick for them :) I learned the one lesson I think everyone just has to keep in mind with git: Commit before you do anything else and you won't ever loose work (save bugs in git or you doing stupid low level stuff). You can always just reset back to your commit and redo the botched attempt to resolve conflicts and this time around it should be easier with the knowledge you gained in the first try. That's also why I never use git-stash to move stuff around. There's no commit to go back to if you accidentally did a `git stash pop` instead of `git stash apply`. Heck there was even this one guy who got some rebasing and squashing so wrong that he force pushed a completely different branch onto his branch. "Lost" all of his week's work. He was so so happy when he learned how to find the commit hash for the 'lost work' and that all branches are in git are labels for those commit hashes and we magically brought it all back by reattaching this label to the right commit and force pushing again.

jrockway 5y ago

It really depends on the timescale of your changes. Change a few lines in an afternoon? Nobody cares about the history. But if you ever have a long-running branch, you will care about your local history. You'll merge in the main branch, and it will conflict. Someone already renamed the thing that you're renaming in your branch. An auto-formatted changed its mind. The API changed. Some stuff was refactored. The difference between "hmm, annoying" and "I'll just delete this work and start over" after struggling for a week pretty much comes down to the history -- remembering what you did and why, and being able to apply pieces of that relative to the new state of the main branch. This is one of those insidious things that will only affect you. Nobody else has your working copy, and nobody cares what you do in it. But they will be doing their thing while you do yours, and to thrive in that environment, you can take advantage of tools. (As for keeping PRs/CLs focused, it is sure nice when you hit some weird bug 3 months later and can identify the candidate commit with a bisect. You don't NEED the history to debug something; just debug it. But it can sure help with the "why" and "how" and get you from debugging to fixing much faster. Bisecting is at the top of our debugging checklist -- do it no matter what once you have a reproduction. It saves so much time that it's not even worth thinking about.)

ChrisMarshallNY 5y ago
The old Perforce Mainline Model[0] prescribes regular merges from the mainline into your working branch, in order to reduce the hit, when you merge back down, into the mainline. Basic common sense, and it also applies to git. With git, those regular up-merges are a lot easier. Personally, I have been using git for years, and have never looked back at Perforce, but learning on more primitive VCSes taught me a disciplined, careful approach. I did have to “unlearn” a few things (mostly, relaxing, and having more faith in the tool), but the transition has been fairly smooth. [0] https://www.perforce.com/video-tutorials/vcs/mainline-model-tofu-scale https://www.perforce.com/video-tutorials/vcs/mainline-model-...
- marton78 5y ago
  I agree with this advice in spirit, but I prefer rebasing regularly onto master, rather than merging. Especially in a long lived branch this keeps the list of changes small. Imagine that someone performed a huge refactor in master, which conflicts with some small thing you did in your branch. If doesn't help to have another commit of the huge refactor in your history: the merge commit. I very much prefer to see only the logical changes I did in my branch.

peakaboo 5y ago

Worth it for a few companies, but not for the majority. Most tests are also useless. Going for 100% test coverage is insanity. I think there is a lot of people in tech with autistic personalities who really hate when things are not perfect.

runawaybottle 5y ago
Couple that with adhd meds which induces a state of compulsiveness where one obsesses and marvels delusionally at their code writing ability.
kossTKR 5y ago
True, i can also get OCD'ey vibes, myself included, i think it comes with mindset one fosters when looking at a screen for long. Same thing can also happen when doing Music or Digital Art, you can fell into a perfectionism loop, where you spend an exponential amount of time on smaller and smaller tasks, that no one will ever care about. For lots of projects writing some quick end-to-end or story based tests is sufficient, maybe with some randomisation thrown in. I honestly think the current framework hell we're in has pushed so many hyper-complex best practices that we just waste way too much time on perfecting process over actually coding - tests being one of the paradigms that has gone overboard.
- phone8675309 5y ago
  A widely used, large framework having really good code coverage is important, especially if not everyone uses all of the framework.

tovej 5y ago

Some things are more worth it than others, and you can choose how much effort you put in. Small commits are definitely worth it when debugging. I've lost hours, maybe even days because of long commits that were a pain to bisect. The help you get from singling out a commit of 3 changes compared to one with 20 changes is immense.

Shacklz 5y ago

> I really want to put the 'enough is enough' point before worrying about a good looking commit history. I see where you're coming from, but I'd like to add a counter-argument to that. I'm currently working on a (mono-) repository with 40-something devs working on it, and we've recently switched from a "everything goes"-commit-history-approach to enforced linear history (while only a handful of people are allowed to directly commit on main-lines without a pull request). The main reasoning was this: It became almost impossible to understand why a build broke on the mainline by just looking at the commit-history itself. It was always needed to go through build-logs and such to get the picture of the how and why, and often even to get to the 'who', because the commit-history itself was just riddled with merge-commits. For the few devs who took care of that, this was a huge issue, while everyone else was just happily committing away. So going to the linear-history-approach made "analyze, understand" a breeze, but made "insertion" harder. We had to put in quite a bit of effort to get everyone up to speed (rebase, squash, reset, cherry-pick etc.) and set up some tooling for basic sanity-checks (pre-push-hooks etc.), but it was well-worth it, and a lot of devs were actually happy to be guided through this because for them it's clear that this will also be useful further down the road (in other jobs), not just for the current task at hand. And at last: It's really not that big of a deal. Just before opening a pull-request (or whatever your equivalent is), have a look through your change-set, run a bunch of commands if necessary, and done. Once you get the hang of it, it's pretty straight forward. It might not be worth it for you personally, but if you work on a repository with many other devs, there might be others who are grateful for that.

deleted 5y ago
[deleted]
tharkun__ 5y ago
This, so much this. Same boat here (for long-ish values of "recent"). I can only second all of what you've said. Rebasing and squashing really aren't that hard. If you ask me, selecting who you want to work with simply based on whether they can be taught to rebase and squash is a really good filter. If someone can't manage that, it is very very likely that you won't be happy to talk to them about small commits (easy to PR), good code hygiene and maintainable code, continuous deployments throughout the day (yes, OMG, you have to keep master green at all time, you have to follow up etc.) and a bunch of other things. That's fine by me, but I'd prefer not to work for the same small company as them or at least a few departments away in a larger one. All of these practices have so many advantages but many people don't or don't want to understand. You can generally teach this to people but it does need everyone to understand and pull on the same string. You can't have a bunch of people in a such a system that just never check the master build after merging.

globular-toast 5y ago

Like anything, this becomes easier with practice. Once you get into the swing with a good workflow, it no longer requires thought. Make the investment once, reap the rewards later when you have to track down a regression that was introduced some time in the past year.

LAC-Tech 5y ago

I agree 100%. I wish we could use a version control tool that didn't require so much attention. I don't want to read article after article for something that should just get out of my way.

sharken 5y ago
A set of basic Git commands for everyday use is a good starting point and of course knowing a bit about the staging area and remote/upstream sources as well. But if you move into the enterprise with multiple releases in active development and multiple teams, then it's hard to keep Git out of the way.
t-writescode 5y ago
This is honestly where I think good git GUI tools help, and for those I go to Git Extensions, or did until I had to use a Mac for work. I learned enough using it that I can work through most issues in a regular and natural way nowadays.
bonzini 5y ago
It's out of your way if you so desire, just squash and commit. What you pay the price for isn't satisfying git's whims; it's a better debugging or learning experience months or years down the line, which is something that git enables you to do.

BugsJustFindMe 5y ago

> But the day only has 24 hours 8. The day only has 8 hours. I'm not getting paid for more than that.

smartbit 5y ago
6. you might get paid for 8 hours, but effectively work 6 hours. The rest of the working hours are for mundane tasks.
- war1025 5y ago
  If we're going down that road, I generally try to be productive from roughly 2pm to 4:30. The rest of the day is for waiting to see if something unexpected catches fire and figuring out what it is I should be working on for my two and half hours of focus time.

kevin_b_er 5y ago

The way the information is organized can often be just as important. Good data keeping practices can be applied to the history of changes in the software code as well. The problem is we're still discussing(arguing) over what good practices are.

dkarl 5y ago

I disagree. Like code, commit history is read much more often than it is written, so care in writing is repaid over time. You don't even have to take that much care and effort. The vast majority of the time, you only need to rebase WIP commits together into a single commit with a descriptive message. The effort of this is insignificant compared to the value of a meaningful, readable commit history.

Retric 5y ago
I personally spend significantly more time writing git commit messages than reading them. Spending lots of time looking at old commits is IMO a sign of poor code quality. Similarly, summarizing each change deserves some real thought so when you are reading these messages their actually helpful.
- SergeAx 5y ago
  When your codebase is 5+ years old and was written by 10+ engineers, 2/3 of those are not working here anymore, all you have is commit history linked to task tracking database. So it is naturally the first step of working on a new feature: get to know the subdomain, find corresponding sub-namespaces, look into commit history of those and find related task and specs. Or you may just punch in a lot of code in hope it will find somehow it's place in codebase and be consistent with other code and readable by your successors and won't break some edge cases not covered by autotests.
  - Retric 5y ago
    Interesting, I favor reading the entire codebase when possible assuming I am going to be working with it for a few months. I only start really looking at old commits only when I need to edit code that’s particularly brittle or incomprehensible.
    - Quikinterp 5y ago
      If I ever have to fix bugs I'll go and look at the commit history to see where it likely started. Especially if it was code that belonged to me but someone inadvertently commited something that broke it, that's why I like a nice commit history.

alecbz 5y ago

You should only ever do things when they're worth it. Which sounds obvious, but a lot of people argue for "correctness" of things in the abstract without tying back to why that correctness matters, how much its worth, and what the cost of getting it is. In the case of git, I think a) a good "published" code history can actually be pretty valuable b) git's UX is bad The fact that a tidy history is valuable should be totally independent from the fact that git's UI doesn't make it easy to do that.

simonw 5y ago

I've realized that as software engineers our work isn't writing code: it's changing code. As such, the unit of work that we produce is the code change. Which means crafting a good commit - with a good commit message - is key to our craft.

TimTheTinker 5y ago

> Some years ago we all went from svn to git and I am not really sure the improvement was worth it. I used svn for years before switching to git. Trust me, git is a huge usability improvement, even for use as an individual developer or small team. Merging in svn was significantly harder. Cherry-picking was unheard of, not to mention diffs and patches.

AtNightWeCode 5y ago

If you work with pull requests, as many companies does, it is essential that things go into separated commits. What junior devs often does is refactor something and then also add functionality in the same commit making it hard to understand if a change is an error in the refactoring or part of the new functionality.