Q:

Git: how to test local code before commit

Let's say I have two files I am working on - "a.txt" and "b.txt". I need to commit my change to "b.txt" but want to keep working on "a.txt" for some more time. I do a "git add b.txt". Now, before I actually commit this change, is there a way to test that the commit will not break the master branch? If I run a test locally, the database tested in my local area would be different than that on master branch as I also have unstaged edits in "a.txt". 
What is the standard procedure for testing in such situations (is it to use 'git stash'?). Or if this situation [needing to test commit in your local area when you also have unstaged edits] is not very common, how do developers avoid the same?

A:

In general it does not really matter what you do before you push. It does not really matter to anyone else what your personal workflow is as long as you push according to the standards of your team.
In the case you described I would use git stash. In detail:

commit b.txt
stash other changes
test
push
pop stash

A:

A good practice is to always do work on branches (see Git Flow for one very common way to do so), and either execute a build against just that branch, or push the branch to a remote (e.g. Bitbucket/GitHub) and have it execute a branch build on your CI server. (Hopefully a build server is part of your development environment.)
The goal is to know that the master build will be green after you merge the branch by having executed the same build and test steps on the branch before you merge.

