
How To GitHub: A Complete Guide to Forking, Branching, Squashing and Pulls - Mizza
http://gun.io/blog/how-to-github-fork-branch-and-pull-request/
======
DrCatbox
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.

~~~
MBlume
To be fair, I spent a few days trying to wrap my head around Mercurial so I
could commit to PyPy, lost a bunch of code, and switched to just using the hg-
git bridge. It's mostly about what you're used to.

~~~
gnosis
Mercurial is far from being the only alternative to git. For instance, have
you tried bzr?

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

~~~
snprbob86
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.

~~~
vedang
`The golden rule is: rebase your own stuff all day long, as much as you want.
Don't rebase once you've published.`

This is a great rule of thumb, which I have had to repeatedly drill into my
team-mates. The crux of the problem, I've come to realise, is that people
can't differentiate between a "local" commit and a "published" commit.

Git tutorials need to focus a bit more on the nature of git than on simply
showing the basic operations.

~~~
snprbob86
Tell your team to add these aliases to their .gitconfig:

    
    
        [alias]
          l = log --oneline --decorate --graph
          la = log --oneline --decorate --graph --all
    
    

\--online --graph : Will really help visual learners

\--decorate : Makes it super obvious how labels and tags work

\--all : Extends the usefulness of --decorate to branches and remotes

------
hardik988
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
Not only a good guide to Git but also a good guide to open source
collaboration for new-comers.

------
Inversechi
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
Could this be linked to somewhere on the GH site, please?

------
gcb
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/>

they mention that they release the source, and list alternatives to the
terminated product BEFORE sending you over to their google docs.

~~~
slig
If you're interested, you should check <https://github.com/Pita/etherpad-lite>

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

