devel:git
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
devel:git [2010-01-10 11:06] – fixed stable link tracking andi | devel:git [2024-02-06 10:39] (current) – [How to use Git] Web links was checked and updated. Aleksandr | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== DokuWiki Git Repository ====== | ====== DokuWiki Git Repository ====== | ||
- | The [[: | + | The [[: |
- | //Git is a free & open source, distributed | + | Git is **NOT** offered as optional |
- | ===== How to use git ===== | + | ===== How to use Git ===== |
Instead of repeating things that were said elsewhere I just want to give some pointers: | Instead of repeating things that were said elsewhere I just want to give some pointers: | ||
- | * [[http:// | + | * [[https:// |
- | * [[http:// | + | * [[https://git-scm.com/|Git Community]] |
- | * [[http://www.kernel.org/ | + | * [[https://schacon.github.io/ |
+ | * [[http:// | ||
- | ===== Using git for DokuWiki ===== | + | There are also some good books about Git: |
+ | * [[https://git-scm.com/ | ||
+ | * [[http:// | ||
+ | * [[https:// | ||
+ | * [[amazon> | ||
- | Before you start using git, you should configure it with your name and email address: | + | ===== Git Configuration ===== |
+ | |||
+ | Before you start using Git, you should configure it with your name and email address: | ||
git config --global user.name "Your Name Comes Here" | git config --global user.name "Your Name Comes Here" | ||
git config --global user.email you@yourdomain.example.com | git config --global user.email you@yourdomain.example.com | ||
+ | |||
+ | And optionally setup colors and few helpful aliases: | ||
+ | git config --global color.ui auto | ||
+ | git config --global alias.st status | ||
+ | git config --global alias.ci commit | ||
+ | git config --global alias.up pull --rebase | ||
+ | |||
+ | ===== Using Git for DokuWiki ===== | ||
To fetch the current development version of DokuWiki use the following command (This creates the directory **dokuwiki** for you): | To fetch the current development version of DokuWiki use the following command (This creates the directory **dokuwiki** for you): | ||
- | git clone git:// | + | git clone git:// |
To update an existing checkout use this command from within the DokuWiki directory: | To update an existing checkout use this command from within the DokuWiki directory: | ||
Line 28: | Line 43: | ||
git pull | git pull | ||
- | When you create a new source file, use this command to add it to the git repository: | + | When you create a new source file, use this command to add it to the Git repository: |
git add somenewfile | git add somenewfile | ||
- | When you changed some already tracked files, you need to tell git about it: | + | When you changed some already tracked files, you need to tell Git about it: |
git add --patch | git add --patch | ||
- | The '' | + | The '' |
When you're finished with your changes use: | When you're finished with your changes use: | ||
Line 42: | Line 57: | ||
git commit | git commit | ||
- | This will scan your local git repository to find the changes that have occurred and will locally " | + | This will scan your local Git repository to find the changes that have occurred and will locally " |
To get your changes included in the official tree, create a patchfile: | To get your changes included in the official tree, create a patchfile: | ||
- | git format-patch | + | git format-patch |
+ | |||
+ | This creates one (or more) numbered patch files that can be mailed manually to the [[: | ||
- | This creates one (or more) numbered patch files that can be mailed manually to the [[: | ||
==== Tips and Tricks ==== | ==== Tips and Tricks ==== | ||
Line 55: | Line 72: | ||
* Make sure your editor does not change line endings (from Unix LF to DOS CRLF), this would result in a complete file replace, instead of a small patch because each line was changed. | * Make sure your editor does not change line endings (from Unix LF to DOS CRLF), this would result in a complete file replace, instead of a small patch because each line was changed. | ||
* Make a patch for a single feature. When you worked on two different features (eg, a language fix and a function update), '' | * Make a patch for a single feature. When you worked on two different features (eg, a language fix and a function update), '' | ||
- | * Patches should be sent to the [[: | + | * We **really prefer** [[github|pull requests]], above patches |
- | * A web interface to the git repository is available at [[http:// | + | * A web interface to the Git repository is available at [[https:// |
- | ==== Mixing the official tree with own patches | + | ===== Use branches and your own fork, for doing pull requests |
+ | (Making [[https:// | ||
- | FIXME explain | + | Above explanation mixes your changes with the incoming changes of DokuWiki in the same ' |
- | ==== Maintaining a stable version | + | First you make at Github your own fork with the ' |
- | Git isn't only for DokuWiki developers, it can be used to get the latest stable version and to update to the next stable version when it is released. To do so you need to clone the repository but work in the stable branch: | + | With the clone url, shown with the 'Code' |
- | git clone git:// | + | git clone git@github.com: |
- | git checkout -b stable | + | |
+ | Next you add the original DokuWiki repository as extra remote repository: | ||
+ | |||
+ | git remote add upstream | ||
+ | |||
+ | Verification of this addition can done by showing all remotes (origin=your online fork, upstream=original online DokuWiki repo) | ||
+ | |||
+ | git remote -v | ||
+ | |||
+ | If you start making the modifications you like to propose, it is recommended to make first a separate branch in your fork. If your plan is to fix multiple issues (e.g. fix php warnings and add a new feature), please create a branch for each of them. A branch can be created with: | ||
+ | |||
+ | git checkout -b yourbranchname | ||
+ | |||
+ | In this branch you can make your changes. Storing changes in git, goes in two steps: 1) first add the files such that git knows which files are ready, 2) commit the added files. | ||
+ | |||
+ | # add an entire file to the coming commit | ||
+ | git add your/ | ||
+ | # or decide interactively which changes in a file to add to the coming commit | ||
+ | git add --patch | ||
+ | |||
+ | After done with adding, commit these changes with | ||
+ | |||
+ | git commit | ||
+ | |||
+ | Advice: try to commit small understandable pieces of code per commit, if the entire change is larger, do not all changes in one commit. This helps later other people that review your proposal :-). | ||
+ | |||
+ | If you wonder what the status is of your repository during the different steps, you can ask git more info: | ||
+ | |||
+ | # shows current status, and gives eventually some hints how to progress | ||
+ | git status | ||
+ | # show not commit changes | ||
+ | git diff | ||
+ | |||
+ | Switching between branches: | ||
+ | |||
+ | git checkout yourbranchname | ||
+ | # back to main branch | ||
+ | git checkout master | ||
+ | |||
+ | Sometimes you have changes, which are not yet ready for committing, but you like to switch for example between branches. You can temporary store the not committed changes. | ||
+ | |||
+ | # store temporary all not committed changes | ||
+ | git stash | ||
+ | # if you like to continue, you can reapply the changes | ||
+ | git stash apply | ||
+ | |||
+ | Of course there are regularly changes added to DokuWiki' | ||
+ | |||
+ | git fetch upstream | ||
+ | |||
+ | And next merge them in your branch | ||
+ | |||
+ | # go to your branch (if you are not already there) | ||
+ | git checkout yourbranchname | ||
+ | # merge the changes from the ' | ||
+ | # in the current branch. | ||
+ | git merge upstream/ | ||
+ | |||
+ | Alternatively, | ||
+ | |||
+ | git pull upstream master | ||
+ | |||
+ | If you are ready, and all your changes are committed, you can publish your branch to your fork on Github | ||
+ | |||
+ | git push origin | ||
+ | |||
+ | On Github, you see now a notice which let you initiate a Pull request to DokuWikis repository. DokuWiki' | ||
+ | |||
+ | Changes can be made locally again in your branch, and committed as before. If done, you can publish them in the same manner as the first time. It will simply sent the extra commits to your fork, and automatically appear in the pull request as well. | ||
+ | |||
+ | git push origin yourbranchname | ||
+ | |||
+ | **Background**: | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | * https:// | ||
+ | |||
+ | ==== Maintaining a stable | ||
+ | |||
+ | Git isn't only for DokuWiki developers. It can be used to get the latest stable version and to update to the next stable version when it is released. To do so you need to clone the repository but checkout the stable branch: | ||
+ | |||
+ | git clone --branch stable https:// | ||
| | ||
Now you can pull all needed updates whenever a new release is made: | Now you can pull all needed updates whenever a new release is made: | ||
+ | cd dokuwiki | ||
git pull | git pull | ||
- | ===== Why Git? ===== | ||
- | The reasons for a distributed RCS are well explained at [[darcs#Why Darcs?]]. So why did we switch from darcs to git? | + | ==== Adding plugin/ |
+ | |||
+ | You can checkout your plugin repository (or if contributing to others' | ||
+ | |||
+ | Go to the plugins (or template) folder | ||
+ | |||
+ | cd dokuwiki/ | ||
+ | # or | ||
+ | cd dokuwiki/ | ||
+ | |||
+ | Clone the plugin repository, this creates the folder ' | ||
+ | |||
+ | git clone git@github.com: | ||
- | While darcs is somewhat more intuitive | + | Rename |
- | Also using a more popular revision control system makes it possible to outsource the hosting to services like github, which means less stuff to administer for us and less traffic on the DokuWiki server. | + | mv dokuwiki-plugin-example example |
- | A more popular revision control system also makes it easier for new developers and other contributors to participate in the project. If they have to learn a new RCS just to start working on the code, that's a barrier to entry that they may not overcome. (It's amazing how little it takes to keep people from participating!) Smoothing the path a bit for new contributors can improve the quality of the code significantly. | + | Eventually, you have to configure your IDE to recognize |
devel/git.1263118009.txt.gz · Last modified: by andi