Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Visualized Git practices for team: branch, merge, rebase

kentnguyen.com

Post reply on HN
Print view View original

21–30 of 39 posts

Re: Visualized Git practices for team: branch, merge, rebase

#21

Post by palish »

alinajaf wrote: post #14
martco wrote: post #9

I agree with the author that learning and becoming handy with git cli is very important. I don't agree that you should stop using a GUI for git, especially if you've already cut your teeth on the command line. Tower, a git GUI for Mac OS X, has a great interface and ties in very well with the core git functionality. I've learned a lot about stashing, merge conflict resolution, and cherry-picking, thanks to that app.…

I've tried a number of gui tools for git but I keep coming back to the command line. You can format your `git log` output to give you your network graph and `git add -[pi]` allow me to stage hunks of diffs much like a GUI tool might. I think more than what tools you use (gui or command line) it's really useful to get an understanding of gits internal model. It informs day-to-day use and is a great example of an elega…

You can format your `git log` output to give you your network graph...

Really? Awesome. How?

Re: Visualized Git practices for team: branch, merge, rebase

#22

Post by molecule »

palish wrote: post #21
alinajaf wrote: post #14

Earlier quoted context omitted.

I've tried a number of gui tools for git but I keep coming back to the command line. You can format your `git log` output to give you your network graph and `git add -[pi]` allow me to stage hunks of diffs much like a GUI tool might. I think more than what tools you use (gui or command line) it's really useful to get an understanding of gits internal model. It informs day-to-day use and is a great example of an elega…

You can format your `git log` output to give you your network graph... Really? Awesome. How?

git log --graph

http://book.git-scm.com/3_reviewing_history_-_git_log.html

Re: Visualized Git practices for team: branch, merge, rebase

#23

Post by SeoxyS »

Can somebody explain how rebasing affects shared histories. Say I'm rebasing a feature branch that's shared via github, will rewriting the commit history prevent me from pushing?

I avoid `git commit --amend` because of that, and thought that `rebase` had the same problem. So for that reason, I always use `merge`. Am I mistaken?

Re: Visualized Git practices for team: branch, merge, rebase

#24

Post by tednaleid »

palish wrote: post #21
alinajaf wrote: post #14

Earlier quoted context omitted.

I've tried a number of gui tools for git but I keep coming back to the command line. You can format your `git log` output to give you your network graph and `git add -[pi]` allow me to stage hunks of diffs much like a GUI tool might. I think more than what tools you use (gui or command line) it's really useful to get an understanding of gits internal model. It informs day-to-day use and is a great example of an elega…

You can format your `git log` output to give you your network graph... Really? Awesome. How?

This is the alias I use in my `.gitconfig` for running log with graphical output (got this somewhere, not sure where):

    [alias]
      l = log --graph --pretty='%Cred%h%Creset -%C(yellow)%d%Creset %s %Cblue[%an]%Creset %Cgreen(%cr)%Creset' --abbrev-commit --date=relative
The omglog gem is also useful for working with git. It gives you a graphical log of the entire repo (not just your current branch as a normal git log does), and it auto updates by monitoring for file system changes (OSX only).

To install:

    sudo gem install omglog
Then just run `omglog` in the root of your repo, or use this alias in your `.gitconfig` to automatically run it from the root of whatever repo you're in:

    [alias]
        omg = !omglog
(shell commands, starting with a "!" command in a git alias are always run from the root of a repository)

Re: Visualized Git practices for team: branch, merge, rebase

#25

Post by alinajaf »

palish wrote: post #21
alinajaf wrote: post #14

Earlier quoted context omitted.

I've tried a number of gui tools for git but I keep coming back to the command line. You can format your `git log` output to give you your network graph and `git add -[pi]` allow me to stage hunks of diffs much like a GUI tool might. I think more than what tools you use (gui or command line) it's really useful to get an understanding of gits internal model. It informs day-to-day use and is a great example of an elega…

You can format your `git log` output to give you your network graph... Really? Awesome. How?

Stick this in your ~/.gitconfig

[alias]

  lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %C(bold white)%s%Creset %Cgreen(%cr) %C(blue)@%an%Creset' --abbrev-commit --date=relative
Then use from the cli as `git lg [branch1, branch2...]

Sourced from multiple results on google and customizations over time.

Re: Visualized Git practices for team: branch, merge, rebase

#26

Post by wanderr »

Davertron wrote: post #12
gavingmiller wrote: post #8

The OP gives his own definition for rebase: git rebasing is taking all your local changes since the last push and put them ahead of other people’s changes regardless of the date you made the commit. But fails to explain _why_ you'd want to do that. Can anyone fill in that why for me?

My understanding is that it keeps the history cleaner at the expense of being "historically correct". It's cleaner because you have fewer merge commits, but less historically correct because it makes your commits look like they happened after the commits pulled in by rebase. Personally, I use merge (with --no-ff) vs. rebase. The only time I actually use rebase is to squash a series of (unpushed!) commits on a feature…

It keeps the upstream history cleaner at the expense of being locally historically correct. In my opinion the nice thing about having everyone rebase onto upstream is that when their changes get merged into upstream, upstream's history shows an accurate linear representation of when a piece of code was accepted into upstream, which to me is far more important than having an accurate local history.

Re: Visualized Git practices for team: branch, merge, rebase

#27

Post by logophobia »

SeoxyS wrote: post #23

Can somebody explain how rebasing affects shared histories. Say I'm rebasing a feature branch that's shared via github, will rewriting the commit history prevent me from pushing? I avoid `git commit --amend` because of that, and thought that `rebase` had the same problem. So for that reason, I always use `merge`. Am I mistaken?

No, you are absolutely right. History rewriting is fine if you do it on a private branch, but on shared branches it can be problematic.

If there are updated refs on a shared branch, you need to use the --force flag when pushing, overwriting the previous refs. All the other people pulling will also need to use the --force flag to get their refs updated.

It could also lead to data loss on all the repositories that do this if something goes wrong. And it forces other team members to use the correct flag when pulling and otherwise dealing with cryptic error messages when they don't do this.

--amend is fine if you haven't pushed yet, otherwise it has the same problems as rebase for shared stuff.

Re: Visualized Git practices for team: branch, merge, rebase

#28

Post by spitfire »

Isn't it a little ambitious to call yourself a veteran $foo programmer when you've been doing it for a little over a year?

Particularly when the blog post before this is discussing how .m and .h files totally confused you. God help him if he gets asked a linked list question in an interview.

Re: Visualized Git practices for team: branch, merge, rebase

#29

Post by [deleted] »

spitfire wrote: post #28

Isn't it a little ambitious to call yourself a veteran $foo programmer when you've been doing it for a little over a year? Particularly when the blog post before this is discussing how .m and .h files totally confused you. God help him if he gets asked a linked list question in an interview.

[deleted]

Re: Visualized Git practices for team: branch, merge, rebase

#30

Post by pjscott »

dqminh wrote: post #2

Its opposite for us. At work, we dont use branch, only git pull --rebase on master. Any idea on when and why to use branches often ?

Where I work, there are several different git styles, but they all work nicely together if everyone adheres to one simple rule. I'm going to say it loudly, because it's important:

origin/master must be deployable.

If that means developing in a branch, fine. If that means accumulating several patches locally in master that you haven't pushed yet because you're not done, fine. Just make sure that origin/master can always be deployed to the servers.

Actually, come to think of it, both of those things are pretty much equivalent to using branches for anything non-trivial.

Post reply on HN