The workflow I'm using in git to merge into the new test folder structure

The workflow I'm using in git to merge into the new test folder structure
0

I just did my first merge into the new test folder structure, and thought I'd share the workflow in case it's helpful to anyone. In my case, for Fortinet, we're using a "feature branch", so we're not merging directly into staging (fwiw, I think this is a good practice for any team to adopt). Eventually, once the feature branch is in a "ready state", we'll merge it into staging.


So, I've been working on IKP-1073-fortinet-high-memory-usage. It was using the old folder structure. Now, the pull request is done (and all the tests have passed), and I want to merge my IKP branch into the feature-fortinet-fortios branch (for you, this might be the staging branch). Here's how you can do it for your branch (assumes you're merging into staging):



  • checkout (switch to) staging
  • pull the latest from origin/staging into staging
  • checkout your IKP branch (for me it was IKP-1073-fortinet-high-memory-usage)
  • merge staging into your IKP branch
  • now your IKP branch should have the new folder structure, PLUS any of your working files that didn't get migrated, which are still in the old folder structure. So, you need to migrate your .ind and test files to the new folder structure, and re-create your test cases as needed (based on Eyal's instructions in the video: https://drive.google.com/drive/folders/0Bz32Q6fWxnLjLVJ3alRueGlpOWc)
  • when you're done with the migration, commit your changes in the IKP branch
  • Note: if it took a long time to do the migration, you should probably checkout staging, pull again, and if there are updates from staging, checkout your IKP branch, and merge staging into your IKP again, just to be sure you're %100 up-to-date with staging.
  • Push your changes to your IKP branch
  • Using your pull request, someone can now merge your changes into staging


In a situation like this, where you have a potentially complicated merge, I think it's a good practice to do this "back and forth merge" -- i.e., if you want to eventually merge <some_working> into <some_integration>, first pull <some_integration> and merge it into <some_working>. This gives you time and space to clean up the merge on your working branch, and makes it very easy to merge back into the integration branch (known as a "fast-forward merge").

Well done!

Thanks for sharing!

FYI

This is great Hawkeye. Thank you for sharing.

Thank you Hawkeye for posting this. Hopefully, you can share your "feature branch" experience with the team soon. Can't wait :-)

Thanks!

This is great!


Just note that you probably want to open a PR on your branch instead of merging it into staging on your own.