Dry-run option will check what the git command is about to do, before actually doing so.
-n option used (but not always means dry run)
Examples:
#Get the stashed working directory back:
$git stash apply stash@{0} git status On branch initialBranch Your branch is up to date with 'origin/initialRemote'. Changes not staged for commit: (use "git add/rm <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: code/editInfo.info modified: code/newScript.sh modified: code/welcome.sh deleted: temp/temp.tmp Untracked files: (use "git add <file>..." to include in what will be committed) logs/database.log
git exercises:
Example 1:
git clean -f --dry-run
Would remove logs/database.log
Example 2:
git add --dry-run
add 'code/editInfo.info'
add 'code/newScript.sh'
add 'code/welcome.sh'
remove 'logs/db.log'
remove 'temp/temp.tmp'
add 'logs/database.log'
git add --all
Example 3:
git commit --dry-run On branch initialBranch Your branch is up to date with 'origin/initialRemote'. Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: code/editInfo.info modified: code/newScript.sh modified: code/welcome.sh renamed: logs/db.log -> logs/database.log deleted: temp/temp.tmp git commit -m 'random dir/files changes'
Example 4:
git push --dry-run #Set the branch: ‘initialBranch’ to track remote branch: ‘initialRemote’ git branch --set-upstream-to=origin/initialRemote Branch 'initialBranch' set up to track remote branch 'initialRemote' from 'origin'. #Confirm the branch tracking git branch -vv * initialBranch 31d2cb7 [origin/initialRemote] Random directory/files changes git status On branch initialBranch Your branch is ahead of 'origin/initialRemote' by 1 commit. git push origin HEAD:initialRemote --dry-run Username for 'https://github.com': greets Password for 'https://greets@github.com': To https://github.com/greets/myProj.git e69eee0..24f8917 HEAD -> initialRemote
Example 5:
git push --all --dry-run
To https://github.com/greets/myProj.git
018d46a..fc62815 branch_v1.8 -> branch_v1.8
43d4441..9ecf5bd master -> master
* [new branch] featureB_old -> featureB_old
* [new branch] initialBranch -> initialBranch
* [new branch] topicBranch -> topicBranch
Apply only certain commits from an existing set of commits & apply the change each one introduces, recording a new commit for each.
Use it in scenario:
(1) A patch applied on one topic branch and committed to be applied across another branch and integrated before the rest of the branch.
(2) Apply only certain commits from a topic branch & later drop that branch without merging it.
But..
git cherry pick introduces a new commit for the same change.
Moreover; there is no metadata linking these two same commits, there is no way for you to find that out.
Use it only when:
You are going to discard the topic branch and keep only some of the commits that you cherry pick.
Drawback:
Cherry-pick does not keep any linking metadata to the commit you picked it from. A bug cherry-picked from any branch cannot be detected.
Solution:
Do not cherry-pick, use more of topic branches instead for small/quick fixes and chosen commits.
Git cherry pick example:
Project:
learn_branching
git checkout cherryPickB
Divya1@Divya:learn_branching [cherryPickB] $git hist
* be761eb 2018-09-10 | Adding output logs file. (HEAD -> cherryPickB)[divya]
* a021500 2018-09-10 | Adding common library script.[divya]
* 7e95b99 2018-09-10 | Editing Readme file.[divya]
* 4871096 2015-11-26 | 1 commit: Initial Project structure and Readme file added.[greets]
#Make some commits here and branch out another branch from here git checkout -b cherryPick_mergeInto 4871096 Divya1@Divya:learn_branching [cherryPick_mergeInto] $git hist * fb2df28 2018-09-10 | adding code.sh (HEAD -> cherryPick_mergeInto)[divya] * 4871096 2015-11-26 | 1 commit: Initial Project structure and Readme file added.[greets] git cherry pick merge #Cherry pick one single commit from branch ‘cherryPickB’ git cherry-pick 7e95b99 Divya1@Divya:learn_branching [cherryPick_mergeInto] $git hist * bb46bbe 2018-09-10 | Adding common library script. (HEAD -> cherryPick_mergeInto)[divya] * fb2df28 2018-09-10 | adding code.sh[divya] * 4871096 2015-11-26 | 1 commit: Initial Project structure and Readme file added.[greets]
#amend the commit message appropriately git commit --amend * d4860f3 2018-09-10 | Cherry-picked from cherryPickB, commitId: a021500: Adding common library script. (HEAD -> cherryPick_mergeInto)[divya] ‘cherryPick_mergeInto’ branch will not get the latest: be761eb commit from ‘cherryPickB’ branch.
This resolves cases with more than two heads, but refuses to do a complex merge that needs manual resolution.
In other words; octopus merge is a git auto merge strategy for merging more than 2 branches together but would not work when auto merging is not possible and requires a git manual merge by the user.
It is primarily meant to be used for bundling topic branch heads together. This is the default git merge strategy when pulling or merging more than one branch.
Demo under Lab session below:
git clone http://github.com/divyabhushan/proj_mergeOctopus.git #Create the local branches by running the build script ./build-octopus.sh #check the branches created git branch #Before an actual merge, dry-run the merge git merge --no-commit --no-ff leg-1 leg-2 leg-3 leg-4 leg-5 leg-6 leg-7 leg-8 #Switch to master branch and merge all the 8 branches git merge leg-1 leg-2 leg-3 leg-4 leg-5 leg-6 leg-7 leg-8 #Check the history of ‘master’ git hist *-----------. 624441a 2018-10-04 | Merge branches 'leg-1', 'leg-2', 'leg-3', 'leg-4', 'leg-5', 'leg-6', 'leg-7' and 'leg-8' (HEAD -> master) [divya] |\ \ \ \ \ \ \ | | | | | | | * e240145 2018-10-04 | Leg 8 commit 3 (leg-8) [divya] | | | | | | | * 3821895 2018-10-04 | Leg 8 commit 2 [divya] | | | | | | | * a5b2bd6 2018-10-04 | Leg 8 commit 1 [divya] | | | | | | * | b688592 2018-10-04 | Leg 7 commit 3 (leg-7) [divya] | | | | | | * | 523e2bb 2018-10-04 | Leg 7 commit 2 [divya] | | | | | | * | c63be7d 2018-10-04 | Leg 7 commit 1 [divya] | | | | | | |/ | | | | | * | 178a657 2018-10-04 | Leg 6 commit 3 (leg-6) [divya] | | | | | * | 316838b 2018-10-04 | Leg 6 commit 2 [divya] | | | | | * | bd5fdc2 2018-10-04 | Leg 6 commit 1 [divya] | | | | | |/ | | | | * | 42e6849 2018-10-04 | Leg 5 commit 3 (leg-5) [divya] | | | | * | 1d553d7 2018-10-04 | Leg 5 commit 2 [divya] | | | | * | d970588 2018-10-04 | Leg 5 commit 1 [divya] | | | | |/ | | | * | d07d1e7 2018-10-04 | Leg 4 commit 3 (leg-4) [divya] | | | * | d36d04a 2018-10-04 | Leg 4 commit 2 [divya] | | | * | 3e6f765 2018-10-04 | Leg 4 commit 1 [divya] | | | |/ | | * | bc77a3c 2018-10-04 | Leg 3 commit 3 (leg-3) [divya] | | * | 37d44f9 2018-10-04 | Leg 3 commit 2 [divya] | | * | 96cc25e 2018-10-04 | Leg 3 commit 1 [divya] | | |/ | * | 24a4520 2018-10-04 | Leg 2 commit 3 (leg-2) [divya] | * | 15f7f4c 2018-10-04 | Leg 2 commit 2 [divya] | * | bdbe0d6 2018-10-04 | Leg 2 commit 1 [divya] | |/ * | 2eedeef 2018-10-04 | Leg 1 commit 3 (leg-1) [divya] * | de42ec7 2018-10-04 | Leg 1 commit 2 [divya] * | 4b0f4df 2018-10-04 | Leg 1 commit 1 [divya] |/ * 0891197 2018-08-16 | Merge branch 'master' of github.com:divyabhushan/proj_mergeOctopus (origin/master, origin/HEAD) [divya] |\ | * c81554d 2015-01-16 | Create a merge commit for the octopus body [Tim Pettersen] * | 742bd20 2015-01-16 | Create a merge commit for the octopus body [Tim Pettersen] |/ * 9d8ae99 2015-01-16 | Merge legs together [Tim Pettersen] * 58b897b 2015-01-16 | Make each leg three commits long [Tim Pettersen] * 62ed117 2015-01-16 | Script to build an octopus [Tim Pettersen]
Thanks for the post. I liked the way all the details have been provided!
Firstly thanks for providing this tutorial from this article I have gathered lots of information. I can say that whatever the information provided by knowledgeHut is more useful to know more about the git.
Written nicely
Leave a Reply
Your email address will not be published. Required fields are marked *