4 ms·

Within git, branches are super-lightweight and easy to create. If you're coordinating with other developers (or finding yourself needing to shuttle code around

Within git, branches are super-lightweight and easy to create. If you're coordinating with other developers (or finding yourself needing to shuttle code around between machines frequently) it would be worth creating a remote dev branch in your repo. With a dev branch, you have the flexibility to just what you describe-- commit broken or half-completed code in order to move to another box-- and still clean up the commit or merge it with others before you move it to your "master" branch for deployment or sharing.

dustingetz 16y ago
yeah, but then your logs and diffs get messy because you can't stage in hunks. or maybe I haven't grokked how. maybe `git merge stagingbranch -no-commit`?
- avar 16y ago
  Yes, you haven't grokked it. When you work on a development branch like this you can rewrite its history with git rebase --interactive before pushing your commits to the main branch.
  - bdonlan 16y ago
    You do have to be a bit careful not to introduce broken revisions as a part of your history-rewriting there, of course. Generally if you only use squash (which is sufficient to clean up "sync to laptop"-like changes) it won't be a problem though - it's when you start deleting or reordering commits that interesting things happen.
- pilif 16y ago
  OF COURSE you can stage in hunks. That's why the index is so awesome in git. Try git add -p (or -i, I prefer -p though) and you will see (and incidentally, never ever use commit -a any more) And to alter commits before merging, use rebase -i and make use of the edit and squash options.
  - prodigal_erik 16y ago
    This workflow always seems backwards to me. "git add -p" lets me stage partial commits in the index, where I cannot build or test them. What I want to do is stage them into my working copy from somewhere else. I wonder how hard "git stash apply -p" would be to add....
    - sh4na 16y ago
      Switch to a new branch before commiting, commit only what you want then switch back. Doing a git checkout -b new-branch-for-this-bit-of-code is quick and painless if you want to stage things while you're working, doesn't change anything since you're creating a new branch from your current point, and gives you much easier logging, diffing and merging capabilities later on. This is one of the recommended workflows for git, in fact. You can also commit parts then stash the rest, test, pop the stash, commit more, stash, test, etc, etc. You can add things to commits with --amend, so you can tweak them if you notice something is missing after you added things with git add -p and then commited. I do this a lot when I want to split a commit and use git add -p. If you really want to test things from somewhere else, use git new-workdir to create a new working dir based off your local clone. Whatever you stash or commit to one, the other will see, since they're really pointing to the same local git clone (if you look at the .git/ dir of a workdir, you'll notice it's all symlinks to the original clone). Just make sure every local workdir you create like this is on a different branch, otherwise it will get confused when you change things on one side (because, of course, they're all pointing to the same local clone, but suddenly the local files won't match). I use this to have a "test workdir", which is based on a clean and permanently updated branch, where I cherry-pick/merge from the work branch into it, build and test, without having to stash on my work branch, reconfigure things and otherwise stop the coding workflow.

dustingetz 16y ago

yeah, but then your logs and diffs get messy because you can't stage in hunks. or maybe I haven't grokked how. maybe `git merge stagingbranch -no-commit`?

avar 16y ago
Yes, you haven't grokked it. When you work on a development branch like this you can rewrite its history with git rebase --interactive before pushing your commits to the main branch.
- bdonlan 16y ago
  You do have to be a bit careful not to introduce broken revisions as a part of your history-rewriting there, of course. Generally if you only use squash (which is sufficient to clean up "sync to laptop"-like changes) it won't be a problem though - it's when you start deleting or reordering commits that interesting things happen.
pilif 16y ago
OF COURSE you can stage in hunks. That's why the index is so awesome in git. Try git add -p (or -i, I prefer -p though) and you will see (and incidentally, never ever use commit -a any more) And to alter commits before merging, use rebase -i and make use of the edit and squash options.
- prodigal_erik 16y ago
  This workflow always seems backwards to me. "git add -p" lets me stage partial commits in the index, where I cannot build or test them. What I want to do is stage them into my working copy from somewhere else. I wonder how hard "git stash apply -p" would be to add....
  - sh4na 16y ago
    Switch to a new branch before commiting, commit only what you want then switch back. Doing a git checkout -b new-branch-for-this-bit-of-code is quick and painless if you want to stage things while you're working, doesn't change anything since you're creating a new branch from your current point, and gives you much easier logging, diffing and merging capabilities later on. This is one of the recommended workflows for git, in fact. You can also commit parts then stash the rest, test, pop the stash, commit more, stash, test, etc, etc. You can add things to commits with --amend, so you can tweak them if you notice something is missing after you added things with git add -p and then commited. I do this a lot when I want to split a commit and use git add -p. If you really want to test things from somewhere else, use git new-workdir to create a new working dir based off your local clone. Whatever you stash or commit to one, the other will see, since they're really pointing to the same local git clone (if you look at the .git/ dir of a workdir, you'll notice it's all symlinks to the original clone). Just make sure every local workdir you create like this is on a different branch, otherwise it will get confused when you change things on one side (because, of course, they're all pointing to the same local clone, but suddenly the local files won't match). I use this to have a "test workdir", which is based on a clean and permanently updated branch, where I cherry-pick/merge from the work branch into it, build and test, without having to stash on my work branch, reconfigure things and otherwise stop the coding workflow.