-
Notifications
You must be signed in to change notification settings - Fork 1
ReleaseManagement
Xmipp version number (for example, "3.1" appears in different files across the source code. You can change the number in all of them easily with the set_xmipp_version.sh script
The new branch release should be handled carefully when release deadline is near. Ideally, only bug fixes should be commited to that branch.
New features can be added to the master branch.
Until 3.1 release is tagged (his state is frozen), master and 3.1 branches will coexist and everyone must deal with both. Some of the changes (3.1 bug fixing) will be only for 3.1, and some of them will be new features for 3.2 future release. This is a brief guide to �how to push changes to our repository without destroying Kino's timetable�:
Step 1: Ask Josemi whether that is really a 3.1 bug or a new feature. If yes continue with Step 2.
Step 2: Write your changes in 3.1 branch.
Step 3: Commit them to your local 3.1 branch.
Step 4: Push them to remote repository.
Step 5: Merge your local 3.1 with your local master
ALARM: I fixed the bug on master (without committing them), what can I do now?
Substep 1: git stash your changes, move to 3.1 and unstash them
$ git stash
$ git checkout 3.1
$ git stash pop
ALARM: I fixed the bug on master (committing them but not pushing them), what can I do?
Substep 1: git cherry-pick your changes from master to 3.1
$ git log
Note your commit hash
$ git checkout 3.1
$ git cherry-pick <your_commit(s)_hash(s)>
Substep 2: push your changes
ALARM: I committed (without pushing) a new feature on 3.1. What can I do?
Substep 1: git cherry-pick your commits from 3.1 to master
$ git log
Note your commit(s) hash(s) and the last commit before your changes
$ git checkout master
$ git cherry-pick <your_commit(s)_hash(s)>
Substep 2: reset your 3.1 branch state
$ git checkout 3.1
$ git reset --hard <commit_before_your_changes_hash>
ALARM: I pushed a new feature on 3.1. What can I do? Do I deserve suicide? (yes)
Substep 1: git cherry-pick your commits from 3.1 to master
$ git log
Note your commit(s) hash(s)
$ git checkout master
$ git cherry-pick <your_commit(s)_hash(s)>
Substep 2: revert your mess in the 3.1 branch
$ git revert <older_commit_hash>^..<newer_commit_hash>
(where older_commit_hash and newer_commit_hash are the first and last commits of the range of commits you want to destroy). In case of a single commit, just git revert <commit_to_destroy_hash>
لطفا وحید، بررسی مرتکب خود را !!!!!!!!!!!!
-- Main.JesusCuenca - 2013-10-18