8

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?

Todd A. Jacobs
  • 81,402
  • 15
  • 141
  • 199
Ben
  • 398
  • 2
  • 8

3 Answers3

20

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.

Todd A. Jacobs
  • 81,402
  • 15
  • 141
  • 199
8

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.

git 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.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
0

Use branches! You can create branch, commit changes into this branch, push this branch and other people then can fetch this branch and switch (checkout) between branches (even offline). It will not influence your main stable branch (master).

chipiik
  • 1,970
  • 15
  • 15