Revert multiple commits – GIT REVERT
-> git revert 0522aefa66c630792b8c9a1b7ffc7ecb3cdf3fd2 db91a76b404be588008f58c2152d9dd6a8745bad 789a4496542b66db86d7572254d19f8190a43055 ac1fbd98e2fae29082c90ab7cfb5e32d274e5ddd 357a955e6353535e7803db2cba17 acdaf4d80cb4 692250fd5362698a1e47176572e52df001582d27 94e83838471548c617ad1bde0bc5abaaa340f6a9 3b0654778599fc1d384f998dae27cb39b1b02518 –no-commit
-> git commit -m “REVERT INCIDENT”
-> git push
Run below command in GIT BASH to list all the GIT BRANCHES:
-> for branch in `git branch -r | grep -v HEAD`;do echo -e `git show –format=”%ai %ar by %an” $branch | head -n 1` \\t$branch; done | sort -r
->Merge from current to next : git merge –no-ff <branch name>
->Merge from master to continuous : git merge -Xignore-all-space –no-ff master
Special Merge Commands:
GIT MERGE COMMANDS (Execute within the target branch while merging MASTER into some target branch)
-> git config –local merge.renameLimit 9000
# …cannot be used with –global
-> git merge –verbose –no-commit –strategy=recursive –strategy-option=patience –strategy-option=find-renames=80% origin/master
-> git merge –verbose –no-commit –strategy=recursive –strategy-option=patience –strategy-option=rename-threshold=80% origin/master
# …remember that any NEW files in the old directory will have to be “moved” to the new one.
The important parameters are:
• merge.renameLimit 9000 (ie. it will check up to 9000 deleted-files VS created-files to see if they’ve just been moved or renamed)
• –strategy-option=patience (I don’t know what this does but is sure sounds good!)
• –strategy-option=find-renames=80% (ie. if a created-file is 80% the same as a deleted-file, it is assumed to be the same file just renamed or moved)
10) Show File changes between two commits:
->git diff –name-only SHA1 SHA2
Ex: git diff –name-only ca2995b3 8aa09359
11) git checkout continuous
git pull –all -v
git reset –hard 31363e7
# un – protect continuous
# git push -f origin continuous
# protect continuous
now can merge master into cont
12) GIT File name to long complaint:
Run this command to get rid of that complaint: git config –system core.longpaths true
13) Revert/Delete set of commits – GIT REBASE
-> git rebase –preserve-merges –committer-date-is-author-date -i 6c58be79af5d4d7df463521d1a08ad7831258b5b :
1. Opens all the commits made after 2595ff9a7e729ae1968bbf8f8e7bd677d3772db5 in editor mode.
2. Delete the commits which you want to get rid of and save it (:wq)
3. Rebasing will be applied.
4. If any merge conflicts occur after deletion, re-basing stops and alerts us to fix them. Once fixed….rebasing continues automatically.
5. If re-basing doesn’t continue automatically, execute -> “git rebase –continue”
-> git rebase –committer-date-is-author-date 05ab02348b4b2e07549fe94db1dc86be7dea8be2
1. After the above steps, the commit date changes to current dat. in order to get-rid of it and revert to our commit-timestamps, execute this command.
-> git push –force
1. Finally execute this to push re-basing to remote.
How rebase works
Suppose you want to rebase my-feature onto master. The rebase process finds which commits in my-feature are not present in master, and cherry-picks them. Afterwards, your branch is reset to the HEAD of the branch you want to rebase on (master in this case), and commits are sequentially applied afterwards.This means that now all your commits sit on top of the other branch’s HEAD, which is now a base for your branch.
It has the advantage of keeping a clean, linear history. It also does not create merge commits (as no merge is actually happening).It has the disadvantage of rewriting commit hashes, and subsequently rewrite history, making it unsuitable for tracking remote branches.In addition, rebase can be used for editing, amending, squashing and deleting commits.
How merge works
When merging a branch into another one, the history of the two branches intersect. This means that the history order will be preserved in a chronological way: the commits will be ordered by date.
A merge can be either fast-forward or not: fast-forward means that no merging process has to be done: a fast-forward merge’s result looks exactly the same as a rebase result (even though the process still remains very different).
If a merge is non fast-forward, the history of the two branches must be intersected. As a result of the process, an additional commit is added to the repository, carrying the merge result.It has the advantage of keeping history consistent (commit hashes are not altered) and preserving chronological history.It has the disadvantage of making it harder to track a branch’s changes, and scattering a branch’s commits throughout the repository. Merge is also able to use different merging strategies, and squash the merge in a single commit (strongly discouraged).