"GitQuickstartTips" . . "GitQuickstartTips" . . . "---+ Git Quickstart\n\n%TOC%\n\nIn order to get started with developing follow the simple steps below. To learn\nmore about the git policies used for VOS read [[VOSGitUsage][Git and VOS]].\n\n---++ Cloning the repository\n\nGit is a decentralized VCS. As such one maintains a complete local copy of the\nrepository - a clone.\n\n\n> git clone git://github.com/openlink/virtuoso-opensource.git\n\n\nThis will clone the repository into sub-folder virtuoso-opensource.\n\n---++ Working With Branches\n\nGit's main concept is the branch which is essentially just a label for a commit.\nThe default branch is called =master= and (following the VOS git policies, other\nprojects may use different policies) always points to the latest stable release.\n\nList the remote and local branches with\n\n> git branch -a\n\n\nIn order to start developing we need to checkout another branch. Here we use the\nmain development branch of Virtuoso 6, \"devel/6\". Since this is the first time\nwe check the branch out locally we need to tell git that we want to track the\nremote branch.\n\n\n> git checkout -t remotes/origin/devel/6\n\nThis creates a new local branch \"devel/6\" which tracks remote branch \"remotes/origin/devel/6\".\n\nFrom here we create a new branch in which we will do our actual development.\nDepending on the type of development this branch is prefixed with =feature= or\n=bugfix=:\n\n\n> git checkout -b feature/myFancyFeature\n\n\n--++ Committing Changes\n\nNow we do our development and regularly commit to the local branch. We try to\ncreate nice self-contained commits with good commit messages. There are several\nways of commiting code. The easiest is to specify the files and folders to\ncommit directly. However, caution should be taken with commiting whole folders -\nevery file in the folder will be part of the commit, independent of its state.\n\n\n> git commit \n\n\nAlternatively we can first mark files to include in the commit and files to be\nremoved:\n\n\n> git add \n> git remove \n\n\nVerify that all is in order:\n\n> git status\n# On branch feature/myFancyFeature\n# Changes to be committed:\n# (use \"git reset HEAD ...\" to unstage)\n#\n# modified: fileA\n# fileB\n# dirA/fileX\n#\n# Changed but not updated:\n# (use \"git add ...\" to update what will be committed)\n# (use \"git checkout -- ...\" to discard changes in working directory)\n#\n# modified: fileZ\n\n\nAnd finally commit the files:\n\n> git commit\n\n\n---++ Viewing What You've Changed\n\nTo see the difference between your tracked but unstaged changes and the current\nbranch (including your not-yet-pushed commits)\n\n> git diff\n> git diff \n\n\nTo see the difference between your staged changes and the current branch\n(including your not-yet-pushed commits):\n\n> git diff --staged\n> git diff --staged \n\n\nTo see a list of commits to a branch:\n\n> git log\n\n\nTo see the details and diff for a commit\n\n> git show \n\n\n\n--++ Stashing Changes\n\nIf you have changes you don't wish to commit but don't want to lose either while\nyou do something else, you can temporarily 'stash' the changes away. This could\nbe some frequently used debug code,or just some work in progress you need to\nmove to another branch without committing. If the code is just WIP for the\ncurrent branch we recommend using an interim commit instead.\n\nThe stash is a temporary store that holds a stack of uncommitted changes at a\nrepository level. Commands given below work by default with the stash at the top\nof the stack, or you can optionally provide the stack reference.\n\nTo store your current changes at the top of the stash stack:\n\n> git stash \n\n\nTo see all your stashed items in the stash stack:\n\n> git stash list\n\n\nThis will show something like:\n\nstash@{0}: WIP on master: 6ebd0e2... My debug code\nstash@{1}: WIP on master: 9cc0589... My stashed changes\n\n\nTo see the details of an individual stash (use bash-completion for ease of use):\n\n> git stash show \n\n\nTo see the changes in a stash:\n\n> git stash show -p \n\n\nTo restore a stash while keeping a copy in the stack:\n\n> git stash apply \n\n\nTo restore a stash and remove it from the stack:\n\n> git stash pop \n\n\nTo remove a single stash from the stack without applying it:\n\n> git stash drop \n\n\nTo clear out your entire stash stack:\n\n> git stash clear\n\n\n\n---++ A convenient git setup - tips & tricks\n\n---+++ Setup git command shortcuts\n\nGit supports a lot of commands like =checkout= or =status=. It also allows to define shortcuts which makes working on the command line faster. And isn't that what we all want?\n\nTo set them up simply edit the git config file (typically ~/.gitconfig but it\ncould also be defined globally) and add an =alias= section like so:\n\n\n[alias]\n st = status\n ci = commit\n br = branch\n co = checkout\n df = diff\n lg = log -p\n lol = log --graph --decorate --pretty=oneline --abbrev-commit\n lola = log --graph --decorate --pretty=oneline --abbrev-commit --all\n ls = ls-files\n ch = cherry-pick\n\n\nNow you can use the shortcuts like any other git command. Example: =git st= as a\nshortcut for =git status=.\n\n\n---+++ Git commit template\n\nIt is customary to use a specific format for commit messages. Git allows to\nspecify a template which reminds the committer of these policies. A typical\ntemplate could look as follows:\n\n\n# Please enter the commit message for your changes. Lines starting\n# with '#' will be ignored, and an empty message aborts the commit.\n#\n# You MUST wrap all lines at 72 characters.\n#\n# ==[ Subject: One line only short meaningful description for logs ]===|\n\n# ==[ Blank: Follow the Subject with a blank line, do NOT remove ]=====|\n\n# ==[ Details: Describe what changed and explain why it changed]=======|\n\n\nThe template could also contain hints to special fields which are supported like\nkeywords to close bug reports or to CC the commit to a certain email address and\nso on (the KDE project uses a variety of git commit hooks like these).\n\nTo use the template add a new section =commit= into the git config file\n(typically ~/.gitconfig but it could also be defined globally):\n\n\n[commit]\n template = /home/user/dev/git.commit-template\n\n\n--+++ Bash shell magic\n\nFor those of us who like to work on the shell there is a little command prompt\ntreat available. In addition to all the fancy coloring and whatever you want to\ndo with your command prompt you can include information about the git repository\nin the current folder.\n\nFor that you need the git bash completion to be installed (this depends on your\nsystem setup and if left as an\n[[http://git.kernel.org/?p=git/git.git;a=blob_plain;f=contrib/completion/git-completion.bash;hb=HEAD][exercise]]\nfor the interested reader). Then the \"__git_ps1\" function will\nbe available for you to play with.\n\nExample prompt:\n\nPS1=\"\\[\\033[01;31m\\]\\u\\[\\033[00m\\]:\\[\\033[01;34m\\]\\w \\[\\033[0;33m\\]$(__git_ps1 \"(%s)\")\\[\\033[00m\\] \\$ \\[\\033[00m\\]\"\n\n\nThe result can be seen here (without colors):\n\ntrueg:~/kde/dev/kde/src/nepomuk-core (libnepomukcore/query/optimization/subQueries) $\n\n\n\n\n---++ Fix Screw-ups\n\n---+++ Split a commit\nImagine you committed a set of changes and realize that you actually wanted to\nsplit that into several commits. That is no problem at all if nothing has been\npushed to a public repo yet. We simple need to do a mixed reset and then do the\nseparate commits:\n\n\n> git reset HEAD^\n\n\nThis will reset the index to the previous commit and keep the current working\ndir unchanged. Now you can continue with creating your commits the way you\noriginally intended (\"git add -p\" is your friend).\n\n---++ Keep In Mind\n * Never pull after a merge! It will mess with your history.\n * Never branch from master. Branch from a devel or stable branch instead.\n\n" . . "2017-06-13T05:44:55Z" . "2017-06-13T05:44:55Z" . . . . . . . . . . . "2017-06-13T05:44:55.251296"^^ . . "a604d8310d5c465a81cb4f01bcb3157e" . "2017-06-13T05:44:55.251296"^^ . "GitQuickstartTips" .