
Git Tips And Workflows - durdn
http://durdn.com/blog/2012/12/05/git-12-curated-git-tips-and-workflows/
======
blhack
Has anybody seen a "git for people who have no idea how to use git" tutorial?

I use git for keeping track of some personal projects, but the extent to which
I understand how to use it is:

"git commit origin master"

We had a hackathon this weekend, and our team had three people on it. I wanted
to make it so that they could also commit code into the same repo (I think
this it the right term?), but had absolutely no idea how to actually make this
happen, and googling didn't seem to give answers that were geared towards
somebody with my level-of-understanding of git.

~~~
mrnil
Read ProGit: <http://git-scm.com/book>

> "git commit origin master"

That's not how to do it :)

> I wanted to make it so that they could also commit code into the same repo

No. Each developer works in her private repo, for sharing work you use a bare
repo people push to / fetch from.

~~~
grannyg00se
>No. Each developer works in her private repo, for sharing work you use a bare
repo people push to / fetch from

What do you mean by a "bare repo"? blhack wants to make it so that they commit
code into the same repo. You could do that by setting up a repository
somewhere, and then each person would clone it.

~~~
mrnil
No, you are mixing things up here. commit is a local operation.

~~~
grannyg00se
I didn't mean to indicate it wasn't.

You could setup a remote and each person could clone that remote.

I left out the details about what you do after you clone (push/pull), but the
point was that there is nothing special about the remote repository as far as
it being "bare". Which turns out isn't right. You can set up a bare repository
with no working directory as 2mur has pointed out. I wonder if that is a
requirement. I always thought that if you clone a repository you can just
start using it as a remote without additional hassle.

~~~
mrnil
> Which turns out isn't right.

Sorry, you lost me; what's not right?

> You can set up a bare repository with no working directory

A bare repository has no working tree per se.

> I wonder if that is a requirement. I always thought that if you clone a
> repository you can just start using it as a remote without additional hassle

You can use bare and non-bare repositories as remote, but you should use only
bare repositories (unless you know what you are doing). Here's a good
explanation: <http://bare-vs-nonbare.gitrecipes.de/>

------
FuzzyDunlop
>> Zero a branch to do something radically different

There's another way to do this:

    
    
        git checkout --orphan new-branch

~~~
0x0
Last time I tried this, I was getting a lot of hassle when switching between
branches that have no common ancestor; .gitignored files disappearing
completely (very annoying when you keep a local config file around etc.),
files left over and "not staged for commit" instead of being removed, etc.
Maybe the "empty root commit" trick would help, I haven't tested that they.

~~~
X-Istence
You are going to have those issues anyway. Since there is no common ancestor
you will have to commit a .gitignore from scratch to that new branch. Files
left over is another common issue, if they are not committed then when you
switch branches they are going to stick around, just like with any other
branch switch...

------
JonnieCache
Curated eh?

~~~
davidw
You have to admit it's a lot better than the recent "12 git tips written by a
finite number of monkeys with typewriters and a finite amount of time".

They're actually pretty good tips, "curated" or ... not - however that would
work.

------
ExpiredLink
> Making ‘git diff’ wrap long lines ... My git diff would not wrap lines and
> leave a lot of information hidden from view in my terminal.

Git is so ... stone age!

~~~
uiri
I think for git diff, this "no wrapping" is a feature not a bug. Git is made
for code in general and Linux (as in, the kernel codebase) in particular. If
your lines are long enough or your terminal is narrow enough that you need
lines to be wrapped, then it may be that your lines are getting too long. The
Linux coding style mandates limiting lines to 80 characters and breaking up
lines which are longer than this limit. This may seem arbitrary and may not be
a great idea in a language which isn't C, but for Linux, this limit allows
levels of indentation which are too deep to be more easily seen because when
code gets into too many levels of indentation it will become very obvious
because several statements end up split across lines. Beyond that, Linus
prefers to chop lines over wrapping, and it seems he just put his personal
preference into his tool because it isn't that big a deal.

------
Nycto
> Search for a string in all revisions of entire git history

The example they show can be shortened by using xargs:

    
    
        git rev-list --all | xargs -n1 git --no-pager grep -F "search string"
    

And here it is as an alias that you can add to your .gitconfig:

    
    
        grepall = "!f() { git rev-list --all | xargs -n1 git --no-pager grep -F \"$1\"; }; f"

------
nicholassmith
I was not aware of the `git config` option for wrapping long files, worth the
price of admission just for that for me.

Edit: there's a `git diff` tip in there, but this comes up a few times so if
anyone needs to do patches from git for svn repos do `git patch --prefix=none
$DIFF1 $DIFF2 > some.patch` share and apply with `patch -p0 < some.patch`.

~~~
spicyj
Or just:

    
    
      git diff REV1 REV2 >some.patch
      patch -p1 <some.patch

~~~
nicholassmith
I found when I was doing that it would occasionally cause problems with
applying in svn properly, but YMMV. I've seen some _really_ over the top
solutions to it as well.

------
temp453463343
These seem like the kind of things you'd end up using once in a blue moon. No
point in memorizing them.

Am I alone in using git extensions? I've been very happy with it and its
ability to display git's "state" right in the window. I usually have one
monitor with VS and one with GitExtentions

------
antirez
>> Making a more recent branch the new master

Why don't just use "git reset --hard <sha-of-the-better-branch>"?

At least if the better-branch and master commit in common is the last commit
in master so no history rewrite will happen when pushing.

------
anilgupta
Git is full of nice tricks, this is a good collection. One it didn't mention
that I use a lot, is manipulating history with human-readable dates:

    
    
      git whatchanged --since="yesterday"
      git revert master@{"1 month ago"}

------
ruswick
I saw the words "curated tips" included on the title and promptly closed the
page.

------
TommyDANGerous
I ask the same thing as blhack, I would like a tutorial. I only know how to
use the basics, pushing to github and heroku, and I've been using it for a
long time.

~~~
Garbage
Try <http://gitimmersion.com/>

