I guess I’m one of the last command line ninjas!
A document would be a good idea, at least showing for each project the basic commands to get going.
The GUI tools are nice, until you need to do something slightly more complex than they allow (like use upstream repos). Git is a very powerful tool and can do a lot of really neat things. Github has a decent GUI client as well for win, mac, linux, and now android and ios.
“Fork” and “Pull Request” are Github terms, but basically it’s an abstraction for cloning the original repo (to under your github account), and then working off your clone and eventually submitting a request for the upstream maintainer to “pull” your changes in. For resyncing your forks with the original master repo (upstream), you would need to add a new remote to your repo.
git remote add upstream <the_upstream_git_repo_url>
then you can do things such as
git pull upstream master
which will pull down changes and fast forward your repo. This essentially does a merge of the upstream master into whatever repo/branch you are currently in. As with most things, there are multiple ways to skin the [octo]cat. (github refrerence lol). Sometimes you may want to use git rebase instead.
Merging brings two lines of development together while preserving the ancestry of each commit history.
In contrast,** rebasing** unifies the lines of development by re-writing changes from the source branch so that they appear as children of the destination branch – effectively pretending that those commits were written on top of the destination branch all along.
I tend to prefer merge/pull upstream to get the latest changes, but sometimes it’s not desirable.
My workflow genreally involves lots of beer , and both github button smashing, and some git command line-fu.
1) Click the Fork button on the repo I’m interested in.
2) git clone email@example.com:igniterealtime/Spark.git
3) git branch -a (and) git status (get our bearings)
4) git checkout -b myNewFeatureOrBugFix (creates a new local branch for me to work in)
6) git status (and) git diff (see what’s been changed, sanity check)
7) git add . (git add . will add everything that’s either untracked, or changed. sometimes that’s not desirable, in that case, you can add individual files with git add the/path/to/the/file and wildcards are acceptable)
8) git commit -m “My super awesome commit message”
9) git status (sanity check to make sure nothing was forgotten)
10) git push -u origin myNewFeatureOrBugFix (this creates a new branch on my fork’s remote, in github)
git checkout master
git merge myNewFeatureOrBugFix (this will merge my new feature/bugfix into my fork’s master branch)
git push -u origin master (and now we pushed our merged changes back to the fork’s master branch)
11) Now I go to github, and click the Pull Request button and write a description about the pull request for this commit. Then sit back, relax, and wait for the pull request to be reviewed by the repo maintainer/lead.
at least that’s the (basic) general idea.