git workflow for D

[Basile B.]

On Sunday, 3 December 2017 at 20:05:47 UTC, bitwise wrote:
> I've finally started learning git, due to our team expanding 
> beyond one person - awesome, right? Anyways, I've got things 
> more or less figured out, which is nice, because being clueless 
> about git is a big blocker for me trying to do any real work on 
> dmd/phobos/druntime. As far as working on a single master 
> branch works, I can commit, rebase, merge, squash, push, reset, 
> etc, like the best of em. What I'm confused about is how all 
> this stuff will interact when working on a forked repo and 
> trying to maintain pull requests while everyone else's commits 
> flood in.
>
> How does one keep their fork up to date?

Just push to your fork/master after pulling from the (shared) 
origin/master.

> For example, if I fork dmd, and wait a month, do I just fetch 
> using dmd's master as a remote, and then rebase? Will that 
> actually work, or is that impossible across separate 
> forks/branches? What if I have committed and pushed to my 
> remote fork and still want to merge in the latest changes from 
> dlang's master branch?

In a non personal project you NEVER commit to master. You make 
each single fucking change in a specific branch (sorry for the 
language, it's intentionally gross). the master branch is only 
updated when you pull from the origin.

> And how does a pull request actually work? Is it a request to 
> merge my entire branch,

Yes it's a merge. Optionally all the commits can be squashed.

> or just some specific files? and do I need a separate branch 
> for each pull request,

Yes, yes yes, again. ~master is sacrosanct.

> or is the pull request itself somehow isolated from my changes?
>
> Anyways, I'd just be rambling if I kept asking questions. If 
> anyone can offer any kind of advice, or an article that 
> explains these things concisely and effectively, that would be 
> helpful.
>
>     Thanks

The only article i've ever read about git was when the first time 
i needed to squash (actually i rather do "fixup" 99% of the 
time...) so i have nothing else to add.