Git usage: Difference between revisions

From Official Kodi Wiki
Jump to navigation Jump to search
>Jmarshall
No edit summary
No edit summary
 
(14 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{XBMC faq toc}}
{{mininav|[[Development]]}}
 
==Git windows guide==
The guide for Windows users is located here: [[Git Usage Windows]]
The guide for Windows users is located here: [[Git Usage Windows]]
== Clone the XBMC main repository ==
== Clone the XBMC main repository ==
Line 59: Line 61:
$ git checkout feature_branch
$ git checkout feature_branch
$ git checkout -b feature_rebase
$ git checkout -b feature_rebase
$ ... do rebase ...
$ # ... do rebase ...
$ git diff feature_branch     # ensure your rebase hasn't dropped something.
$ git diff feature_branch                                     # ensure your rebase hasn't dropped something.
$ git checkout feature_branch
$ git checkout feature_branch
$ git tag -f feature_last_rebase   # so you know when you last rebased.
$ git tag -f feature_last_rebase                             # so you know when you last rebased.
$ ... more commits on top of feature_branch ...
$ # ... more commits on top of feature_branch ...
$ git checkout feature_rebase
$ git checkout feature_rebase
$ git checkout -b tmp       # create a temporary branch
$ git checkout -b tmp                                         # create a temporary branch
$ git branch -f feature_rebase feature_branch       # move feature_rebase to the HEAD of feature_branch
$ git branch -f feature_rebase feature_branch                 # move feature_rebase to the HEAD of feature_branch
$ git rebase --onto tmp feature_last_rebase feature_rebase    # rebase changes from the last rebase on top of feature_branch
$ git rebase --onto tmp feature_last_rebase feature_rebase    # rebase changes from the last rebase on top of feature_branch
$ git diff feature_branch       # ensure your rebased branch contains all the commits you want
$ git diff feature_branch                                     # ensure your rebased branch contains all the commits you want
$ ... do rebase ...
$ git branch -d tmp
$ # ... do rebase ...
</source>
</source>
You then just rinse/repeat until all issues are ironed out.  feature_rebase is then what is pulled into master nice and cleanly.
You then just rinse/repeat until all issues are ironed out.  feature_rebase is then what is pulled into master nice and cleanly.
[[Category:Development]]
[[Category:Development]]
[[Category:Manual]]
{{nobots}}

Latest revision as of 22:00, 17 November 2014

Home icon grey.png   ▶ Development ▶ Git usage

Git windows guide

The guide for Windows users is located here: Git Usage Windows

Clone the XBMC main repository

XBMC now uses git as its Software Configuration Management (SCM) framework. The main repository is located at github

For read only access

  $ git clone git://github.com/xbmc/xbmc.git

If you are a developer, clone the repository.

  $ git clone [email protected]:xbmc/xbmc.git

Fetch old branches and extra history

The following is ONLY useful for developers who wish to see extended XBMC history. Everyone else should stop here. Run this command from your tree. It requires git 1.6.5 or higher:

$ git fetch origin refs/old/heads/*:refs/remotes/svn-migration/* refs/replace/*:refs/replace/*

Platform Settings

Case Insensitive File Systems

Git wants to run under a case sensitive file system but under OSX and Windows, the file system might be case insensitive. Make sure that core.ignorecase is properly set. Check with:

$ git config --list

if not set:

$ git config --global core.ignorecase true

Line Endings

Windows users MUST use the git autocrlf feature. This is set by default by tortoise. If it's not set, you can do so manually:

$ git config --system core.autocrlf true

Linux and OSX users should set autocrlf to 'input'

$ git config --global core.autocrlf input

Updating

When updating from the main git repository (by default git will call this 'origin'), you should always rebase on top of your history, unless you know what you're doing.

Always use

git pull --rebase

A safe bet is to set this to be done automatically.

$ git config branch.master.rebase true

Pushing

Please use

git log

to look at the log before pushing. If there are merge commits that you don't understand, please ask for help before pushing.

Never EVER force a push (non-fast-forward commit) to mainline. Ever. Doing so will result in your push privileges being revoked.

Merging

Always use the --log option to add a description of what commits are being merged. You can (and should) set this as a default:

$ git config merge.log true

Advanced

Maintaining a rebased version of a merge branch

A long-lived feature branch involving a bunch of developers at some point needs merging to mainline. During the review stage, this typically involves someone taking the time to rebase the feature branch on mainline so that the changes are easier to review for others, with a pull request being made. Review will inevitably result in fix commits being required, and where many developers are involved this can be messy if constantly rebased (as devs are working against a moving target). An alternative is to have 2 branches: The first rebased branch changes to the development branch with fixup commits being applied. A second branch is then created which is identical to the first, just rebased down. In order to maintain this arrangement, you need to be able to apply the top N commits from the development branch onto the rebased branch to ensure it's kept up to date. This can be done as follows:

$ git checkout feature_branch
$ git checkout -b feature_rebase
$ # ... do rebase ...
$ git diff feature_branch                                     # ensure your rebase hasn't dropped something.
$ git checkout feature_branch
$ git tag -f feature_last_rebase                              # so you know when you last rebased.
$ # ... more commits on top of feature_branch ...
$ git checkout feature_rebase
$ git checkout -b tmp                                         # create a temporary branch
$ git branch -f feature_rebase feature_branch                 # move feature_rebase to the HEAD of feature_branch
$ git rebase --onto tmp feature_last_rebase feature_rebase    # rebase changes from the last rebase on top of feature_branch
$ git diff feature_branch                                     # ensure your rebased branch contains all the commits you want
$ git branch -d tmp
$ # ... do rebase ...

You then just rinse/repeat until all issues are ironed out. feature_rebase is then what is pulled into master nice and cleanly.