• Zeth0s@lemmy.world
    link
    fedilink
    arrow-up
    33
    ·
    edit-2
    1 year ago

    I never push as last thing in the evening. I want to sleep over it and revise in the morning. --amend crew unite

    • Anticorp
      link
      fedilink
      English
      arrow-up
      8
      ·
      1 year ago

      You should be pushing feature branches as you work on them, so if you have a crash or something, your work isn’t lost. Builds should be triggered from pull requests on the main branch, if triggered by anything. You should never push directly to main. At least that’s my preference.

      • Zeth0s@lemmy.world
        link
        fedilink
        arrow-up
        5
        ·
        edit-2
        1 year ago

        Our ci/cd pipelines build also feature branches. I do push often, clean code. I don’t push when I am tired enough that I can’t trust my judgment that the code I am pushing is over my personal quality threshold. I add meaningful, concise commit messages. These are my rules.

      • TheManuz@lemmy.world
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        I make WIP branches only for that purpose, so I can push half done work and rework it the day after.

        This means a lot of history changes, but only in the WIP branch.

        When history is clean, I rebase the feature branch.

        Is this a good practice? I never found a better way to backup partial code.

    • Michal@programming.dev
      link
      fedilink
      arrow-up
      1
      arrow-down
      2
      ·
      1 year ago

      What if while you sleep over it your laptop gets stolen or damaged? I’d rather push every small change than sit on it.

      • Zeth0s@lemmy.world
        link
        fedilink
        arrow-up
        5
        ·
        edit-2
        1 year ago

        I would lose max 3 hrs of work that I already know how to re do. I can live with that. I don’t want to publish too much unfinished/unpolished work. There is always the chance someone might need the branch.

        Even if drafts under development, I like to publish something that reaches the standard of my “best” me, not my “Friday evening” me

          • Zeth0s@lemmy.world
            link
            fedilink
            arrow-up
            1
            arrow-down
            1
            ·
            edit-2
            1 year ago

            Because someone else might need to work on something on or from my branches. And I don’t want garbage in my history. There are cases I might not be able to squash merge, so all my history will be in the project history. I want each commit to be clean. It is not a lot of effort, and forces me to increase code quality, because I review my code more often.

            Rules for all projects I manage: never rebase published branches and always publish clean code (even implementation is unfinished).

            From experience following these simple rules make the whole project management easier and more effective

        • Michal@programming.dev
          link
          fedilink
          arrow-up
          1
          ·
          1 year ago

          On one occasion i had to take over a task from a colleague while he was on his day off. He did not push his changes. I am sure he had backups but when i asked him to push his changes he had to drive home to do it.

          I’d rather company IP stays on its git server.