Visualized Git practices for team: branch, merge, rebase

http://kentnguyen.com/development/visualized-git-practices-for-team/

by kentnguyen • 14 years ago

86 36 14 years ago

dqminh2• 14 years ago

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 ?

fhwang3• 14 years ago

Branching can often be a good strategy if you have a large team and you don't want large uncompleted chunks of work to block quick fixes & deploys, etc. The situation you want to avoid is:

1. Engineers A & B are working on a medium-sized story that's not really done yet, but is in master anyway 2. Somebody discovers a small but critical bug in production 3. Engineer C can write a bugfix very soon, but can't deploy it to production because the other story isn't done yet.

But if your team never ends up saying "I'd deploy that but master isn't clean right now due to different changes", you probably just don't need to branch that much. Maybe your team is smallish or maybe you're capable of always breaking up work into really small increments. It really depends on everybody's situation.

Github does something sort of like this internally: http://scottchacon.com/2011/08/31/github-flow.html

Branching is more overhead in some circumstances but I've also found they can make things much easier. But I also wish that more people were comparing strategies and trade-offs because this stuff gets subtle and there are really lots of ways to do it.

dqminh2• 14 years ago

We faced this situation before. What we do is: - When there is a feature that is not done yet, but has some user-facing code, we use feature toggler to disable it on production - we deploy quick fix by doing a cherry-pick

We discussed about branching a while ago to solve this problem more effectively but still not satisfied with the pros vs cons. For us, branching only makes sense if we switch to use branching completely, and thats quite a big change.

molecule2• 14 years ago

We have been very happy with the git branching workflow described and justified here: http://nvie.com/posts/a-successful-git-branching-model/

generalk• 14 years ago

A local git branch is super-cheap, so there's hardly any downside to using them. The upside, even for a single developer, is the ability to work on multiple features/bugfixes simultaneously, and merge them into master only when they're ready.

pjscott• 14 years ago

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.

gavingmiller• 14 years ago

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?

alinajaf3• 14 years ago

master on your local repo is a different reference to master at origin and master at other developers machines. By merging your master into origin/master instead of rebasing, you leave the history looking like multiple branches were merged together.

By rebasing onto origin/master instead of merging, you leave the history looking linear.

Ultimately it's about aesthetics, you don't gain anything by rebasing (when pulling) other than a cleaner history.

dennyabraham• 14 years ago

I'm not certain this is due to the particulars of the workflow of the team I was working with, but one of the benefits I saw of rebasing over regular merging was that rebasing let us resolve conflicts at the point of the commit in which they emerged, rather than in a merge commit at the end.

Davertron2• 14 years ago

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 branch, and I usually only do that if I went hog-wild, committing more than necessary while experimenting.

wanderr• 14 years ago

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.

jabo• 14 years ago

When I'm working on a branch and I want to pull changes from master into my branch so that I'm working on the latest code base I do

> git rebase master

What this does is that it temporarily reverts all my changes on this branch, applies all the changes from master on my branch and then reapplies my changes on this branch.

lnguyen3• 14 years ago

Something I wrote up nearly three years ago that should explain rebase vs merge

http://gitguru.com/2009/02/03/rebase-v-merge-in-git/

I really should go back and start making new blog posts... I'd dropped the ball because I ended up on a few enterprise SCM (software configuration management) gigs shortly after.

martco• 14 years ago

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. Also, Tower shows a tree graph, similar to the network diagram the author "seriously cannot live without."

Why knock visual tools when when you rely on them so much?

alinajaf3• 14 years ago

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 elegant, well-designed system.

palish• 14 years ago

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

Really? Awesome. How?

andrewingram• 14 years ago

I used git at the command line for two years before trying (and later buying) Tower.

I am a very visual person. It gives me greater confidence in what I'm doing when I can see a polished visual overview, it makes me more willing to use powerful features like picking individual lines to commit, to avoid any single commit containing a mixture of use cases.

But I always make sure I know what the GUI is doing on the command line before trusting it to be doing the right thing. I made sure I understood rebasing correctly before setting it to be the default pull behaviour in Tower. Similarly, I never feel comfortable using a one-line deployment script before running through a deployment by hand first.

Any tool that makes our lives easier and less likely to make silly screwups is a good thing in my eyes. It doesn't matter whether that tool is a GUI or a script. I prefer using a GUI for databases too, because the command line is woefully inadequate at letting me grasp the shape of data quickly.

hack_edu• 14 years ago

I love git. It helps me to wake up in the morning some days. But...

The OP's attempt to visualize git concepts falls quite short. This same old branching graph does little to nothing to illustrate these concepts. I cannot tell you how many friends and colleagues threw up their hands when someone tries to graph it out these way.

igorgue• 14 years ago

I think the best thing I did for my team is explain them how branches work, and how not-so-special are they, branches are just pointers to a commit, and commits are never 'lost'.

People need to understand how simple Git is.

SeoxyS• 14 years ago

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?

logophobia• 14 years ago

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.

spitfire• 14 years ago

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.

nazri1• 14 years ago

The merge-often strategy that the OP recommend in his post is the one that is Linus abhors so much. He even calls it "unholy mess" : https://lkml.org/lkml/2012/1/10/267. Basically that merge strategy can produce pointless merges.

See this discussion: http://git.661346.n2.nabble.com/Re-Regulator-updates-for-3-3... on the git developer mailing list for more details on why that merging strategy is not liked.

lnguyen3• 14 years ago

The strategy isn't the issue. It's whether it fits with the process you've set up.

If you do code-review on the contributions/pull requests then I can see where the merge-often strategy causes issues. The auto-generated merge commits don't give you the context of the updates that are pulled in and will lead to having to spend time going back through the commit tree. It may not lead to the introduction of issues or regressions but you can't be sure.

However, if you're set up as a small team with good internal communication or a high level of trust, then merge-often can be a good thing in that you usually aren't left with big merge issues to deal with and you're more likely to have any conflicting updates fresh in your mind.

lucisferre3• 14 years ago

We solve the problem with rebasing. If it's not part of the main branch then it's not part of history, so rebasing to organize the pull request makes sense.

lucisferre3• 14 years ago

His opinions on not rebasing onto master and instead merging are his own. Personally I find merging far more confusing in terms of understanding history graphs and always rebase before issuing a pull request. I think you will find that generally a lot of open source projects on Github have this practice of asking people to "please rebase your changes onto master so I can merge".

One practical reason is when doing bisects.

There are certainly two schools of thought on this, but "this is confusing to me so don't do it" shouldn't be considered a valid opinion.

Visualized Git practices for team: branch, merge, rebase

Related Stories