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

Feb 29, 2012, 9:31:50 PM (8 years ago)

/* New Page */


  • Developer/Git/Committers

    v1 v1  
     1= Git Committers =
     5[[TOC(Developer/GitCommitters, depth=2)]]
     8TODO: Some guidelines for anyone who wishes to contribute to rtems... Patches? Pull Requests?...
     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  =
     13Currently all committer's should have an ssh account on the main git server,  If you have been granted commit access and do have an account on one should be requested on the list. SSH access for git uses key logins instead of passwords. The key should be at least 1024bits in length.
     14=  Personal Repository  =
     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 list and development type commits by a developer would only add noise and lessen the effectiveness of the commit list.
     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.
     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  =
     23Set up the server side repository. In the following substitute user with your username.
     25# ssh
     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
     32Provide a description for the repository, for example "Clone of master repository."
     34[user@git git]$ echo "Clone of master repository." > rtems.git/description
     35[user@git git]$ logout
     37Clone the repository on your local machine
     39# git clone ssh://
     40# cd rtems
     42Add the RTEMS repository as a remote repository and get the remote tags and branches
     44# git remote add upstream ssh://
     45# git fetch upstream
     48After a little while you should be able to see your personal repo at and you can create other repositories in your git directory that will propagate to if you need.
     49=  Check your setup  =
     52git remote show origin
     54Should print something similar to
     56 * remote origin
     57   Fetch URL: ssh://
     58   Push  URL: ssh://
     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)
     70=  Push commits to personal repo master from local master  =
     73# git push
     75=  Push a branch onto personal repo  =
     78# git push origin branchname
     80=  Update from upstream master (RTEMS head)  =
     82When you have no changes in your local master branch, use
     84 # git fetch upstream
     85 # git checkout master
     86 # git merge upstream/master
     88This is the same as a git pull.
     89=  Update and commit to RTEMS  =
     91When you have changes and you want to propagate them upstream: (if you
     92have those changes on a separate branch)
     94# git checkout new_features
     95# git fetch upstream
     96# git rebase upstream/master
     97# git push upstream new_features:master
     100If someone pushed since you updated the server rejects your push until you are up to date.
     101=  GIT Push Configuration  =
     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).
     106Lets suppose we have a ''test'' branch intended for integration into the ''master'' branch of the main repository.
     108# git branch
     109  master
     110 *  test
     112There are two options for pushing with the branch. First,
     114# git push origin test
     116Will push the test branch to the personal repository. To delete the remote branch
     118# git push origin :test
     120You'll still need to delete your local branch if you are done with it.
     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:
     124# git config remote.origin.push test:master
     127Now git push will merge into your master branch on your personal repository. You can also setup a remote branch:
     129# git config remote.origin.push test:test
     131You can see what branch is configured for pushing with
     133# git remote show origin
     135And reset to the default
     137# git config remote.origin.push master
     139=  Committing  =
     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
     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