4 ms·

"Never Work on Master" - yes! "Updating Master to Reflect Trunk" - (ignoring the "trunk" misnomer, that's been addressed by other comments). I've recently star

"Never Work on Master" - yes! "Updating Master to Reflect Trunk" - (ignoring the "trunk" misnomer, that's been addressed by other comments). I've recently started taking a step to make this relatively unnecessary. I delete my local master branch. It has made my workflow a lot cleaner! (a) I never accidentally work on master anymore. (b) I never have to switch to master to pull the latest from the remote. (c) One less thing to keep in sync and clutter my repo. Basically, I can now just do `git fetch origin` periodically to get updates from the remote, and then anytime I want to rebase or make a new branch or whatever, I refer to origin/master instead of master. And you can always `git checkout origin/master` if you want. It's the best!

vsbuffalo 13y ago
Isn't it more reasonable to say "never work on master if you're collaborating". If I use Git to manage a single script that only I work on, I don't see the need to create a branch.
- jlgreco 13y ago
  More reasonable is to say "never expect other people to accept your changes to master". Even if you are collaborating, feel free to work on master. You just may (probably will) have to knock it over to another branch when it comes time to give it to other people. Think of it like rewriting history with rebase before you push; the objective is to make it look like you did everything 'correctly' the first time through. Branches are a 'weaker' concept in git than some people seem to think. They are really just labels for commits that can be moved (unlike tags).
  - sandyarmstrong 13y ago
    Sure. You can totally work on master. But I find that it's a lot easier to get confused about what's been merged, and to accidentally make mistakes, when you make a habit of working on master. That's why I find that I make a lot fewer silly mistakes if I just get rid of the local master branch for any repo that I am actively contributing to in a team environment.
- sandyarmstrong 13y ago
  OP was pretty clear that they were coming from a "collaborating in open source" point of view, I thought.
agumonkey 13y ago
This has to be the smallest and most important git tip I've read. Suddenly I see branches as transactions and master a coherent backend.

vsbuffalo 13y ago

Isn't it more reasonable to say "never work on master if you're collaborating". If I use Git to manage a single script that only I work on, I don't see the need to create a branch.

jlgreco 13y ago
More reasonable is to say "never expect other people to accept your changes to master". Even if you are collaborating, feel free to work on master. You just may (probably will) have to knock it over to another branch when it comes time to give it to other people. Think of it like rewriting history with rebase before you push; the objective is to make it look like you did everything 'correctly' the first time through. Branches are a 'weaker' concept in git than some people seem to think. They are really just labels for commits that can be moved (unlike tags).
- sandyarmstrong 13y ago
  Sure. You can totally work on master. But I find that it's a lot easier to get confused about what's been merged, and to accidentally make mistakes, when you make a habit of working on master. That's why I find that I make a lot fewer silly mistakes if I just get rid of the local master branch for any repo that I am actively contributing to in a team environment.
sandyarmstrong 13y ago
OP was pretty clear that they were coming from a "collaborating in open source" point of view, I thought.

agumonkey 13y ago

This has to be the smallest and most important git tip I've read. Suddenly I see branches as transactions and master a coherent backend.