-
Notifications
You must be signed in to change notification settings - Fork 5
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 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.
You must first FORK the mono/MonoGame 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 anointed 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.
If you intend to keep your fork up to date with the fast pace of the main repository, then you need to add a remote. This is done with a single command:
git remote add upstream https://github.com/mono/MonoGame.git
The repository URL is case sensitive, so if you mistype it, you will need to edit the ".git/Config" file and correct your syntax error. It will be obvious where your remote is referenced. You can't use Notepad to edit this file, so get a different plain text file editor that understands mixed line endings.
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.
You can also work on your own main branch, but remember to set the New Branch option when you commit. This is where the Git GUI is nice. Using TortoiseGit you can set the new branch name during your commit and then push your changes back to the origin (your fork at github) with the same branch name.
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)
When you are ready to update your fork with the lastest revision, make sure that you have the remote added, as mentioned above:
git remote add upstream https://github.com/mono/MonoGame.git
Next you follow these steps:
git fetch upstream
git merge upstream/develop
Fix any merge conflicts that are reported. Be mindful of this step because you don't want to commit conflicts into your local HEAD. Note that if you make changes to fix merge conflicts, then you will need to commit your changes to the local repository before you can push:
git commit -a
I suggest using "-a" so that all of the changes are pushed. You should again be mindful of this step just in case you want to use different merge notes for your conflict resolutions.
Next you need to push your local changes back to the github repository, called the 'origin'. You do this using the "git push" command, as in the following:
git push origin develop
The final push will set your origin's develop branch in sync with the main repository's develop branch. Once you are here, make sure that you update your working copies by dumping them in the trash and doing a fresh checkout of your origin/develop branch.
Let's say you didn't follow the directions and you have some dangling commits on your repository that are getting in the way. If you want to remove commits, you must use the reset command:
git reset --hard HEAD~1
This will move your head back one commit (hence the ~1). If you want to go back 2 commits, then ~2 is the option to use. The pattern continues beyond 2 to as many commits as you want. This only affects your local copy. If you pushed your bad commits up to github (they will show up on github.com), then you need to do the following as well:
git push origin HEAD --force
This will flush out the commits on github for your repository and get you back on track to making clean commits and PRs.
All of the commands that you will likely ever need in your journey to stardom, fame, and game development bliss, are the following:
git remote add upstream https://github.com/mono/MonoGame.git
git fetch upstream
git merge upstream/develop
git push origin develop
git add [files changed]
git commit -m "some keen and clever message"
git push origin develop
git reset --hard HEAD~1
git push origin HEAD --force
http://stackoverflow.com/questions/1338728/how-to-delete-a-git-commit