Are there best practices, other than stash, for using git-pull when our workflow includes a lot of uncommitted code?

Question

My team and I are new to Git; we have used CVS so far. We have a remote repository and each one of us has his own repository. Each one of us is working on a feature or bug, but some of us may work on different parts of the same feature.

When one is done they commit and push their changes. Another programmer may want to use that code (for example, if one is working on BL, and another one on UI), but without committing anything as the code may not even compile yet or the working directory may still be dirty.

So far I've only found out a suggestion to use stash, but we find it uncomfortable. We want to pull the code from the remote and simply get it merged with the uncommitted code, but as far as I understand Git, this is probably impossible.

What do you think would be the best way for us to work with the remote?

Answer 1

The Problem

You are suffering from CVS/SVN habits in your work-flow, and especially from the "big patch" mindset.

The Solution

Git has a very cheap branching model and interactive staging. The upshot of this is that you should be working on feature branches, and treating your non-integration branches as patch queues.

So, instead of "code, code, code, code, push, pull, merge, scream" you should do something more manageable:

1. Branch a lot. Make a branch for each mini-feature or change-set.
2. Commit a ton of small, atomic changes to your private branches. git add -p is your friend.
3. Rebase your private branches against your integration branch before merging into it.
4. Push to your integration branch every single time you have a complete change-set or finish a feature.

If you start treating Git commits as patches, and branches as patch queues, you'll end up with a work-flow where people can cherry-pick or merge small change-sets among repositories without getting a migraine. The Git branching model makes it easy, but it's up to your team to break down the work into right-sized pieces.

Answer 2

As long as you are not pushing your own code, you can commit, and then git pull.

A commit will remain private to your repo until your next push.

So you can work on the same 'feature' branch, and still benefit from the push of your colleague.

But if you must also publish your work, then you can use a 'developerX_feature' branch, in order for you to push your own branch, and for other to fetch and then merge your branch to their own 'developerY_feature' branch in their local repo.