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.
