Skip to main content
20 events
when toggle format what by license comment
May 5, 2022 at 14:04 comment added CorwinCZ Your focus on solving this problem with git is pushing you to sub-optimal solutions. Try to rephrase your question to omit specific technology. Eg: "What is the best way to record which commit is currently deployed to which environment?" Such question could help you find better solutions :)
May 5, 2022 at 12:35 answer added Matthieu M. timeline score: 1
May 5, 2022 at 4:02 comment added Christopher Hunter It should be noted that resetting the remote live branch (or any remote branch) is generally bad practice in a shared environment, for exactly the reasons you describe. It's worth having controls in place to prevent this.
May 4, 2022 at 18:14 comment added Bart van Ingen Schenau If you use the git-flow branching model, then the top of the master branch should always exactly reflect what is currently in production. And the master branch should indeed be configured to accept only pull requests (from a release or a hotfix branch).
May 4, 2022 at 14:20 answer added Edgar Bonet timeline score: 3
May 4, 2022 at 14:15 answer added Graham timeline score: 4
May 4, 2022 at 14:06 answer added R.. GitHub STOP HELPING ICE timeline score: 12
May 4, 2022 at 12:55 review Close votes
May 9, 2022 at 3:09
May 4, 2022 at 12:21 answer added Stack Exchange Broke The Law timeline score: 1
May 4, 2022 at 7:06 comment added ojs Or more generally, it's far easier to record in production which git commit the deployment is from than the other way around.
May 4, 2022 at 3:00 history tweeted twitter.com/StackSoftEng/status/1521686126683209729
May 3, 2022 at 19:08 comment added Bakuriu I don't understand your problem... Say you deploy your code as docker containers. You would build a docker image that ends with the commit hash. Then you can just look at the name of the running live image and checkout the commit hash. This works even if you have a broken update and have some containers with a version and others with a different one, you can easily distinguish the two and checkout both of them to troubleshoot deployment problems, what you suggest only works if deployment always work.
May 3, 2022 at 18:01 history became hot network question
May 3, 2022 at 11:50 answer added Greg Burghardt timeline score: 77
May 3, 2022 at 11:06 answer added pjc50 timeline score: 7
May 3, 2022 at 10:46 comment added Stack Exchange Broke The Law note that git checkout live checks out the developer's branch live which is not necessarily the same as the server's branch. By default if it does not exist it will create one based on the server's live branch. But I think if you use e.g. git checkout origin/live then it will always check out what's on the server, and warn the developer that the branch won't be updated if they commit because it is not their machine's branch.
May 3, 2022 at 10:43 comment added Robert Elliot Binary built from commit 5 deployed to live. Remote branch live -> 5. Developer git checkout live. Local branch live points to 5. Live rolled back to binary built from commit 3. Remote branch live -> 3. Developer git checkout live && git pull. Local branch live still points to 5. Or worse, someone decides for whatever reason to deploy a binary built from a commit that is neither an ancestor nor a descendant of 5. git checkout live && git pull now asks you to merge.
May 3, 2022 at 10:33 comment added Stack Exchange Broke The Law I don't understand the problem you have with branches. If the live environment rolls back, why shouldn't the live branch also roll back?
S May 3, 2022 at 9:59 review First questions
May 3, 2022 at 11:22
S May 3, 2022 at 9:59 history asked Robert Elliot CC BY-SA 4.0