git workflow for D

[Mengu]

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? 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?

you can fork it, set dmd/master as upstream and then git fetch 
upstream. you can then rebase.

>
> And how does a pull request actually work? Is it a request to 
> merge my entire branch, or just some specific files? and do I 
> need a separate branch for each pull request, or is the pull 
> request itself somehow isolated from my changes?

commits can be cherrypick-ed or you can request your entire 
branch to be merged. it doesn't always have to be the master 
branch. for example, if there's std.experimental.logger branch, 
you can ask for your branch to be merged with that. having a 
seperate branch for each feature is most of the time the way to 
go. makes it cleaner for yourself. later on you can delete those 
merged branches.

>
> 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