austinEng
commented
6 years ago @joeyzia So for this, we want to include your commits, but not have all the stuff currently on develop. That will get merged in later. Here's how you do that:
git checkout travis-aws-configuration
git fetch origin
git rebase -i origin/staging This will allow you to select which commits you want to apply starting from the first difference from staging. You want to drop all commits except:
- "Changes in yml files"
- "Fixes"
- "Added CodeDeploy hooks and Start/Install scripts"
- "Editted environment variable naming convention" Furthermore, because it's generally bad style to have "broken" commits, it would be better to have a single commit instead of "Changes in yml files" and "Fixes". So you will want to squash fixes into "Changes in yml files" so they become a single commit.
Now do git log. You should see all the commits from develop removed. There should be my commit "Configure Travis gh-pages deployment" followed by three of your commits: "Changes in yml files", "Added CodeDeploy hooks and Start/Install scripts", and "Editted environment variable naming convention"
If all is well, do git push -f to forcefully update the branch. This pull request will update automatically.
@heallen Take a look at this as well! This is generally a good workflow for updating pull requests so we don't have a lot of commits that are something like "fixes" or "updates" or "changes" for a single new feature. Furthermore, I think it's better if each commit is an isolated change in it's entirety, so modifying a UI component should be in the same commit as modifying its snapshot. Not doing so would mean that some commits fail tests and some commits pass tests.
joeyzia
Integrated Travis and AWS configuration, scripts, as well as deployment code.