I had a much much longer reply, but my browser crashed and ate it, wasting about an hour of careful proof checking to make sure I had all the details right. I'll do a more detailed blog post later
thelusiv Wrote:Here's something I'm interested in hearing about. Let's pretend for a moment that VDrift was already on GitHub (with a few branches: master, development, and last-release) when you started your fork there [1].
What kind of workflow would you have used?
I'd already have a copy of the working true, so I'd make a branch locally.
I do my changes in that branch, committing locally very frequently, getting new change with git fetch origin; git rebase less frequently, but probably at least daily. Yes I know I said don't use rebase too much, keep reading.
When I want to publish my changes, having rewritten my change history as often as is convenient, fork the project on GitHub, set up the remote. Push it, make the beats go farther.
Submit a pull request. This is basically a memorandum to the project saying "get my changes please." Using GitHub, this creates a "Pull Request" "Issue" that anyone can comment on. Otherwise, it's just like any email.
thelusiv Wrote:What kind of workflow could NaN have used to incorporate your changes into the development branch?
Add the remote, pull changes into a new branch (on his local repo), Ideally perform necessary changes (eg. if I interpreted the coding style wrong in places) in that branch and merge it into development, then push to the main repositroy on github. Alternatively, if there are some commit's he's happy with and others that can't be used for some reason, git has a cherry-pick command that allows him to import particular commits into the development branch and make further changes where necessary.
As a foolish last resort, it's also possible to directly compare the two branches, import all the changes in one commit, and bugger up everyone's change history. He wouldn't want to do that, though
thelusiv probably also should have Wrote:You made a boo-boo, or have further changes or something, what do you do now?
This is where the "merge is better than rebase" comes into play. Let's imagine that the main development branch has all my changes, and some corrections. If I now do a rebase off that branch it's going to create lots of confusion and possibly install some merge conflicts that make no sense â although the biggest problem I'd face would come when it's time to push again, because git will complain mightly about a the remote branch not being an ancestor, and while you can force it through it means that anyone pulling my branch into the main repo again is going to face the same problems. So, the very first thing I should do, is merge the development branch again locally. I can now make all the changes I want, but it would be very painful to try ever rebasing on this branch again, because every time I try to rebase against the remote development the first thing I'll have to work around is the possible conflicts of that merge. So when I want to update, I merge again. This has the effect that every time I sync my branch with the main development one, a new merge commit is visible in my branch and anything that pulls from it. But don't worry, git is designed to work with these â it won't duplicate commits.
In any case, probably the best strategy is to merge once at the beginning of a block of work, and once again before pushing it to my github repo, thus minimizing the number of conflict resolution (large snapshot) commits.[/list]
