gitlab-runner exec shell job_name
CHROME_HEADLESS=0 bundle exec rspec spec/features/projects/tree/create_directory_spec.rb
cd qa && bundle exec bin/qa Test::Instance::All http://0.0.0.0:3000 -- qa/specs/features/ee/browser_ui/3_create/web_ide/web_terminal_spec.rb
fitfor focused karma specs
cd sites/handbook && NO_CONTRACTS=true bundle exec middleman
git rebase -i master) and message cleanup via
fixupare worth learning more about if you are unfamiliar with them.
merge-base(the common ancestor of your branch
HEADand the upstream branch
master) from the possibility of "conflict resolution" when rebasing against the latest upstream
git rebase -i $(git merge-base HEAD master). This lets you do your interactive rebase against the
merge-basewithout any chance of having to deal with conflicts at the same time. Make sure that the
merge-basecommit is contained on your master branch (i.e. you didn't just fetch and checkout the branch directly without updating master). You could just
git fetchthen rebase against
origin/master, but this negates the benefit of using
git push --force-with-lease(Or just wait until after the next step to push if you don't want to trigger an extra unnecessary build)
git rebase master, to rebase against the latest master, and resolve any conflicts against your cleaned-up, interactively-rebased branch.
git push --force-with-lease(force-with-lease ensures nobody else has pushed to the branch since you last pulled)
When a branch has followed a merge instead of a rebase workflow, it can get very confusing to know what is going on, and you want to just squash it down to a single commit. But, you can't just do a regular interactive rebase relative to master if the branch has had master merged into it. Here's what you have to do instead.
Note there may be more efficient ways of doing this, suggestions are welcome…
Assuming branch is named
branch and upstream is named
git log master..branch --oneline
git reset --hard abcdef
merge --squashthe last commit:
git merge --squash 123456
git restore --staged .
git checkout .
git clean -df
Though the contributor and development docs are the single source of truth, there are some additional habits that may be worth developing when you're new to the code contribution process.
Depending on your existing habits and
git practices the habits below may help mitigate pain during code submissions.
Some frontendmasters workshops related to testing that I want to take after the web security workshop: