Changes between Version 1 and Version 2 of GitCreateBundle
- Timestamp:
- Oct 15, 2013, 4:22:51 PM (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
GitCreateBundle
v1 v2 5 5 == Why git bundles == 6 6 7 Currently, the repo is folded into different public branches, letting a contributor choose on which of these branch his new patch is meant to be applied (see [ patchesRasdamanReleaseProcess#Branchingmodel here] for details].7 Currently, the repo is folded into different public branches, letting a contributor choose on which of these branch his new patch is meant to be applied (see [RasdamanReleaseProcess#Branchingmodel here] for details). 8 8 9 9 This wiki page is meant for developers who need to reflect a ''merge'' operations to the public repo: indeed a solution which provides both un-linearized history and submission to the [patchmanagaer patch manager] is to submit a ''bundle''. … … 43 43 44 44 First of all, the status of the two branches to be merged '''must''' be the _exactly_ the same before starting to merge. 45 In this case, we can imagine we want to merge `feature_X ' into `master':45 In this case, we can imagine we want to merge `feature_X` into `master`: 46 46 47 47 {{{ … … 56 56 #!sh 57 57 $ git fetch origin 58 $ # already up-to-date? otherwise pull new changes on both branches 59 $ 58 $ # already up-to-date? otherwise pull new changes on both branches. 59 60 60 $ git branch 61 61 feature_X … … 65 65 $ git merge feature_X --no-ff 66 66 $ # In case of "Automatic merge failed; fix conflicts and then commit the result.", then see you later. 67 $ # otherwise: 67 68 $ # Check: 68 69 $ git log --oneline -1 master 69 70 3f36d7f Merge branch 'feature_X' into master … … 80 81 To publish this on the public repo you can create the bundle, but first (again) remember that: 81 82 82 * local snapshot of two branches must ''exactly'' be synchronized with that of the public repo 83 * consequently, the ''names'' of the merging branches must be the same (as developers tend to open branches for local development..)83 * local snapshot of two branches must ''exactly'' be synchronized with that of the public repo; 84 * consequently, the ''names'' of the merging branches must be the same as well (developers tend to open new branches for local development...). 84 85 85 If it is allfine, create the bundle:86 If all is fine, create the bundle: 86 87 87 88 * Synopsis: … … 152 153 $ cd ~/test_repo 153 154 $ git init 155 156 $ # push two branches to the test repo 154 157 $ cd /home/rasdaman/rasdaman 155 $ git remote add test_remote ~/test_repo/ 156 $ # push two branches to the test repo 158 $ git remote add test_remote ~/test_repo 157 159 $ git push test_remote master 158 160 $ git push test_remote feature_X 159 $ # Now move to the test repo and apply the bundle (1-verify, 2-apply) 161 162 $ # Now move to the test repo 160 163 $ cd ~/test_repo 161 164 $ git branch 162 165 feature_X 163 166 * master 167 164 168 $ # check out on a branch you're not merging into: 165 169 $ git checkout feature_x … … 167 171 * feature_X 168 172 master 173 174 # Apply the bundle: [verify &] apply 169 175 $ git bundle verify /path/to/ticket:XYZ_MergingFeature_xOnMaster.bundle 170 176 $ git fetch /path/to/ticket:XYZ_MergingFeature_xOnMaster.bundle master:master
