@christophpacher: I resisted git for a while, but it is really handy for collaborating with other oF users/developers! Even if you just make issues on my github repo that would help me to track the problems and document changes etc…I wrote up some stuff on collaborating with git earlier in this same thread - hopefully they will get you up and running.
Let me know if there is a good time for us to work together - a date that is convenient to visit Linz - and/or I’ll let you know when next I’m coming to Vienna!
[quote=“gameover, post:101, topic:7403”]
So on that note we first need to get you up and running with git…I’m afraid I do not usethe macosx client. I only use the command line - at first I found it a bit intimidating but it’s really fairly straightforward for simple things…and the process of having to type the commands does sort of make sure you think about what each one is doing.
There is a good git tutorial on forking here: http://help.github.com/fork-a-repo/
It’s a bit off topic, but to summarise the most useful git commands for collaboration (this assumes you’ve gone to my github repo and clicked on ‘fork’ already:
> cd ~/[pathtoyourof007]/addons
> git clone git@github.com:username/ofxOpenNI.git
> cd ofxOpenNI
> git remote add upstream git://github.com/gameoverhack/ofxOpenNI.git
>
>
That last command tells your local copy of your fork of the repo where to pull changes from it’s upstream parent (ie., my repo)
And then when you want to get my most recent changes you do a:
> git fetch upstream
>
Which will fetch all changes to all branches, or if you want to be more specific you can do a:
> git fetch upstream experimental
>
It’s best to make changes on another branch rather than in the branch of an upstream repository. In other words don’t go making changes in the master, develop or experimental branches that get downloaded to your local repository, as then you may easily have to deal with a lot of conflicts every time I update my repo. Instead:
Firstly change to the experimental branch:
> git checkout experimental
>
then make a copy of this branch:
> git checkout -b experimental-yourNameOrFeatureOrBugFix
>
The ‘checkout -b’ command makes and checks out a branch all at the same time.
Now go ahead and make a changes.
Use
> git status
>
To get a list of files you’ve changed and (if you added any files) any untracked files in your local branch.
If you added files you can do
> git add .
>
to add all files, or
> git add fileName.ext
>
to selectively add files.
When you’re happy with a change you do a:
> git commit -a -m "Some description of what you changed"
>
Then you can do a:
> git push origin experimental-yourNameOrFeatureOrBugFix
>
This will create and upload this branch to YOUR github repo.
Then you go to your github repo and click on pull-request. Make sure you change the branch you are making the pull request on to the correct branch. It will default to something like:
> You're asking gameoverhack to pull 42 commits into master from experimental-yourNameOrFeatureOrBugFix
>
Click on the bolded ‘master’ bit and type in ‘experimental’ on the left hand side to change to the right branch to make the pull request on.
Which should update the pull request to:
> You're asking gameoverhack to pull 42 commits into experimental from experimental-yourNameOrFeatureOrBugFix
>
If you haven’t made a pull request or finished your changes, but my experimental branch has been updated in the meantime, you do a:
> git checkout experimental
> git fetch upstream experimental
> git checkout experimental-yourNameOrFeatureOrBugFix
> git merge experimental
>
Basically these commands download any changes from my repo, change you into your branch and then tries to merge my latest changes with your branch. Hopefully you get a bunch of info about changes that have been made ending with:
> Automatic merge succeeded
>
If/when you get to needing to merge changes take a look at: http://book.git-scm.com/3-basic-branching-and-merging.html
Ok I think that’s enough for now…there’s lot’s of tutorials out there and there are some sightly more ‘safe’ ways to do the branching so that you always have a nicely merged version of code…but let’s see how you go with this first.
But essentially the idea is to avoid making changes on a local branch that is the same as an upstream branch name, and to make pull requests on either develop or experimental (depending on where you started making changes)…
I’m sure others can correct or elaborate on my git-lore 