Git Process - ProofDrivenQuerying/pdq GitHub Wiki

The most reviewed copy of the code will be set to the master in GitHub.

In eclipse this would be done via the Git plugin, which would give access to git-related actions from the Team menu.

You can create a branch from the web interface.

Here the command line instructions are given:

Grab a complete copy of a repository (general command):

git clone https://github.com/ProofDrivenQuerying/pdq.git

(this gets the complete copy of the repository, but you will only see a branch if you switch to it using git checkout)

For every branch x in the remote pdq repository, a corresponding local branch origin/x is created in your local repository.

You can check what branch you are currently associated with by:

git branch

All commands for modifying will be associated with that branch by default.

You can grab a specific branch e.g., the master using

git fetch origin master

or with the full name, e.g. git fetch https://github.com/ProofDrivenQuerying/pdq.git master

1. Raise an issue associated with the master e.g. via the web interface
2. Update local copy of some branch (e.g. mybranch)
   • Switch locally to mybranch

	git checkout mybranch  (flags that you are working locally with mybranch)
	git pull    (gets the code for mybranch from the server) 

3. After editing locally, commit changes locally

	git commit -m "Commit message"

or git commit -am "Commit message" (Note that the commit message should not be empty)

4. After waiting at least one day for a response to the issue, push changes from the local branch (called origin by default) back to mybranch

	git push origin mybranch

you can omit mybranch and it will be the default (it seems you can omit origin)

5. Other project members should get the changes now by doing

	git pull 

or git pull origin mybranch from the command line

To revert local changes I have used

git reset --hard origin/master-branch-name (e.g. review)

from the command line

1. Raise an issue, GitHub creates an id for it
2. Create a new branch for the bug fix

	git checkout <nameofbranchfixisfrom> (e.g. staging, master...)
	git checkout -b "mybugfix-<id>" (new name)

3. Make bug fix locally, commit changes locally

	git commit -m "Commit message"

4. Push changes from the local branch to a new branch called bugfix-id

	git push origin <bugfix-id> where id is the issue raised  

5. Create a pull request (This is easy from the web interface after you push your new branch, but it seems tricky to do form the command line; we know that it involves git request-pull with some arguments, but we are not sure which arguments)

Reviewers do the following:

1. Fetch a pull request, let bugfix- be the branch where the pull request was issued.

	// Get the id of the pull request issued in review branch
	--git fetch origin pull/ID/head:<bugfix-<id>>

	// Switch to the new branch that's based on this pull request:
	--git checkout bugfix-<id>

2. Add reviewer comments and issues via web interface (how?), via command line (how?). The review process is described in the pdq process document.
3. Bug owner changes code in response to reviewer comments -- we are not sure yet what this requies.
4. When review is complete, replace the branch-being-fixed with the fixed version. From the web interface just do a merge of this pull request. From the command line we are not sure.

We recommend that this be created as a subproject.

1. Checkout as in III, using two git checkout command, from the appropriate branch
2. When editing, create a new subproject at the appropriate level (e.g. if it is mostly about planning, it would be a sibling of planner with a name myexperimentalplanner_)
3. To add the new subdirectory use

	git add

and then a commit.

4. Do a push to the server as part of the appropriate branch

	git push origin staging

Periodically we should have this subproject reviewed using a pull request, so that if we want to replace stable code with it we don't have so much work to do.

Right now the branch size-estimation has a subproject called cardinality while our master branch called "review", does not have cardinality. We have two goals: keep the branches in sync, but not reintroduce cardinality (and other deleted code) in review. Hence we should periodically merge from review into sizeestimation, but never merge from sizeestimation into review.

In general we should implement a change at the highest level where it is applicable. However, if the change has been implemented in, say, sizeestimation, and then we find out we want to to make it into review, we either redo the change manually in review (and then merge review into sizeestimation), or use the cherry pick command described here, which allows you to pick particular commits made in sizeestimation and re-commit them in review but without merging.

An even more proper way of always committing changes anywhere is by creating new branches. See here.

commit only maintains copies locally. If you want to make any local changes persistent and visible to other machines (e.g. you were working on a laptop and want to make the changes available for editing on the department's linux server) it will be necessary to push the changes into a new branch on the server : we did not yet discuss how to do this.