Previous Lecture lect07 Next Lecture

lect07, Thu 04/22

Production pipeline. Feature-branch/pull request workflow

Announcements

Sprint Planning

Continuous Integration / Continouous Delivery (CI/CD)

Feature Branch / Pull Request Workflow

When making a change to your team’s repo, you should typically NOT be making changes on the master branch

Reasonable exceptions: small changes to documentation only (not touching code).

So what do you do instead?

Whoa, whoa getting ahead of ourselves: issue first.

WAIT.

Before you start working on a branch:

Once your team is in steady state, you should always be assigned to at least one in-progress issue on the Kanban board.

Ok, got an issue. How do you make a feature branch?

Like this. Always start with a fresh copy of master:

git checkout master
git pull origin master
git checkout -b thAddMenuItem

The th are your initials (the person making the branch). The rest is camel-cased and summarizes the purpose of the branch.

You could also come up with a different branch name convention, one that works better for your team.

The important thing is to have one.

Working on a feature branch

You may need, periodically, to push your changes to GitHub. Use the branch name in place of master:

Rebasing on master

You may need, from time to time, to rebase your branch on master.

This is to say, replay all of the changes on your branch on top of a fresh copy of master.

To do this, type:

git pull --rebase origin master

You may have merge conflicts. If so, you may find that you have to resolve these merge conflicts one commit at a time.

If all else fails, you can always type git rebase --abort to abort the mission and start over.

But if you stay focused, you can get through it:

Eventually, you’ll have a new version of your branch, at which point you’ll want to:

git push --force origin thAddMenuItem

Creating a Pull Request

When you create a pull request, which you can easily do through the github web interface, you have to select a base branch and a compare branch.

You are requesting that the admins of the repo pull commits from the compare branch into the base branch.

Once you create a Pull Request, you should:

Reviewing a PR

If you are asked to review a PR, please do so promptly.

Diplomacy is good… it’s better to ask questions than make statements.

I wonder if this code would be clearer if we factored out both the long if
part and the long else part into separate functions?   Choosing
some good names for those and some good parameter values might make this
code easier to understand.  What do you think?

vs.

This code is a convoluted mess---so complicated that no-one could
possibly make sense of it.  You need to totally rewrite this!

Both of these might be honest and understandable reactions to the same code. But one is much more likely to result in good team relations and team productivity. :-)

Today: