5 ms·

How To GitHub: A Complete Guide to Forking, Branching, Squashing and Pulls

306 points by Mizza 15y ago

Radzell 15y ago
Thanks managing a team github problem sometimes feels like a full time job on top of coding. It doesn't get errors a lot, but when it does they stick around.
- Mizza 15y ago
  Well, then I hope this guide is useful! Send it out to your team, have them take a look at it. I enjoy the disorganized nature of GitHub, but there are some serious faults. I think they can probably be overcome by rationality and standard practice (clear communication, being polite, documentation, etc). Politically, I see myself as a 'vulcan anarchist' so it's fun to see GitHub as a little microcosm of intelligent anarchy. From order, chaos. From chaos, order.
- DrCatbox 15y ago
  You should try mercurial really. A huge team at work, never any mercurial problems/error messages. Just code man. Just code.
hardik988 15y ago
Thanks for this. I'm still learning git and didn't know about the squash feature.. Now that I think about it, even if I spend 5 minutes on HN, I manage to learn something new! Cheers.
dudus 15y ago
Not only a good guide to Git but also a good guide to open source collaboration for new-comers.
gcb 15y ago
offtopic, but looking on the main page for gun.io i saw their tech stack, and i went to see what etherpad was about, and saw one of the best Descontinued Product Page ever. http://etherpad.com/ http://etherpad.com/ they mention that they release the source, and list alternatives to the terminated product BEFORE sending you over to their google docs.
- slig 15y ago
  If you're interested, you should check https://github.com/Pita/etherpad-lite https://github.com/Pita/etherpad-lite
DrCatbox 15y ago
I tried using git for several weeks now and still cant manage to do the simplest things, like maintain a work repo and a sync repo and then pull/merge between them before pushing upstream from sync. It feels like I have to know the internals of git workings just to perform a simple action, and I need to know all the side-effects of its actions, and how to fix those as well. With mercurial all the commands I need to know are hg log, diff, incoming, outgoing, pull, update push and merge. With git I need to know at least two or three flags for each command where each flag is really special to that command and using/not using it changes everything. With mercurial I just know -p -r and -l for limits thats it. I hate git with a passion now. Its like forcing everything through its world view, for the tinies action it barks are you with insane messages. Version control systems are supposed to model commits or sets of changes on a repo, not model and show you their own internal representation of what it thinks about my code. Also Ive noticed most git tutorials really simple things (like this is how you do cvs but now with git), while "the rest" is left to some black ninja voodo magic expert dudes who "get" it. And this is just another tutorial to work in a very specific environment using git. Im so glad we use mercurial at work right now.
- huherto 15y ago
  May be I was so used to subversion. I understand that git is more flexible and powerful, but it makes me feel dumb. Specially because so many smart people love it.
  - lnguyen 15y ago
    If you haven't seriously used branches before, git can be a bit hard to wrap your head around. And trying to map it back to what you're familiar with in svn adds to the frustration. The best thing to do is create some "play" git repositories and see what happens when you run any command. You can also run "git clone" on local directories to mimic actual remote repositories without having to set anything up. Don't worry about screwing anything up as you can just delete the directory and start over.
    - ColdAsIce 15y ago
dfc 15y ago
Rebasing is the thing I need a good howto for. Some documents give me the impression that rebasing is evil and then others like this one make it seem harmless.
- senko 15y ago
  Never rebase public branches, ie. ones that other people might have checked out. It will rewrite history and make them sad. Rebasing your own branches other people have no business checking out is perfectly fine. Bonus points for never doing a (non fast-forward) merge of upstream branch into your branch (if you plan to merge your branch back into the upstream one later). If you do need to update your branch before it gets merged, rebase it instead. What to do if your public branch needs to be updated from upstream? Create a fresh one off of upstream, merge your branch into it, and continue working on a new one.
- snprbob86 15y ago
  Start by always using rebase --interactive (or just -i) to help you get a feel for it's behavior. Learn how to use `git reflog` to recover if you botch it up. The golden rule is: rebase your own stuff all day long, as much as you want. Don't rebase once you've published. Rebase is a tool for reasoning about your changes as a collection of logical transformations. It's to help you prepare a patch to share with the team. Interactive rebasing (and squashing, fixups, etc) are there to let you checkpoint your work as you go and to give you the freedom to come back and reason about your patches later. Once I got comfortable with rebase, I began using it as a tool to help me write code. By that I don't mean putting characters into a text file. I mean teasing out isolated changes without interrupting the flow of bigger tasks. The fear of rebase comes from people who are used to centralized version control systems. They view their version control system as a tool for backups and accountability. Git provides sha1 hashes for backups/security/accountability. Everything else git does is to help you write, reason about, communicate about, share, separate, combine, and otherwise fiddle with patches as logical changes. If you don't want people to rewrite history, don't give them push access to your repository. Everyone has their own, right? If you want to prevent people from accidentally rewriting canonical history, disable --force pushes to your team's shared repository using a pre-commit hook. But in reality, that won't be an issue because as soon as some one accidentally force pushes, everyone else will have their pulls broken and know the perpetrator immediately identified for flogging.
Inversechi 15y ago
This is exactly the kind of article I was looking for! I'm still very much learning git and eager to commit to more Repos on Github however have been unsure about how to do this effectively.
nathell 15y ago
Could this be linked to somewhere on the GH site, please?

306 points by Mizza 15y ago

Thanks managing a team github problem sometimes feels like a full time job on top of coding. It doesn't get errors a lot, but when it does they stick around.

Mizza 15y ago
Well, then I hope this guide is useful! Send it out to your team, have them take a look at it. I enjoy the disorganized nature of GitHub, but there are some serious faults. I think they can probably be overcome by rationality and standard practice (clear communication, being polite, documentation, etc). Politically, I see myself as a 'vulcan anarchist' so it's fun to see GitHub as a little microcosm of intelligent anarchy. From order, chaos. From chaos, order.
DrCatbox 15y ago
You should try mercurial really. A huge team at work, never any mercurial problems/error messages. Just code man. Just code.

hardik988 15y ago

Thanks for this. I'm still learning git and didn't know about the squash feature.. Now that I think about it, even if I spend 5 minutes on HN, I manage to learn something new! Cheers.

dudus 15y ago

Not only a good guide to Git but also a good guide to open source collaboration for new-comers.

gcb 15y ago

offtopic, but looking on the main page for gun.io i saw their tech stack, and i went to see what etherpad was about, and saw one of the best Descontinued Product Page ever. http://etherpad.com/ http://etherpad.com/ they mention that they release the source, and list alternatives to the terminated product BEFORE sending you over to their google docs.

slig 15y ago
If you're interested, you should check https://github.com/Pita/etherpad-lite https://github.com/Pita/etherpad-lite

DrCatbox 15y ago

I tried using git for several weeks now and still cant manage to do the simplest things, like maintain a work repo and a sync repo and then pull/merge between them before pushing upstream from sync. It feels like I have to know the internals of git workings just to perform a simple action, and I need to know all the side-effects of its actions, and how to fix those as well. With mercurial all the commands I need to know are hg log, diff, incoming, outgoing, pull, update push and merge. With git I need to know at least two or three flags for each command where each flag is really special to that command and using/not using it changes everything. With mercurial I just know -p -r and -l for limits thats it. I hate git with a passion now. Its like forcing everything through its world view, for the tinies action it barks are you with insane messages. Version control systems are supposed to model commits or sets of changes on a repo, not model and show you their own internal representation of what it thinks about my code. Also Ive noticed most git tutorials really simple things (like this is how you do cvs but now with git), while "the rest" is left to some black ninja voodo magic expert dudes who "get" it. And this is just another tutorial to work in a very specific environment using git. Im so glad we use mercurial at work right now.

huherto 15y ago
May be I was so used to subversion. I understand that git is more flexible and powerful, but it makes me feel dumb. Specially because so many smart people love it.
- lnguyen 15y ago
  If you haven't seriously used branches before, git can be a bit hard to wrap your head around. And trying to map it back to what you're familiar with in svn adds to the frustration. The best thing to do is create some "play" git repositories and see what happens when you run any command. You can also run "git clone" on local directories to mimic actual remote repositories without having to set anything up. Don't worry about screwing anything up as you can just delete the directory and start over.
  - ColdAsIce 15y ago

dfc 15y ago

Rebasing is the thing I need a good howto for. Some documents give me the impression that rebasing is evil and then others like this one make it seem harmless.

senko 15y ago
Never rebase public branches, ie. ones that other people might have checked out. It will rewrite history and make them sad. Rebasing your own branches other people have no business checking out is perfectly fine. Bonus points for never doing a (non fast-forward) merge of upstream branch into your branch (if you plan to merge your branch back into the upstream one later). If you do need to update your branch before it gets merged, rebase it instead. What to do if your public branch needs to be updated from upstream? Create a fresh one off of upstream, merge your branch into it, and continue working on a new one.
snprbob86 15y ago
Start by always using rebase --interactive (or just -i) to help you get a feel for it's behavior. Learn how to use `git reflog` to recover if you botch it up. The golden rule is: rebase your own stuff all day long, as much as you want. Don't rebase once you've published. Rebase is a tool for reasoning about your changes as a collection of logical transformations. It's to help you prepare a patch to share with the team. Interactive rebasing (and squashing, fixups, etc) are there to let you checkpoint your work as you go and to give you the freedom to come back and reason about your patches later. Once I got comfortable with rebase, I began using it as a tool to help me write code. By that I don't mean putting characters into a text file. I mean teasing out isolated changes without interrupting the flow of bigger tasks. The fear of rebase comes from people who are used to centralized version control systems. They view their version control system as a tool for backups and accountability. Git provides sha1 hashes for backups/security/accountability. Everything else git does is to help you write, reason about, communicate about, share, separate, combine, and otherwise fiddle with patches as logical changes. If you don't want people to rewrite history, don't give them push access to your repository. Everyone has their own, right? If you want to prevent people from accidentally rewriting canonical history, disable --force pushes to your team's shared repository using a pre-commit hook. But in reality, that won't be an issue because as soon as some one accidentally force pushes, everyone else will have their pulls broken and know the perpetrator immediately identified for flogging.

Inversechi 15y ago

This is exactly the kind of article I was looking for! I'm still very much learning git and eager to commit to more Repos on Github however have been unsure about how to do this effectively.

nathell 15y ago

Could this be linked to somewhere on the GH site, please?