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?
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 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.
You only ever, ever push something that actually works. You may have files or changes that you were working on that you don’t want to push. You must make sure that your branch that doesn’t have these files or changes will work. Your branch may have additional changes made by someone else that may have broken your new code (which the person pushing those changes couldn’t check for because they don’t have your new code). So:
-
Remove the changes that you don’t want to push. Easiest done by using “stash” first, then removing the changes.
-
Pull the latest state of the branch. Any conflicts are best handled at this time. Make sure that your code works with these changes.
-
Push your complete code. You always push what you have tested. Obviously your complete code doesn’t contain the bits that you didn’t work.
Then you can use stash again to restore the changes you were working on.