How to get the files modified in a Git Push?

Question

I want to get all the files that has been modified in the last Push.

The Push can have multiple commits.

Currently I am able to to get the Modified files of last commit by this command:

git diff-tree --no-commit-id --name-only -r HEAD

Answer 1

You can use the below:-

git diff --name-only $GIT_PREVIOUS_COMMIT $GIT_COMMIT

Or there is a function in jenkins changeSets which can be used.

Answer 2

git push doesn't modify any files.

git push adds or removes commits. The commits have snapshots of files. The commits do not have changes, they just have files.

Here is a file:

$ cat name-of-file
I am the contents of file name-of-file.

What are the changes I made to this file? I've given you a snapshot, and my question to you is: what are the changes? What key piece of information have I left out of my question?

Think about this for a bit, then read on: Given two snapshots, how will you find changes? Does git diff help?

Which two snapshots would you like to use?

The git diff command can show you what has changed between any two snapshots:

git diff <hash#1> <hash#2>

Note that you must pick two commit hashes. However, you can pick those commit hashes by names. In some existing Git repository, run:

git rev-parse master

and see which commit hash comes out. Then run git log master. What's common between the output of git rev-parse and the first line of git log?

There's a complete (if overwhelming) list of ways to produce Git hash IDs in the gitrevisions documentation, but the most useful ones for everyday work are branch names like master, tag names like v2.1, and remote-tracking names like origin/master. The name HEAD means the current commit,¹ and you can abbreviate it @ if you like.

---

¹The name HEAD also means the current branch name. The way Git decides whether you've used HEAD to talk about a commit hash ID or to talk about a branch name is that some commands need a branch name, and others need a commit hash ID. The git rev-parse command can ask either question, but the default is to find a hash ID. You can use git rev-parse --symbolic-full-name HEAD to ask about the branch name, or, if you're extra-serious, you can use git symbolic-ref HEAD for this case.

---

git diff-tree is the plumbing version of git diff for two commits

The command you identified, git diff-tree, is a way to run git diff from another computer program. If you're running git diff to view the difference yourself, on your own computer screen, you would normally use what Git calls a porcelain command, named after the more-polished, user-oriented parts of a bathroom like the sink. If you're running git diff to get differences to feed to another computer program, you might need to disassemble and re-assemble various equipment along the way, doing what Git calls plumbing, and here you would use git diff-tree to compare two specific commits.

The git diff-tree command has one peculiar extra feature: if you run it with just one commit hash ID, or a name like HEAD that resolves to such a hash ID, Git will extract, from that commit, the list of parent commits. Git will then diff the commit's parent(s) vs that commit. That's what you are seeing when you run git diff-tree options HEAD.

To select two commits to compare, simply use both hash IDs, or names for them, on the command line.

Plain git diff can also compare other things

The porcelain git diff command can invoke, instead of git diff-tree, the git diff-index or git diff-files plumbing commands. These allow you to compare a commit's contents to the contents of the index, or a commit to the work-tree, or the index to the work-tree.

Commits, the index, and the work-tree

Remember that at all times, Git has three active copies of each file:

• The frozen copy in the HEAD commit is available through git show HEAD:path.
• The work-tree copy is an ordinary file that you can see and edit. Git doesn't really use this file though!
• In between these two copies, Git keeps the copy of the file that it will put into the next commit that you make. This copy is in what Git calls, variously, the index, or the staging area, or the cache. You can view this copy with git show :path.

When you run git commit, Git packages up whatever is in the index right then, and freezes those contents to make the new commit snapshot. This is why you must keep running git add so often. The git add command copies the contents of some work-tree file into the index, updating or even creating the index version.

It's the index version of the file that matters to Git. The committed versions are frozen into commits and cannot be changed. They last as long as the commit lasts. The work-tree version of each file is the one you can see and work with, but it's not the one that Git cares about. The index version of each file is the one Git needs, in order to make new commits—and making new commits is the reason Git exists, so Git cares about commits and the index.

The work-tree is for you. Git doesn't want or need it for anything; it's for you to work with, and in, and to copy out of to update the index, that Git needs for new commits.

Summary: commits are snapshots; diff compares snapshots

All of this is how, and why, Git makes snapshots. Git does not deal in changes. It makes snapshots. You can, at any time, compare two snapshots to see what's different between them. What you see will depend on which two snapshots you select.

You can also compare a snapshot (a commit) with a proposed snapshot (the index), or compare a snapshot to your work-tree, or compare your proposed snapshot (the index) to your work-tree. The git diff-tree command only compares actual snapshots. To obtain the other comparisons, you need one of the other plumbing commands, or the porcelain git diff.

The git status command also runs git diff for you. When you use git status, it actually runs two such diffs. One compares the current snapshot, HEAD, to the index—to the proposed commit. This is where changes staged for commit comes from. The second comparison compares the index to the work-tree. This is where changes not staged for commit comes from. Neither the index nor the work-tree have any actual changes; the changes that git status or git diff show are the result of comparing actual snapshots (commits), proposed snapshots (the index), or potential snapshots (the work-tree).

Answer 3

You were almost there. One can achieve this by comparing the current HEAD to the origin branch. git diff-tree --no-commit-id --name-only -r HEAD..origin/master

Example

git checkout master
git pull
touch addnewfile.txt
git add -A
git commit -am "added new empty file"
echo 'test' > addexistingfile.txt
git commit -am "added test in existing file"
git diff-tree --no-commit-id --name-only -r HEAD..origin/master

The last command shows then the output:

addnewfile.txt
addexistingfile.txt