Git Workflow Basics • Hacker News Board

Re: Git Workflow Basics

#11

Post by shadowfiend » Wed, Aug 17, 2016, 2:20 PM UTC

> How easy is it to accidentally remove a line during interactive rebase and lose all work associated with it?

This is not only not easy, it's actually very difficult. If you drop something in an interactive rebase, you can reset your HEAD to the HEAD commit from before your rebase. It's a bit arcane, and has its own dangers, but it's also important to be clear that rebases are not destructive unless a git gc runs between your rebase and realizing you made a mistake. It's also the equivalent fix to checking out intermediate commits for a squash merge, as far as I know.

Don't get me wrong, I don't think rebase should be the first tool you reach for and I don't particularly like “rebase everything to master” workflows. But it's not as dangerous as you're making it sound, IMO.

Re: Git Workflow Basics

#12

Post by snuxoll » Wed, Aug 17, 2016, 2:25 PM UTC

I'm so happy this uses squash merges, using rebase for this purpose is exceptionally overkill when you just want a clean commit history (due to the complexity of using the rebase tool), if you're writing a feature that involves a large amount of changes throughout the codebase it can be a handy tool to break up your work but for the general case of smaller PR's a squash merge is the way to go.

Re: Git Workflow Basics

#13

Post by jordigh » Wed, Aug 17, 2016, 2:28 PM UTC

> This workflow is scary. A rebase should not be part of any everyday workflow and must be reserved _only_ for exceptional situations.

This is what Mercurial Evolve tries to solve. There's nothing wrong with rewriting draft commits. The only potential problem is rewriting public commits. Mercurial uses phases to distinguish drafts from published commits and you may optionally designate certain repositories as non-publishing, so that they can be used for collaboratively editing draft commits.

A similar de facto convention on git is to only rewrite certain branches (e.g. feature branches) but never rewrite others (e.g. master). Commits that are local-only can be rewritten at will. Mercurial just codifies this convention via phases.

Re: Git Workflow Basics

#14

Post by Ridikule » Wed, Aug 17, 2016, 2:33 PM UTC

Typically, I see folks create a working branch, make incremental commits, such as a commit per day so as not to lose work, then rebase them all into a single commit before pushing back to origin. We haven't had any problems with this approach so far. YMMV

Re: Git Workflow Basics

#15

Post by K0nserv » Wed, Aug 17, 2016, 2:35 PM UTC

I don't share this concern, I've been rebasing frequently(several times a day) for years now and never caused any unrecoverable problems. I would recommend that the last thing you do before pushing a branch you've rebased is

git diff origin/master branch

This way you can see if the diff looks like what you expect it to be. If it doesn't and you believe you messed something up while rebasing just

git reset --hard origin/branch

and redo the rebase

Re: Git Workflow Basics

#16

Post by fredoliveira » Wed, Aug 17, 2016, 2:43 PM UTC

Your suggestion feels a little misguided. You end your post by saying that you contest the a priori idea of branching, but seem to forget everything that is right about branching in the first place:

* Want to see the history for a specific feature? Impossible in your proposal, native in a feature/topic branching model.

* Want to do a code review on a specific feature? Again, impossible in your proposal, trivial in a feature/topic branching model.

* Want multiple developers to work under the same codebase with minimal conflict resolution and clear separation of tasks? Very hard under your proposal, easy in a feature/topic branching model.

You also say that using topic branching means not doing CI. I've used the idea of proper feature branching for years, and have never _not_ had a CI process. CI tools are most definitely ready for (and are quite welcoming of) workflows like git-flow. I'd be happy to speak at more length about how we implement it if you'd like, but I assure you it is all but complicated.

Re: Git Workflow Basics

#17

Post by steveklabnik » Wed, Aug 17, 2016, 2:46 PM UTC

  > A squash merge is a rebase.

Well, it's not a rebase in the literal sense: the base commit isn't changing. It _is_ modifying history, though.

Re: Git Workflow Basics

#18

Post by stormbrew » Wed, Aug 17, 2016, 2:53 PM UTC

It probably is in the same sense that 'git rebase -i' often puts the new branch on a new base even if that wasn't your explicit intention. Usually merge squashes are reparented to the current head of the target branch.

But my point was just that a merge squash is just a specific incantation of the git-rebase tool. And it is one of the most history destroying incantations, rather than the least.

Re: Git Workflow Basics

#19

Post by DougWebb » Wed, Aug 17, 2016, 2:54 PM UTC

Rebase is absolutely a part of my everyday workflow, and the rest of my team's workflow as well. (Yesterday I had to show our CTO how to use it, because the rest of the team was getting annoyed by his merge commits.)

Our workflow is:

- locally, commit to local master or a local branch

- occasionally checkout local master (if necessary) and pull using the 'rebase after fetch' option.

- if we had local master commits, fixup any conflicts in our code

- if we were working on a local branch, checkout that branch and rebase it on the new master, fixing any conflicts that arise

- If our work is complete, possibly do a final rebase to reorder and squash local commits, and fast-forward merge to master if we were on a branch. Finally, push the local master to share our work.

Note that we never rebase anything that's been pushed. Also, if we're worried that a rebase is potentially complex and error prone, we create a new branch at the existing HEAD so that the old commits don't get lost in the reflog. Once the rebase is done, we can delete that branch so the old commits can be garbage collected.

Re: Git Workflow Basics

#20

Post by SonicSoul » Wed, Aug 17, 2016, 3:00 PM UTC

we've adopted it daily to solve the issue with bad merge history. Seems that git will do a merge on the server and is confused on who did what. Care to elaborate on how you solved this problem w/out rebase?