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
