GIT - Httqm's Docs

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 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) :