Working with Git

[Marcel Bischoff]

On 16/10/07, Brandon Allbery wrote:
>On Fri, Oct 7, 2016 at 12:43 PM, Chris Jones <jonesc at hep.phy.cam.ac.uk>
>wrote:
>
>> On 07/10/16 17:39, Craig Treleaven wrote:
>>>
>>> On Oct 7, 2016, at 12:16 PM, Sterling Smith <smithsp at fusion.gat.com>
>>>> wrote:
>>>> On Oct 7, 2016, at 7:20AM, Chris Jones <jonesc at hep.phy.cam.ac.uk> wrote:
>>>>>
>>>>> My point still stands though, you have to actively try the things you
>>>>> need to do, to get used to them.
>>>>>
>>>> +1
>>>>
>>>
>>> Yabut, then you hear things like “use —force when you need”, except then
>>> you hear “—force can really screw things
>>>
>>  up”.  I’m a little gunshy of that screw-things-up part!
>>
>> Indeed, I was a little dubious of the suggestions that involve -force. I
>> suspect there are better ways of working that should avoid the need for
>> that.
>
>
>--force only comes into it when you are rewriting history (i.e. merging
>existing commits that were already sent upstream). Best is to not do this;
>work in a branch, combine commits after, and cherrypick those to *another*
>clean branch (or diff the first branch to get all changes as one patch, and
>apply it in the new branch to get a single commit). Or just accept multiple
>commits instead of trying to pretend to be a neat freak after hosting a
>wild party.

'push --force' should *never* be used when working in a team except for
dire emergencies like having cleaned the history of accidentally
committed login credentials or the like. It completely rewrites the
remote history of the repository, invalidating all local clones
immediately and leaving a mess for all collaborators. Git is designed to
work with branches whenever possible and 'merge' or 'merge --squash'
them when you're finished.