GIT - Httqm's Docs

You may find yourself in one of these situations :

incomplete rebase :
1. you've run git rebase [options]
2. Git replied with a "wall of text" having the word CONFLICT
3. you're like 😱 and just want to return to before you run git rebase
This is the easy situation since you can go back to that "before state" with : git rebase --abort
complete rebase :
1. you've run git rebase [options]
2. you have / have not run into conflicts and have handled them more or less properly
3. the git rebase command ended successfully and —as for Git— everything is going extremely well
4. you're not satisfied with the code you get because of
  - wrong conflicts management decisions
  - other reasons
  and now, you want to go back to before you run git rebase. Read below

Whatever situation you ended in, and whatever "recovery solution" you applied, you've not fixed anything :

if you had a valid reason to perform a rebase in the first place, that reason still applies
aborting / resetting the operation just lets you return to a known + clean situation where you can handle things differently

Undoing a complete rebase :

What we want to do is return to a previous state of the Git repository, i.e. alter the index and the working directory, which is exactly what git reset --hard is for.
Once we know how to "jump back", we need to find out where to jump back to. git reflog will tell us.

example

read my notes below about dry-running commands

the current situation :

git reflog

31d1afd5 HEAD@{0}:  rebase finished: returning to refs/heads/feature
31d1afd5 HEAD@{1}:  rebase: [commit message]							|
												| A
73595077 HEAD@{27}: rebase: [commit message]							|
24066915 HEAD@{28}: rebase: checkout master
70bef9e4 HEAD@{29}: checkout: moving from master to feature				  C
24066915 HEAD@{30}: rebase finished: returning to refs/heads/master
24066915 HEAD@{31}: pull upstream master: checkout 2406691540f36c1ca45fb3c7881ca9ca4b679465
45e96175 HEAD@{32}: checkout: moving from feature to master
70bef9e4 HEAD@{33}: rebase -i (finish): returning to refs/heads/feature			  C
70bef9e4 HEAD@{34}: rebase -i (pick): [commit message]						|
												| B

with :

A : these are all the commits of the feature branch after I rebased them on master. I did 💩 with the conflicts and I want to get rid of this.
B : this is my previous work on the feature branch, before the rebase I want to undo
It happens that this previous work includes a squash of commits (recognized via the rebase -i), but this has nothing to do with the rebase I want to undo.
C : candidates as for where to jump back to (the difference is the update of master from its remote)

jumping back :
git reset --hard 70bef9e4
```
HEAD is now at 70bef9e4 [commit message]
```
And that's it !

Some documentations suggest commands like :

git reset --hard HEAD@{33} : seems to do the job (but needs further tests to get it clear)
git reset --hard feature@{33} : moves back to some random point (???), I must have missed something

Dry-running commands

It is a safe practice to experiment commands / anything you're not completely sure of on a copy of your data instead of the actual data. To do so, I usually git clone my repository into a temporary place then play until I understand how things work and I feel confident to apply changes to the real data.
But since a cloned repository has an empty reflog, git clone is helpless here.

As a workaround, it is possible to run :

tmpDir="$(mktemp -d)" && cd "$tmpDir" && rsync -av "path/to/gitRepository/" .

In this situation, there is no way to know What would happen if ... ? without actually trying it. However, it is pretty safe to try it :

make sure there are no pending changes : git status should return nothing
just try it : git merge myBranch
2 possibilities :
- everything is going extremely well : enjoy !
- conflicts ! Go back to the previous state : git merge --abort

Listing stuff changed in a branch is the typical use case, but the method below actually works between any commits.

git show commitOldest..commitNewest --name-only --format='' | sort -u

with :

commitOldest : very likely to be the base of the branch
commitNewest : HEAD

Situation

We have :

A---B  master
 \
  C---D  feature

We want the feature branch to be up-to-date with master.
To do so, there are 2 options :

merge
rebase

Comparison of options

command	merge	rebase
result	A---B master \ C-B-D-E feature	A---B master \ C'-D' feature
pros	reliable solution resolve conflicts only once fine for small teams and not very highly active master branch (few changes to sync from master to feature) merging is a non-destructive operation : it only adds the merge commit and makes no change to the branches	linear history / tramlines : easier to follow feature stays parallel to master feature only contain feature-related changes no merge commits
cons	"mixes" master and feature commits into feature, making it more difficult to track changes (git log, git bisect, ...) the above is made even more complex if feature lasts for a long time on a large repo with many committers / branches, this will create many redundant merge commits (and wide tramlines in the commit history)	MUST NOT be used on public branches _can_ lead to fixing conflicts repeatedly when rebasing updating feature with rebase throughout its life makes it a "private" branch, i.e. : code that is not shared to others code living on your hard disk only (SPOF) impairs history : loses chronological order of creation of code (but no big deal, actually) loses context provided by a merge commit : you can't see when upstream changes were incorporated into feature

Which is the best ? Which should I use ?

if applicable (private branch), try rebase
if it turns into conflict resolution hell, give up and use merge
move on

But don't forget :

the answer to the merge vs rebase question is mostly context-dependent
you may avoid most of the pain by having smaller features, meaning shorter-lived feature branches
don't forget to interactively rebase feature (private commits only, as usual) from time to time to :
- re-order commit
- squash commits

so that the development history makes more sense.

git branch --unset-upstream

This procedure looks overkill.

Maybe I was trying to achieve something very specific when writing this (but forgot to note how this was special ).
Or maybe I've gained some extra experience with Git since that time, and would do that differently today.

Anyway, I can't see what using this temporary "squash branch" brings.

Remember the use case that made all this necessary.

Preliminary

Have a look to the definitions if you're not familiar with these terms :

The workflow :

setup :
- I have an upstream repository : upstream
- upstream is forked into myFork
- my local repository is a clone of myFork
initial status of my local repository :
```
‌
	---o---o---o master
```

I create a feature branch and work there :

git checkout -b feature
code then git add
git commit
repeat

‌
	---o---o---o---o---o---o master
	            \
	             o---o---o feature

the work on my feature is done, time to share it with others. To do so, I update master of local repo + fork :
1. git checkout master
2. git pull upstream master
3. git push myFork master
The point of this step is to receive the changes made by others on master, so that conflicts —should there be any— arise on my local repository rather than later while merging on upstream.

I create a branch —from master— to squash my feature branch into :

git checkout master
git checkout -b feature_squash

‌
	---o---o---o---o---o---o master feature_squash
	            \
	             o---o---o feature

I merge squash my feature branch into the squash branch :

git merge --squash feature

Squash commit -- not updating HEAD
Automatic merge went well; stopped before committing as requested

git commit
summarize the list of commit messages into something explaining the single resulting commit :
did this and that as requested by ticket #xyz

‌
	---o---o---o---o--o---o master
	            \          \
	             \          o feature_squash
	              \        /
	               o--o---o feature

I merge my squash branch into master :

git checkout master
git merge feature_squash

‌
	---o---o---o---o--o---o---o master feature_squash
	            \          \ /
	             \          o
	              \        /
	               o--o---o feature

Delete the squash branch :

git branch -d feature_squash

‌
	---o---o---o---o--o---o---o master
	            \          \ /
	             \          o
	              \        /
	               o--o---o feature

Push the changes (now on master) to my fork :
git push myFork master
merge myFork into upstream : to be done with GitLab
delete the local feature branch :
Since feature has been merged into feature_squash —that doesn't exist anymore— Git will consider feature as not merged and you'll have to force it with :
git branch -D feature

Those who already f*cked up their repository know what I mean
For others : there _may_ be a day when you'll realize you made commits on myFeatureBranch (which is fine) and others on master (Hell starts here!)

After hours of sweating / swearing / cleaning, you decide it would be wise to set up some safeguard to avoid living this again.

The title of this article as well as the solution below refer to master because it's a pretty common situation, but you can —of course— apply this to any branch .

Here come the Git hook scripts :

these are shell scripts found in myGitRepo/.git/hooks
a hook is an opportunity to run a custom action when an event occurs. For instance : when git commit is run, trigger a script before actually committing things —this is what the pre-commit hook is for

Client-side hooks are not copied when cloning a repository (details).

cd root/of/myGitRepo

cat << 'EOF' > .git/hooks/pre-commit
#!/usr/bin/env bash

currentBranch="$(git rev-parse --abbrev-ref HEAD)"
if [ "$currentBranch" == 'master' ]; then
	echo 'None shall pass!'
	exit 1
fi
EOF
chmod +x .git/hooks/pre-commit

Check :
ls -l .git/hooks/pre-commit && cat $_

I've found ONE edge case where I still need to be able to commit to master : when finalizing a merge --squash. So here's a hack to workaround the pre-commit hook script without entirely disabling it :

add to the code :

#!/usr/bin/env bash

currentBranch="$(git rev-parse --abbrev-ref HEAD)"
if [ "$currentBranch" == 'master' -a "$c2m" != 'yes' ]; then
	echo 'None shall pass!'
	exit 1
fi

explicitly raise a flag to actually commit to master :
c2m=yes git commit

I have :

	          F-------G myBranch
	         /
	A---B---C---D---E master

A standard merge would give :

	          F-------G myBranch
	         /         \
	A---B---C---D---E---H master

I want :

	A---B---C---D---E---H master myBranch

git merge --squash is what you're looking for .
I play with this command in gitMergeSquash.sh, which outputs :
with git merge :

with git merge --squash :

When starting working on an existing remote branch :

git checkout --track remote/branch

Branch branch set up to track remote branch branch from remote.
Switched to a new branch 'branch'

This :

creates the local branch branch
sets remote/branch as the upstream of the new local branch branch
checkouts the new local branch branch

You can not run :

git checkout --track remote/branch myLocalBranch

fatal: Cannot update paths and switch to branch 'branch' at the same time.
Did you intend to checkout 'myLocalBranch' which can not be resolved as commit?

When publishing a local branch :

git push -u remote branch

Anytime :

git branch -u remote/branch localBranch

Branch localBranch set up to track remote branch branch from remote.

localBranch must exist before doing this.

git branch -u remote/branch

Branch currentLocalBranch set up to track remote branch branch from remote.

This construct declares remote/branch as the upstream of the currently checked out local branch currentLocalBranch, which may not be your intention.

git log branchToExclude..branchToList
- while sitting on the branch having the commits to list :
  git log --oneline master..HEAD
git log branchToList --not branchToExclude
git cherry -v branchToExclude branchToList
- the 2^nd parameter, if omitted, defaults to the current branch. So, while sitting on the branch we want to list :
  git cherry -v branchToExclude

These commands also state at which commit 2 branches diverged : the oldest reported commit is the common ancestor of both branches.

This typically happens when you've committed on master, then realized that those commits better suit a feature branch. In other words, how may I go from this :

	A---B---C---D---E master

to this :

	      C---D---E newBranch
	     /
	A---B master

Before going further, make sure you have no uncommitted changes left.

Method 1 : (source) :

create a new branch + "jump" on it :
git checkout -b newBranch
make master point to the commit that is the base of newBranch :
git branch -f master HEAD~3

3 is the number of commits to move from master to newBranch

Method 2 (source) :

git branch newBranch      # Create a new branch, saving the desired commits
git reset --hard HEAD~3   # Move master back by 3 commits (GONE from master)
git checkout newBranch    # Go to the new branch that still has the desired commits


NB : instead of resetting to a nb of commits, you can reset until a specific commit ID :
git reset --hard a1b2c3d4

How it works (source) :

You want to go back to C, and move D and E to the new branch. Here's what it looks like at first:

A-B-C-D-E (HEAD)
        ↑
      master

After git branch newBranch:

    newBranch
        ↓
A-B-C-D-E (HEAD)
        ↑
      master

After git reset --hard HEAD~2:

    newBranch
        ↓
A-B-C-D-E (HEAD)
    ↑
  master

Since a branch is just a pointer, master pointed to the last commit. When you made newBranch, you simply made a new pointer to the last commit. Then using git reset you moved the master pointer back two commits. But since you didn't move newBranch, it still points to the commit it originally did.

Method 3 : cherry-picking (source) :

NB : if you checkout newBranch from the existing master branch it ALREADY has those three commits included in it, so there's no use in picking them. At the end of the day to get what the OP wanted, you'll still have to do some form of reset --hard HEAD.

https://stackoverflow.com/questions/1628563/move-the-most-recent-commits-to-a-new-branch-with-git#comment-36690393



Step 1 - Note which commits from master you want on a new branch :

git checkout master
git log

Note the hashes of (say 3) commits you want on newBranch. Here I shall use:
C commit: 9aa1233
D commit: 453ac3d
E commit: 612ecb3

    Note: You can use the first seven characters or the whole commit hash

Step 2 - Put them on the new branch

git checkout newBranch
git cherry-pick 612ecb3
git cherry-pick 453ac3d
git cherry-pick 9aa1233

NB : the order is important. You want to do the oldest commits first

GIT - HowTo's about "branches"

How to undo a rebase ?

You may find yourself in one of these situations :

Undoing a complete rebase :

example

Dry-running commands

How to test / simulate / dry-run a merge without actually making changes ?

How to list all files altered in a branch ?

Should I merge or rebase my feature branch to keep it up-to-date with master ?

Situation

Comparison of options

Which is the best ? Which should I use ?

How to stop tracking a remote branch ?

Workflow of upstream + fork + feature branch ending with a merge --squash

Preliminary

The workflow :

How to forbid commits on the master branch ?

Situation

Details

Solution

Alternate solution

How to merge a branch as a single commit (i.e. merge + squash) ?

Situation

Solution

How to track a remote branch ?

When starting working on an existing remote branch :

When publishing a local branch :

Anytime :

How to list commits from a specific branch only ?

How to move commits to another branch ?

Method 1 : (source) :

Method 2 (source) :

How it works (source) :

Method 3 : cherry-picking (source) :