-
Notifications
You must be signed in to change notification settings - Fork 0
GIT'ing Started With Git
Welcome to the new world of GIT. This revision control technology is a two-stage system where you maintain local copies of your repository, commit to those copies, and then push changes to the "remote" server. In the git world, your remote is what we used to consider "The Server" in cvs and svn parlance.
With git, you will need to be familiar with your head revisions, branch names, and the concepts of forking repositories and then branching them. If this is your first time with any revision control system, welcome to the new world order. For you seasoned cvs and svn experts, you will be doing more branching than you likely ever did with cvs and svn. Just know that "cvs -j" is the equivalent of an upstream merge in git.
You must first FORK your repository. This will be your primary work horse from which you will request PR (pull requests) of the master team (those who can commit to the master head revision). You don't get to push to the master head unless you are annointed with the privilege from repo admin.
From the web site, I suggest you use the "Fork" link while you are at the mono/MonoGame home page. It will be quick.
Next you will see your page change to " myAccount/MonoGame ". This is your new fork identifier. It's an ACTUAL repository that is a copy of the upstream ( mono/MonoGame ) repository. NOTE that this fork is a zero-day operation, meaning that any changes to upstream are NOT automatically applied to your fork. You are now blazing your own trail and nobody can affect your work.
Now that you have a PRISTINE fork of mono/MonoGame, you need to branch it. First you make a working branch, which will be a scratch space you use to do dev work, experimental work, etc. This is where you bind your game for production release. You will NEVER, EVER, EVER, do a PR from this branch.
git checkout -b scratch
See: http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html
The checkout command takes -b as the branching command. The name you give your branch should be useful to yourself so you know that it is your scratch space for production use.
As you work you may find bugs or missing features in the source for MonoGame. When you do, log an issue for it. Then you create a branch from your PRISTINE fork with a name like PR865 referering to the Issue 865 that you just logged.
git checkout -b PR865
Then from that branch, you make your single, isolated, changes for Issue 865, commit (git commit), and PUSH to the remote (git push).
git commit -m'look what I did mom'
See: http://www.kernel.org/pub/software/scm/git/docs/git-commit.html
git push
See: http://www.kernel.org/pub/software/scm/git/docs/git-push.html
After you have PUSH'd your PR865, you need to get back on the github web site and issue a PR for your issue. There is a link "Pull Request" at the top of the screen. Click there, select your branch and select the target of your PR. This PR thing is a way for you to ask the admins to (1) review your changes, and (2) integrate them back into master.
All done, so you can go back to work on your scratch branch and continue on with your awesome game. Eventually someone will pull your PR, integrate, and grant you 1 minute of fame as a contributor to MonoGame. (high-five)
You should use the git shell or TortoiseGIT for these operations because it is safer, l33t, and will expose more tools for you to more effectively manage the branching and merging ( git mergetool ) of your PRs. The GIT client UI from github is pretty, but if it finds an error, it will just complain and say "no."
See: http://code.google.com/p/tortoisegit/
In all likelihood your first commit was probably a full file change set (every line changed). There is a global setting for the line ending fix up . You can use the GIT client UI for managing your repo settings, as that tool is pretty nice for it. Fortunately, since you did your change on an isolated branch, you don't have to worry about this line ending fiasco mucking up the rest of your future work, and your reputation as an experienced developer.
Next : GIT'n Some Updates