Learn Git Basics in about 15 Minutes

Since most (all?) IgniteRealtime projects are migrating to using Git as version control, hosted on GitHub, I thought I’d share this with the community.

This is a quick tutorial on the basics of using Git. The tutorial is *not *GitHub specific, but rather is just a primer on using Git’s basic functionality. It will only take about 15 minutes to complete, so you can git (haha) it done on your lunch break

Funny, but maybe not the real world scenario which one will use.

Well, yes and no. You’re right, if you are contributing to a project, you likely won’t be initializing many new repos… however, the tutorial does show which git commands are common, and their basic use-cases.

Such as:

git status

git add

git commit

git branch

git checkout

git log

git reset

git merge

git pull

git push

When working with an Ignite repo on Github, after forking, the usual workflow commonly involves making new local branches, tracking changes and new files, committing and merging back into your fork’s master branch, from which you likely will issue a pull request.

These commands are really central to using Git. The tutorial will not make you a Git Wizard, and if you are familiar with Git already, there’s not much you will take away. But, we do have a lot of new members in the community, so spending a few minutes to learn some basics isn’t too bad

Many thanks Jason,

I use Git daily in my day job and never bothered to learn the commands. I just use TortoiseGit on my Windows dev PC. Just select the folder, right click and do a clone, pull, commit and push

I have some forked Git repos, but I still need to set them up properly. Commands for creating the first fork, syncing the local clone with updates from the Igniterealtime master to get an up-to-date clone would be more helpful for me.

No idea how to update the changes from master into my local clone with TortoiseGit even though I have it installed … I always use the command line.

Maybe we can create a short document (without long descriptions) with similar content:

# One time:
Open https://github.com/igniterealtime/Openfire and click on "Fork"
Open the git shell
git clone https://github.com/your-username/Openfire
cd Openfire
git remote add upstream https://github.com/igniterealtime/Openfire # Daily: Pull in changes not present in your local repository, without modifying your files
git fetch upstream
# Daily: Merge any changes fetched into your working files
git merge upstream/master # Create a patch/fix/new feature # create branch?
# merge branch into your clone?
# delete branch?
# create pull request?

I really recommend the free Pro Git book: http://git-scm.com/book

http://git-scm.com/bookIt’s the de-facto standard guide to git.

I believe using git via it’s command line is something everyone should do, as it’s really beneficial to your development workflow. Tortoise(SVN|Git) is a terrible abstraction.

For people like me who do not develop code every day a GUI is more easy to use. I use vi often but I would not recommend it to people who need to edit or write someting once a year.

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.

http://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/

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 git@github.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)

**5) **

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)

or

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.

1 Like

Image2.jpg

this was on hacker news (news.ycombinator.com) this morning:

Visualizing Git Concepts with D3:

http://www.wei-wang.com/ExplainGitWithD3/#

pretty cool… it’s a git work-flow visualizer.