0

In preparation for the first day of the fourth month of the year, I've added some, uh "new features", to the dev branch of our code.

Upon discovering these features, the first thing my coworkers will do is look at the commit logs to find what changed (and undo it). I could make the changes directly to our deployed code, but then they would be overwritten on the next deployment (which deploys from our DEV branch).

Is there anyway I can commit the code to our DEV branch without leaving any obvious signs? Or if not, at least making it a little more difficult for my co-workers to find the exact code that was altered?

BrianHVB
  • 1,764
  • 14
  • 34
  • You can do everything locally without pushing it. Then push it when you want them to know – evolutionxbox Mar 31 '21 at 15:04
  • 7
    One of the main goals of version control systems is to prevent what you're trying to do. Everything commited becomes visible to everyone with access and they can track what changed, when and by whom. – Alejandro Mar 31 '21 at 15:06
  • @evolutionxbox .. that won't work. It is a web app, so in order for them to see it, it will have to be deployed to our development environment, which means either a) it is part of the DEV branch and gets deployed, or b) I make changes directly on the application server, but then they get overwritten during the next build (which happens dozens of times each day) – BrianHVB Mar 31 '21 at 15:07
  • 2
    that would, um, defeat the whole purpose of git in the first place. If this is a work environment, I would try to solve this on an organizational level. In other words, solve the issue with your coworkers. And if the issue IS actually your code, solve that. – Dirk Trilsbeek Mar 31 '21 at 15:08
  • Your intention is to defeat the purpose of having a version control system. git doesn't allow that IMHO. any single commit is your culprit. – Asif Kamran Malick Mar 31 '21 at 15:09
  • 1
    git can't possibly distinguish between your funny goal and a totally malevolent one. – Romain Valeri Mar 31 '21 at 15:16
  • The best you can do is [change the author info of commit(s)](https://stackoverflow.com/questions/3042437/how-to-change-the-commit-author-for-one-specific-commit). But I'm not sure if that really helps your cause. – Asif Kamran Malick Mar 31 '21 at 15:23
  • 1
    I'm tempted to say that this is the answer to the question: https://workplace.stackexchange.com/a/69494 – legoscia Mar 31 '21 at 15:43
  • You can rebase the dev branch and add the changes to some commit you already made. Evil. – KamilCuk Mar 31 '21 at 15:44
  • @KamilCuk - that sounds perfect. What rebase arguments would I use? I'm assuming I would check out and old commit, then make some changes, but not sure how to apply those back to master. – BrianHVB Mar 31 '21 at 20:59

1 Answers1

1

that sounds perfect

You can rebase the dev branch and add place the changes to some commit you already made. It would be evil, tho.

If you do not know how to rebase yet, rebasing is a basic git operation and you should definitely learn it. My workflow would look like this:

  • Checkout newest dev branch.
  • Edit the files you want to do.
  • Add the changes and create them with some irrelevant commit message, like git commit -m "Rebase me".
  • Find a commit that you made in gitk.
  • Then interactive rebase up until your commit like git rebase -i <commit_sha>^ like git rebase -i 165b520 but you can also git rebase -i --root.
  • Remove your commit line with Rebase me and move the line below your commit (in vim dd removes a line, p pastes the line below current line, P pastes line above current line).
  • Change your commit from pick to fixup (in vim place cursor on beginning of the line and type cwf<esc>).
  • Quit editor (in vim :wq or ZZ).
KamilCuk
  • 96,430
  • 6
  • 33
  • 74