Add ability to create new Ideas

[florida]

This contains actions and tests for adding new Ideas and a feature test that checks if it works in the client side.

[dbernar1]

I've just created https://github.com/winnipegrb/winnivote/pull/24 and https://github.com/winnipegrb/winnivote/pull/23 , because either I'm seeing double, or there was some sort of a mixup when you committed the code.

I do not have advice about how to avoid something like this going forward, because git diff probably would not have helped here.. Perhaps it is related to Git and re-basing? FWIW, I don't remember ever re-basing, and I use git daily at work for the past ~2.5yrs, so it might not be the right tool for what you were doing, though I don't have no idea what you used re-basing for in the first place! :)

[swalberg]

It's a funny one, I see the same commits duplicated with different SHAs, so there might have been a rebase. Surprised you've never used rebase... It's the cleanest way to bring in changes from the parent branch (as opposed to a merge) and it's helpful for cleaning up your commit history prior to merging back to the parent branch (squashing).

If I can make it to the next meeting I'll offer to do a talk at the beginning on git branching/merging/pull requests.

[jeffreyfultonca]

I would like to hear swalberg present on git branching/merging/pull requests.

[dbernar1]

Don't be a little suckup Jeffrey ;D

Ya, I just git pull - I presume this is an alternative to that? Perhaps that's the solution to often having commits ala https://github.com/fbcpublishing/draft_review/commit/152849021a87f1ac014eafa74c4b47ee56617519 ?

[swalberg]

Pulling is a bit different -- it's a fetch from a remote repo and then a merge into the local branch. You usually use it to grab changes in a shared branch, e.g. master.

The merge commit is fine in master, it's an annotation that the merged commit(s) were from a feature branch. If you merge on GH with the web UI I think you always get one even if it's unnecessary.

FWIW, what I do most of the time:

# from within master
git pull origin master # Grab any changes upstream
git checkout mybranch # get into my feature branch
git rebase master # rebase master commits onto my branch

Rebasing doesn't work if I'm sharing mybranch with other people during development as it's rewriting history. If they're trying to contribute to the branch we'll have a big problem.

The other alternative is just to grab the latest commits:

# within mybranch
git fetch # grab the latest from origin
git rebase origin/master # update based on the origin/master

The downside to that is that if I want to look at master I have to pull or reset in order to "see" the latest commits.

If I'm sharing a branch with someone else I just do the git pull origin mybranch

For fun, run git log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit -- and see what it looks like on various branches. The more bubbles, the harder it is to figure out what has happened in the past. This is where squashing/rebasing/merging becomes important.