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
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)
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.