0

I have to deploy my code for third agency, as there has some previcy info in the old commit history. Though now I has add this previcy info to gitignore, but it's keeped in the old history.

So how to make the old history invisible to the third agency.

I've tried two below methods,

  1. make another deploy repo for deploying, remove .git, and init it as a new repo. Then add develop repo as remote, pick each new commit from it. Though this works, pick commit will cost too many time eachtime where has new commit in the develop repo.
  2. in the develop repo, squash all old commit, but there has too many commit, and has a lot of conflict in the squash process. And this will lost the old commit .

Is there a proper way to make it.

LF00
  • 27,015
  • 29
  • 156
  • 295
  • 1
    Is not enough to deploy on a new repo only the latest release, and update it each time you need to publish sources for that agency? – Antonio Petricca May 26 '21 at 05:44
  • Doesn't simple `git rebase -i commitish` work? Edit the older commit which has sensitive information and you should be OK. – Asocia May 26 '21 at 05:47
  • 1
    Does this answer your question? [How to remove file from Git history?](https://stackoverflow.com/questions/43762338/how-to-remove-file-from-git-history) – Gaël J May 26 '21 at 05:55
  • 4
    There is no way to "hide" history. Either it's there, or it's not. Your only option is to make separate snapshots into a new repository that you share with the 3rd party. – Lasse V. Karlsen May 26 '21 at 06:45
  • "I have to deploy my code" : do you have to share the commit history ? or just deploy the code of the latest version to some server that will execute that code ? – LeGEC May 26 '21 at 07:49
  • the commit history is not required. But I need to use it when update it. For example the database schema update. – LF00 May 26 '21 at 08:01
  • 2
    This sounds like an [X/Y Problem](https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem): your actual task is to _deploy some code to a production environment_. You have started trying to use git for that job, and found a problem: you don't want to copy the history to the server, but git is _all about_ copying history. Instead of finding a way to use git for something it's not designed for, look for _a more suitable process or tool_. That might mean changing how you do database migrations, if those are somehow tied to git history, but it's going to be less pain in the long run. – IMSoP May 26 '21 at 15:37

0 Answers0