4 ms·

I watched the video, and it looks really cool, but the way I was taught to use git was to create a branch, make your changes, commit the changes, then merge bac

I watched the video, and it looks really cool, but the way I was taught to use git was to create a branch, make your changes, commit the changes, then merge back to master, rinse and repeat. Is that not the standard way of using github? How does that look in this scenario? Everything almost always being in a straight line, and the author always working on 'master' makes it a bit confusing to imagine in a real-world scenario (based on my Git usage).

jlgreco 13y ago
If I am only working on one thing at the moment, I typically just make a lot of commits on master then rebase them all before publishing them. I only start branching if I'm doing multiple things at once. (And it is pretty easy to move changes to a branch later if you want to start work on something else.)
- zeppelinnn 13y ago
  I think this is correct for personal projects, but when working with teams it's better to create dev branches especially for major feature/functionality additions. I personally try to stick with separate branches and then merge just to uphold that practice, as well as being able to revert/find your mess-ups quicker.
  - jlgreco 13y ago
    Feature branches in git most frequently only live on the developers machine, often for only a few hours,(unlike feature branches in centralized version control systems, which are almost always long-lived) so there is no harm in not branching if you're only working on something thing . If it is a feature that multiple people need to work on, or needs to be worked on for more than a few hours, then a separate feature branch is of course the correct thing to do. Branches in git are literally just pointers to commits (write a sha1 object to any file under refs/heads to see what I mean) so they don't really buy you much if you're not frequently switching between locations in the DAG, but can be created retroactively with zero hassle if you do find yourself needing them. Basically, what you do with your private DAG doesn't matter at all, what is important is that you only publish things that are sensible.

jlgreco 13y ago

If I am only working on one thing at the moment, I typically just make a lot of commits on master then rebase them all before publishing them. I only start branching if I'm doing multiple things at once. (And it is pretty easy to move changes to a branch later if you want to start work on something else.)

zeppelinnn 13y ago
I think this is correct for personal projects, but when working with teams it's better to create dev branches especially for major feature/functionality additions. I personally try to stick with separate branches and then merge just to uphold that practice, as well as being able to revert/find your mess-ups quicker.
- jlgreco 13y ago
  Feature branches in git most frequently only live on the developers machine, often for only a few hours,(unlike feature branches in centralized version control systems, which are almost always long-lived) so there is no harm in not branching if you're only working on something thing . If it is a feature that multiple people need to work on, or needs to be worked on for more than a few hours, then a separate feature branch is of course the correct thing to do. Branches in git are literally just pointers to commits (write a sha1 object to any file under refs/heads to see what I mean) so they don't really buy you much if you're not frequently switching between locations in the DAG, but can be created retroactively with zero hassle if you do find yourself needing them. Basically, what you do with your private DAG doesn't matter at all, what is important is that you only publish things that are sensible.