git workflow for D

[Jonathan M Davis]

On Monday, December 04, 2017 12:02:37 Ali Çehreli via Digitalmars-d-learn 
wrote:
> On 12/04/2017 09:38 AM, Patrick Schluter wrote:
>  > So, avoid pull, look first what fetch does and if that is what you
>  > thought it would do, do the merge and be happy.
>
> +1
>
> Paraphrasing someone I trust very much, "Never 'pull', always 'fetch -p'
> and then rebase."

I use pull all the time, but it's always pulling master from upstream, and I
never make any changes to my local master; all my changes go on branches.
Using github or gitlab, I really don't have any other reason to pull or
fetch, because the only place that I normally care about getting code from
is upstream master. Any code being merged from someone else is merged into
upstream master via github/gitlab, and my code is all done on separate
branches that get pushed up to github/gitlab to be merged. With different
workflows (like sharing work directly with someone rather than using github
or gitlab), I could see reasons to be wary of pull, but in the typical
workflow with github/gitlab, I really don't see any reason to be wary of it
- not when the only time it's needed is to sync my local master with the
main one on github/gitlab.

- Jonathan M Davis