Other projects will be converted to Git within Dawn-of-Light Organization.

Git Software

Git is a distributed code versioning system, there is no centralized repository like in Subversion, every user work on its own repository copy and can use all git command "offline", once your code edits are ready for publishing you can push your commits to an online repository or share it with your coworkers directly.

All remote references are handled as Branches, so you can switch between them easily to retrieve code or logs, or you can merge them to your local copy/branch to follow code changes.

Now you have your own copy of full Project History in your account, you can do anything you want without breaking anything in official repository !

You can now CloneYour repository locally to begin any work (or even use the few tools available from GitHub web view) and start creating your own branch for modification, keeping "master" branch even with DOL official repository so you can easily merge your work with current source.

We create a Clone repository of Remote Fork, then create an own branch "working".We set an "upstream" remote reference to Official Repository so we can update our Fork with upcoming changes.

For TortoiseGit User's, it's pretty much like working with TortoiseSVN, you just use Git Contextual Menu to Clone the repository with GUI options :

You are now working in your own local branch, you can make some changes to any file save them and try your first commit.Git use a "Staged Area" where modifications are tracked but not committed to repository, using TortoiseGit you can still use "old style" commits which will auto-add modified files, using command line you have to explicitly add your files to staging area or auto-add them on commit.

The workflow is : Edit your working branch, commit to your working branch, switch (checkout) to master branch, fetch and merge upstream master branch so you have an up to date branch to Project Official repository, then merge your working branch update to the local up to date master, finally push the change to your user repository on GitHub so you can start a Pull Request !

From there you can use GitHub Web to create your Pull Request :

If you only make atomic changes and don't want to use all the working branch workflow you can still edit directly your Fork's master branch and produce Pull Request, you can run in some troubles if you heavily edit your Fork's master and your changes are not pulled into official repository, later upstream Merge will become difficult...

Simply switch to your working branch and merge any change you may have "pulled" from upstream

Set your Authoring Identity for Subversion Commit

When migrating Subversion to GitHub, it needs Author E-mail mapping to match the correct GitHub account to Sourceforge username...Subversion repository have a lot of inactive contributors, so I used the Sourceforge mail alias for most of users.

The Sourceforge alias should be something like [sf-username]@users.sourceforge.net and forward to your private registered Sourceforge email, this way you can confirm in GitHub you are the owner of this account !

GitHub allows a pretty efficient Patch Merging process using Pull Request, in subversion you had to build a patch file matching all your change, then transmit this patch to someone with Commit Rights to apply it to current SVN source tree, if you were not a registered contributor, and the authoring was made with the committer credits...

With Git the "Rights Management System" only apply to the Centralized Official Repository, but you can do any updates in your own repository (Forked) or local repository (Cloned on your computer), you have the full range of Git versioning tools available just for you, and Git is made to follow distributed change so you can easily export your updates to an other user repository or the Centralized repository (if any...) especially if you share common references (updating a Clone/Fork)

GitHub has build a specific workflow around remote branch Merges, which is the process of upgrading someone else Git repository with the exported updates you made to a common source tree, this is the Pull Request

The main steps to do this is simply using the GitHub Web, browse to your own forked repository containing updates, use the New Pull Request button and start comparing your changes to Official Repository to make sure it match the update you want to provide to current Code Base, then you just need to add Title/Description and provide some explanations for your update, this will immediately create a "Ticket" to the main repository tracking this patch to be imported in main source tree, and give all the proper credits to whomever contributed even after the patch is merged in official repository.

You can then display your pull request Status in Official Repository, this will sum up all the contributors working on this "Ticket", what commit is being exported, display differences between files involved in patch, and finally, thanks to Continuous Integration Service, your patch will be automatically tested on the current source tree to make sure the resulting Merge will be able to build or even run Unit Tests, this will provide a good starting point to prevent any patch from breaking the source tree

This "Ticket" is working some way like an "Issue" Ticket or other bugs report tracking systems, we can discuss on it, add more code update to improve the merged patch, choose to apply it or discard completely...It's way more efficient than forum topics/posts to track code patch, and it's integrated nicely into GitHub with all references needed to Git Repository (and continuous integration is really a powerful tool !)

GitHub Wiki and Issues

GitHub offer a Wiki repository for every project, even if this is not a powerful Wiki engine, it works with simple MarkDown Syntax and allow to share and update documentation with a pretty efficient Web access.

Every Forum Topic with How-to Guide, Any user provided Article or any Tips and Tricks resource can go in there, we'll worry about how we sort such data when we'll have some !

Some of the first needed article would be new guide on how to build or use DOL from GitHub repository !

GitHub also offer an efficient Issues Tracker, well DOL have so much issues right now I don't know how it could be fit in this...

Please try to use the Issues Tracker for identified bugs with as much data as you can provide on how to fix the issue, I don't think we'll be able to fix pretty hard bugs any faster by tracking them, but maybe "whole" feature request could fit in there

And don't forget, GitHub have some social Features ! You can Follow People to receive notifications, you can "Star" Projects to keep updated, you can comment almost everywhere

Concise, clear, understandable, excellent work ! /worship -- i'm totally aware GITHub workflow will need to be mastered by beginners. To ease this, i'll assign to a key for fasters answers on this forum : URL of this guide and https://guides.github.com/introduction/flow/index.html