4 ms·

Spoken like someone who has recently learned git but doesn't have extensive experience using it in a production environment. Or perhaps I'm just becoming more c

Spoken like someone who has recently learned git but doesn't have extensive experience using it in a production environment. Or perhaps I'm just becoming more cynical with age.

chrischen 8y ago
Is there something wrong with doing it that way? I'm a solo developer so don't have the benefit of learning from corporate best practices.
- therein 8y ago
  Should work fine for a solo developer however I believe his point was that you shouldn't be re-writing the history. That is, what would be the next command you use? You have just done a hard reset and removed the last commit from the history. Now your remote and your local copy have diverged. You can do `--force` of course to rewrite the history on your remote but that wouldn't be acceptable in a corporate environment because many other people also have their local copies of that repository and they'll all have issues after you force your change in. A more transparent approach would be to do `git revert HEAD` or even better `git revert <hash>` to explicitly have your change be reverted with another commit.
  - chrischen 8y ago
    The deployment git shouldn't be making commits and should only ever be a slave to wherever it pulls from. Production git clone shouldn't be pushing commits upstream. So while it's running the previous version, you just `git pull` again to get the latest fixes for whatever broke at a later time. No history is rewritten as it fasts forward to the latest commit. I hope that clears up how it's used. As far as I know this is a common pattern of usage for deployment scenarios.
    - therein 8y ago
      For a deployment pipeline that takes the HEAD state on the git repo, you are right, that's perfectly fine. However if you have other developers or SRE that have that repo checked out, they'll have problems. Not problems that they can't take care of, but an additional step nonetheless.
      - chrischen 8y ago
        Let me clarify the scenario I'm using, as far as I can see there should not be anyone else touching the repo except production services that depend on it. 1. Push to somewhere (maybe a bare repo, or github/bitbucket). 2. Production clone pulls from the master. If any issues arise, you can do git reset --hard HEAD^ on the production repo to rollback any changes to an arbitrary prior version. > However if you have other developers or SRE that have that repo checked out, they'll have problems What do you mean by this? The production repo should only be read from by production services serving from it (webserver, database, etc). Any engineers shouldn't be making commits to it and merging upstream. It should be purely be used for deployment. I think maybe you're assuming the production repo is also the master repo? This is not something I recommend and if you use my deploy scenario, this is not how it would be setup. The production repo should just be a clone of the master, purely pulling updates from master just like everyone else, which can be on github or another bare repo that others work from. Except the production repo would also be a read-only repo. You obviously don't SSH in, make hot patches, and commit from there. Based on this, what I suggested (git reset --hard HEAD^) and having a repo deployed on the production server is a best practice for deployment. It allows for effortless roll back to arbitrary prior states, easy post-update hooks for build steps. And should upstream ever be updated, it's one command that just re-syncs (git pull) to any of the latest fixes for whatever went wrong.
chrischen 8y ago
Here: https://security.stackexchange.com/questions/45452/is-using-git-for-deploying-a-bad-practice https://security.stackexchange.com/questions/45452/is-using-... May want to catch up on some git yourself.

Spoken like someone who has recently learned git but doesn't have extensive experience using it in a production environment. Or perhaps I'm just becoming more cynical with age.

chrischen 8y ago

Is there something wrong with doing it that way? I'm a solo developer so don't have the benefit of learning from corporate best practices.

therein 8y ago
Should work fine for a solo developer however I believe his point was that you shouldn't be re-writing the history. That is, what would be the next command you use? You have just done a hard reset and removed the last commit from the history. Now your remote and your local copy have diverged. You can do `--force` of course to rewrite the history on your remote but that wouldn't be acceptable in a corporate environment because many other people also have their local copies of that repository and they'll all have issues after you force your change in. A more transparent approach would be to do `git revert HEAD` or even better `git revert <hash>` to explicitly have your change be reverted with another commit.
- chrischen 8y ago
  The deployment git shouldn't be making commits and should only ever be a slave to wherever it pulls from. Production git clone shouldn't be pushing commits upstream. So while it's running the previous version, you just `git pull` again to get the latest fixes for whatever broke at a later time. No history is rewritten as it fasts forward to the latest commit. I hope that clears up how it's used. As far as I know this is a common pattern of usage for deployment scenarios.
  - therein 8y ago
    For a deployment pipeline that takes the HEAD state on the git repo, you are right, that's perfectly fine. However if you have other developers or SRE that have that repo checked out, they'll have problems. Not problems that they can't take care of, but an additional step nonetheless.
    - chrischen 8y ago
      Let me clarify the scenario I'm using, as far as I can see there should not be anyone else touching the repo except production services that depend on it. 1. Push to somewhere (maybe a bare repo, or github/bitbucket). 2. Production clone pulls from the master. If any issues arise, you can do git reset --hard HEAD^ on the production repo to rollback any changes to an arbitrary prior version. > However if you have other developers or SRE that have that repo checked out, they'll have problems What do you mean by this? The production repo should only be read from by production services serving from it (webserver, database, etc). Any engineers shouldn't be making commits to it and merging upstream. It should be purely be used for deployment. I think maybe you're assuming the production repo is also the master repo? This is not something I recommend and if you use my deploy scenario, this is not how it would be setup. The production repo should just be a clone of the master, purely pulling updates from master just like everyone else, which can be on github or another bare repo that others work from. Except the production repo would also be a read-only repo. You obviously don't SSH in, make hot patches, and commit from there. Based on this, what I suggested (git reset --hard HEAD^) and having a repo deployed on the production server is a best practice for deployment. It allows for effortless roll back to arbitrary prior states, easy post-update hooks for build steps. And should upstream ever be updated, it's one command that just re-syncs (git pull) to any of the latest fixes for whatever went wrong.

chrischen 8y ago

Here: https://security.stackexchange.com/questions/45452/is-using-git-for-deploying-a-bad-practice https://security.stackexchange.com/questions/45452/is-using-... May want to catch up on some git yourself.