Don't be like jimmy... test before committing! πŸ˜‹

  • 5
    Happens all the time :')
  • 10
    This happens so often. My commit comments must be so embarrassing to look back on.
  • 6
    This happens to all devs at least once in their life time
  • 6
    Always test before committing.
    But when that fails, rebase your commits to clean up your history.

    (Disclaimer: I'm assuming this is git, since the screenshot looks like github)
  • 5
    I can't even explain how many times I have a series of commits that are basically "here's the thing" and "actually committing the thing"
  • 4
    That guy needs to learn about rebase!
  • 1
    @DoctorWhatIf yep, this is git.
  • 1
    @Yankeesrule a ninja rebase or a reset of the last commit to delete evidence hoping that the change has not been pushed yet
  • 0
    Correct me if I'm wrong, but it's a bit hard to revert a commit that has been pushed to the remote, isn't it? @m93mark
  • 0
    @dreik It's not hard at all. You just need to force push it afterwards (which is destructive and can screw stuff up if you're not careful).

    The problem is if someone pulled those commits already. Then other people's local history will be different from the one in the remote repository, and git will throw a hissy fit when they try to pull the new changes.
  • 2
    @DoctorWhatIf yeah, that's what I thought too. It won't be much of a problem for a single person project, but could be near impossible in a team project. Anyways, better to test always before pushing.. ;)
  • 5
    @dreik It can still be good in a multi-person project, as long as everyone is pushing to their own branches (and amending, and force-pushing, etc) before pushing that work into the master branch (where others can get it).

    At my current job each developer has their own repository (fork of the main one) and can only push changes to be released via a Pull request. Until that is merged, it's usually fine to fiddle around with history. After that, it's set in stone.
  • 1
    @DoctorWhatIf thanks for sharing that info. Wish there was a direct message feature. I would really like to know more about the git workflow at your place because we also just started using git. so we are looking for ways to improve and optimize our workflow.
  • 2
    @dreik Well, ours is fairly straightforward.

    We're using GitHub. There we have the "company" account (with restricted access), which has the production-ready code.
    When working on a feature, a developer forks the appropriate repository, which creates a copy of the repository under their account. In that repo they do whatever they want (feature branching, etc.)
    When a feature is completed, the developer creates a Pull request into the master branch of the "company" repository.
    The creates pull requests then trigger the Continuous Integration flow (using teamcity) that will build th code and run all tests.
    Once the code is reviewed the PR is merged and that triggers a deployment to the acceptance environment, followed by production.

    You could also achieve the same under a single repo if every developer had their own branch(es) and *no one* pushed onto master.

    Is that clear? Feel free to ask any questions, I'll be glad to answer them if I can.
  • 1
    @DoctorWhatIf yep, with you so far. We are using GitLab currently. We haven't yet looked into CI. Thanks for all the info. I really appreciate it. Can I bug you with few more questions?
    Do you guys use a project management/ task management system? And how do you allocate time for tasks? Just estimating or are you guys using any technique for that?
  • 0
    @dreik As I said, ask away ☺️
    We use JIRA (from Atlassian) as our management system.
    We don't assign time though, we just estimate complexity (we're using Scrum here). So, we have some baseline stories we use to anchor our estimations of new ones.
    The only "technique" we use to estimate is Planning Poker, where every team member has a deck of cards with point values on them, and everyone shows their estimations at the same time (to avoid bias). If there are differences, we then discuss them to reach a consensus.

    PS: I also heard good things about, but never tried, the Hamburger Method for splitting user stories better, in order to estimate them more easily: https://gojko.net/2012/01/...
  • 1
    @DoctorWhatIf I'm gonna check these out now. I've earned about things like planning poker, but haven't used it actually. Thanks Mister Doctor πŸ˜‰
  • 0
    Oh and I'm reeallyy close to getting my first stress ball... yay for me!! πŸ˜„
  • 1
    @dreik No problem friend! Glad I could help!
  • 1
    @dreik Good luck on those last upvotes!
Add Comment