Changes between Initial Version and Version 1 of Developer/Git/Committers


Ignore:
Timestamp:
Feb 29, 2012, 9:31:50 PM (8 years ago)
Author:
Gedare
Comment:

/* New Page */

Legend:

Unmodified
Added
Removed
Modified
  • Developer/Git/Committers

    v1 v1  
     1= Git Committers =
     2
     3
     4
     5[[TOC(Developer/GitCommitters, depth=2)]]
     6
     7
     8TODO: Some guidelines for anyone who wishes to contribute to rtems... Patches? Pull Requests?...
     9
     10The preferred workflow for making changes to RTEMS is to push patches to a committer's personal repository in public view and then merge changes from there. For working on enhancements or bug fixes committers are encouraged to push to branches on their personal repositories and to merge into the main RTEMS repository from their personal repository. Personal branches should not be pushed to the RTEMS repository.
     11=  SSH Access  =
     12
     13Currently all committer's should have an ssh account on the main git server, git.rtems.org.  If you have been granted commit access and do have an account on git.rtems.org one should be requested on the rtems-devel@rtems.org list. SSH access for git uses key logins instead of passwords. The key should be at least 1024bits in length.
     14=  Personal Repository  =
     15
     16Personal repositories keeps the clutter away from the master repository. A user with a personal repository can make commits, create and delete branches, plus more without interfering with the master repository. Commits to the master repository generate email to the rtems-vc@rtems.org list and development type commits by a developer would only add noise and lessen the effectiveness of the commit list.
     17
     18A committer should maintain a personal clone of the RTEMS repository through which all changes merged into the RTEMS head are sent. The personal repository is also a good place for committers to push branches that contain works in progress. The following instructions show how to setup a personal repository that by default causes commits to go to your private local repository and pushes to go to your publicly visible personal repository. The RTEMS head is configured as a remote repository named 'upstream' to which you can push changes that have been approved for merging into RTEMS.
     19
     20Branches aren't automatically pushed until you tell git to do the initial push after which the branch is pushed automatically. In order to keep code private just put it on a branch in your local clone and do not push the branch.
     21=  Create a personal repository  =
     22
     23Set up the server side repository. In the following substitute user with your username.
     24{{{
     25# ssh git.rtems.org
     26[user@git ~]$ ln -s /data/git/user git
     27[user@git ~]$ ls -l
     28lrwxrwxrwx 1 user rtems 16 Feb  1 11:52 git -> /data/git/user
     29[user@git ~]$ cd git
     30[user@git git]$ git clone --mirror /data/git/rtems.git
     31}}}
     32Provide a description for the repository, for example "Clone of master repository."
     33{{{
     34[user@git git]$ echo "Clone of master repository." > rtems.git/description
     35[user@git git]$ logout
     36}}}
     37Clone the repository on your local machine
     38{{{
     39# git clone ssh://user@git.rtems.org/home/user/git/rtems.git
     40# cd rtems
     41}}}
     42Add the RTEMS repository as a remote repository and get the remote tags and branches
     43{{{
     44# git remote add upstream ssh://user@git.rtems.org/data/git/rtems.git
     45# git fetch upstream
     46}}}
     47
     48After a little while you should be able to see your personal repo at http://git.rtems.org/user/rtems.git/ and you can create other repositories in your git directory that will propagate to http://git.rtems.org/user if you need.
     49=  Check your setup  =
     50
     51{{{
     52git remote show origin
     53}}}
     54Should print something similar to
     55{{{
     56 * remote origin
     57   Fetch URL: ssh://user@git.rtems.org/home/user/git/rtems.git
     58   Push  URL: ssh://user@git.rtems.org/home/user/git/rtems.git
     59   HEAD branch: master
     60   Remote branches:
     61     4.10   tracked
     62     4.8    tracked
     63     4.9    tracked
     64     master tracked
     65   Local branch configured for 'git pull':
     66     master merges with remote master
     67   Local ref configured for 'git push':
     68     master pushes to master (up to date)
     69}}}
     70=  Push commits to personal repo master from local master  =
     71
     72{{{
     73# git push
     74}}}
     75=  Push a branch onto personal repo  =
     76
     77{{{
     78# git push origin branchname
     79}}}
     80=  Update from upstream master (RTEMS head)  =
     81
     82When you have no changes in your local master branch, use
     83{{{
     84 # git fetch upstream
     85 # git checkout master
     86 # git merge upstream/master
     87}}}
     88This is the same as a git pull.
     89=  Update and commit to RTEMS  =
     90
     91When you have changes and you want to propagate them upstream: (if you
     92have those changes on a separate branch)
     93{{{
     94# git checkout new_features
     95# git fetch upstream
     96# git rebase upstream/master
     97# git push upstream new_features:master
     98}}}
     99
     100If someone pushed since you updated the server rejects your push until you are up to date.
     101=  GIT Push Configuration  =
     102
     103
     104People with write access to the main repository should make sure that they push the right branch with the git push command. The above setup ensures that git push will not touch the main repository, which is identified as upstream, unless you specify the upstream (by git push upstream master).
     105
     106Lets suppose we have a ''test'' branch intended for integration into the ''master'' branch of the main repository.
     107{{{
     108# git branch
     109  master
     110 *  test
     111}}}
     112There are two options for pushing with the branch. First,
     113{{{
     114# git push origin test
     115}}}
     116Will push the test branch to the personal repository. To delete the remote branch
     117{{{
     118# git push origin :test
     119}}}
     120You'll still need to delete your local branch if you are done with it.
     121
     122If you are going to work exclusively with one branch for awhile, you might want to configure git to automatically push that branch when you use git push. By default git push will use the local master branch, but you can use the 'test' branch as the source of your changes:
     123{{{
     124# git config remote.origin.push test:master
     125}}}
     126
     127Now git push will merge into your master branch on your personal repository. You can also setup a remote branch:
     128{{{
     129# git config remote.origin.push test:test
     130}}}
     131You can see what branch is configured for pushing with
     132{{{
     133# git remote show origin
     134}}}
     135And reset to the default
     136{{{
     137# git config remote.origin.push master
     138}}}
     139=  Committing  =
     140
     141When merging someone's work, whether your own or otherwise, we have some suggested procedures to follow.
     142 *  Never work in the master branch. Checkout a new branch and apply patches/commits to it.
     143 *  Before pushing upstream:
     144  *  Update master by fetching from the server
     145  *  Rebase the working branch against the updated master
     146  *  Push the working branch to the server master
     147The basic workflow looks like
     148{{{
     149# git checkout -b somebranch upstream/master
     150# patch .. git add/rm/etc
     151# git fetch upstream
     152# git rebase upstream/master
     153# git push upstream somebranch:master
     154}}}