0

So brief story I'm managing a GIT repo of some code for an application. The application does not have any tests. One of the developers merged a feature branch directly into master and Jenkins deployed it to stage. This feature branch has weeks worth of changes and was merged several times into master branch. So I come back from vacation and find some functionality broken and added functionality not ready for primetime. I managed to tease out the bad code by reverting merges and commits. I want to run this fixed code base and manually test the crap out of it. The PM wants to take whats on live and drop it into the GIT repo. This seems so wrong. Does anybody have any other solution or comments?

Clutch
  • 7,404
  • 11
  • 45
  • 56
  • 1
    You you unsure about content after the teasing out, just use `git diff master release` to see difference if any and investigate it. – kan Aug 16 '12 at 21:36
  • Wait, are there changes on live that are not in the repo? – willoller Aug 18 '12 at 01:08

1 Answers1

1

I did not understand what the PM wants to do.

Though I believe a "well maintained" Git repo has one branch per feature, including the fixes, which is merged once it is stable and passed tests.

I know and imagine how hard it is to stick to that. So I guess what you now have is a repo in which you have no idea what any commit may represent since it's messy and you added reverts (personally I think reverting should be avoided when possible).

So you want to have something stable? I would recommend, even though I have very little experience of it, to start from a stable commit in the history. Branch from it and call it "stable", that will become your main branch. Merge successively from commits that introduce new features, or bugs. For each, commit fixes until it is stable and rebase to have these fixes before the next bad commit.

For example, before:

A(stable) - B(feature1, bugged) - C(feature2, more bugged) - D (worse)

after:

A - B - B1 - B2 - C - C1 - D - D1

(so that A, B2, C1, D1 are stable milestones). Overall, you can play with rebase, merge and cherry-pick to perform what you want to do. This article : Git Cherry-pick vs Merge Workflow tells you that you'd better use merge if you are not comfortable with the others, but there are little differences that are very useful.

Hope you'll solve your problem

Community
  • 1
  • 1
Vince
  • 1,570
  • 3
  • 27
  • 48