Using `--force-with-lease` allows one to force push without the risk of
unintentionally overwriting someone else's work.
The git-push(1) man page states:
> Usually, "git push" refuses to update a remote ref that is not an
> ancestor of the local ref used to overwrite it.
>
> This option overrides this restriction if the current value of the
> remote ref is the expected value. "git push" fails otherwise.
>
> --force-with-lease alone, without specifying the details, will protect
> all remote refs that are going to be updated by requiring their
> current value to be the same as the remote-tracking branch we have for
> them.
>
> --@calleerlandsson
> -- https://github.com/thoughtbot/guides/pull/363
Autosquash makes it quicker and easier to squash or fixup commits during an
interactive rebase. It can be enabled for each rebase using `git rebase -i
--autosquash`, but it's easier to turn it on by default.
Say I have this history:
$ git log --oneline
aaa1111 A first commit
bbb2222 A second commit
ccc3333 A third commit
I make another change that I already know should be squashed into "A
second commit". I can do this:
$ git add .
$ git commit --squash bbb2222
[my-branch ddd4444] squash! A second commit
Then when I rebase:
$ git rebase -i origin/my-branch
The interactive rebase list will be set up ready to squash:
pick aaa1111 A first commit
pick bbb2222 A second commit
squash ddd4444 squash! A second commit
pick ccc3333 A third commit
Since it's unlikely that anyone will be writing a commit message that begins
`squash!` or `fixup!` when they don't want this behaviour, and the user
still has a chance to review what's going to happen with the rebase, it's
safe to have it always turned on.
* Lists all remote branches
* Sorts by last commit date, descending
* Shows how long the branch has been around
* Shows last commit author
```
$ git branches
6 days ago Dan Croak origin/HEAD
6 days ago Dan Croak origin/master
5 months ago Dan Croak origin/dc-rbenv-zsh
6 months ago Sean Doyle origin/sd-nvm-path
6 months ago Tute Costa origin/vim-multiple-cursors
7 months ago Sean Doyle origin/sd-vundle
8 months ago Sean Griffin origin/sg-disable-spring
9 months ago Mike Burns origin/mb-experimental-tag
```
Using the `commit.template` setting, read in a commit message template
for each commit. This template is commented out so the commit message
author doesn't need to delete it.
The template serves as a reminder on how to write a better commit
message. The bullets are taken from Caleb's blog post[1]. There is no
_problem_ per se -- we are writing good messages these days -- but it's
handy to be reminded of things to think about. For example, people often
forget to note whether there are any side effects.
This message does not show on `git commit --amend`, only normal `git
commit`.
[1] http://bit.ly/13HWyiy
@jferris:
This has the effect that Git will never implicitly do a merge commit,
including while doing git pull. If I'm unexpectedly out of sync when I
git pull, I get this message:
> fatal: Not possible to fast-forward, aborting.
At that point, I know that I've forgotten to do something in my normal
workflow, and I retrace my steps.
@gylaz:
I like the value of seeing a failure message if a pull (or just merge)
fails due to not being able to get fast-forwarded. Then I can look to
see whose changes went out, that I may have not expected to be there.
* Fast commits.
* Fast rebase of origin into feature branch.
* Fast merge feature branch into master.
* Fast branch creation.
* Fast branch deletion.
Conflicts:
gitconfig
