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

Comparing Git Workflows

atlassian.com

Post reply on HN
Print view View original

11–20 of 104 posts

Re: Comparing Git Workflows

#11

Post by icebraining »

herge wrote: post #7
drewg123 wrote: post #4

One of the things I hate about the traditional git workflows describe there is that there is no squashing and the history is basically unusable. We have developers where I work that use our repo as a backup, then when things are merged to master, the history is littered with utter garbage commits like the following: "commit this before I get on the plane" "whoops, make this compile" "WTF?" These add no benefit to his…

I wonder if 'expandable commits' would be useful, where in the full history, a change (with all it's code review fixes, etc) would appear as one commit, but if you wanted to dig deeper, you could 'expand' that commit into all it's gory details of 'draft version before review', 'tried refactoring this part but gave up', etc.

I think you can do that if you merge with --no-ff, then use git log --first-parent. Only the merge commit will appear on the list, hiding the commits from the merged branch.

Re: Comparing Git Workflows

#12

Post by tommyd »

herge wrote: post #7
drewg123 wrote: post #4

One of the things I hate about the traditional git workflows describe there is that there is no squashing and the history is basically unusable. We have developers where I work that use our repo as a backup, then when things are merged to master, the history is littered with utter garbage commits like the following: "commit this before I get on the plane" "whoops, make this compile" "WTF?" These add no benefit to his…

I wonder if 'expandable commits' would be useful, where in the full history, a change (with all it's code review fixes, etc) would appear as one commit, but if you wanted to dig deeper, you could 'expand' that commit into all it's gory details of 'draft version before review', 'tried refactoring this part but gave up', etc.

I thought the very same thing, as I can see the benefits to both having a single atomic commit for ease of reading history, and to being able to see the individual commits that made it up to avoid losing valuable information about changes.

It turns out that the Github "Squash and Merge" option for Pull Requests does basically this – you review the PR as a bunch separate commits, when you click "Squash and Merge" a single commit is created in the target branch with all the commits squashed, but you can still go back to the original closed and merged PR (e.g. by following a link in the commit message) to view the individual commits.

Obviously this doesn't help if you want to bisect among more granular commits, but (without having actually used it), it sounds like a good middle ground to me. The previous workflow I was used to involved squashing and force pushing to your branch, therefore overwriting the individual commits in the PR for ever.

Re: Comparing Git Workflows

#15

Post by forrestthewoods »

drewg123 wrote: post #4

One of the things I hate about the traditional git workflows describe there is that there is no squashing and the history is basically unusable. We have developers where I work that use our repo as a backup, then when things are merged to master, the history is littered with utter garbage commits like the following: "commit this before I get on the plane" "whoops, make this compile" "WTF?" These add no benefit to his…

Gross.

In a private environment squashing history is the precise opposite of what I want. I want immutable history. Anything anyone every checks in is there forever. Safe and secure. Impossible to lose. Impossible to screw up.

Furthermore, I want all the changes they made along the way to their feature. Because lord knows there will be a moment down the road where there's a line of code that doesn't quite make sense. And I'll want _full_ history to understand where that line came from. See how it evolved.

Git still doesn't have anything as good as p4 timelapse view. Which is deeply unfortunate. That's a great tool for spelunking the past.

Re: Comparing Git Workflows

#16

Post by drewg123 »

raju wrote: post #10
drewg123 wrote: post #4

One of the things I hate about the traditional git workflows describe there is that there is no squashing and the history is basically unusable. We have developers where I work that use our repo as a backup, then when things are merged to master, the history is littered with utter garbage commits like the following: "commit this before I get on the plane" "whoops, make this compile" "WTF?" These add no benefit to his…

Do you use feature branches, or does everyone work off `master` ? (From your comment it seems like you do) If you use feature branches, then it might help to - rebase interactively to clean up/edit/remove commits that are not relevant before merging - merge into master with the `--no-ff` flag - this forces Git to create _one_ merge commit, even if it is a fast-forward merge FWIW the two above can be used individually…

We use feature branches, using atlassian stash rather than github.

I'm confused though -- I thought that if you rebased & squashed something after you pushed it, then it would confuse the git clients of anybody who had pulled before the squash?

Thanks so much for all the suggestions!

Re: Comparing Git Workflows

#17

Post by fphilipe »

raju wrote: post #10
drewg123 wrote: post #4

One of the things I hate about the traditional git workflows describe there is that there is no squashing and the history is basically unusable. We have developers where I work that use our repo as a backup, then when things are merged to master, the history is littered with utter garbage commits like the following: "commit this before I get on the plane" "whoops, make this compile" "WTF?" These add no benefit to his…

Do you use feature branches, or does everyone work off `master` ? (From your comment it seems like you do) If you use feature branches, then it might help to - rebase interactively to clean up/edit/remove commits that are not relevant before merging - merge into master with the `--no-ff` flag - this forces Git to create _one_ merge commit, even if it is a fast-forward merge FWIW the two above can be used individually…

Re --no-ff, you can flip the behavior so that you need --ff when you really want to fast forward by adding this config:

    [merge]
      ff = no

Re: Comparing Git Workflows

#18

Post by zzleeper »

drewg123 wrote: post #4

One of the things I hate about the traditional git workflows describe there is that there is no squashing and the history is basically unusable. We have developers where I work that use our repo as a backup, then when things are merged to master, the history is littered with utter garbage commits like the following: "commit this before I get on the plane" "whoops, make this compile" "WTF?" These add no benefit to his…

I am guilty of that. But what can I do? I use dropbox as a sort of backup (in case of a lost laptop or HDD failure), which doesn't work with git. When pushing to personal & private projects that's fine, but I need a better backup soln when pushing to a public repo..

Re: Comparing Git Workflows

#19

Post by icebraining »

zzleeper wrote: post #18
drewg123 wrote: post #4

One of the things I hate about the traditional git workflows describe there is that there is no squashing and the history is basically unusable. We have developers where I work that use our repo as a backup, then when things are merged to master, the history is littered with utter garbage commits like the following: "commit this before I get on the plane" "whoops, make this compile" "WTF?" These add no benefit to his…

I am guilty of that. But what can I do? I use dropbox as a sort of backup (in case of a lost laptop or HDD failure), which doesn't work with git. When pushing to personal & private projects that's fine, but I need a better backup soln when pushing to a public repo..

You can squash commits locally before pushing. I'm not a fan of "one commit per feature", but I still use interactive rebase on my personal branch to combine (or split) commits before merging it with an upstream branch.

To avoid cluttering the main repo but still have a backup, you can just use a fork (even just a directory on a remote server).

Re: Comparing Git Workflows

#20

Post by ep103 »

drewg123 wrote: post #16
raju wrote: post #10

Earlier quoted context omitted.

Do you use feature branches, or does everyone work off `master` ? (From your comment it seems like you do) If you use feature branches, then it might help to - rebase interactively to clean up/edit/remove commits that are not relevant before merging - merge into master with the `--no-ff` flag - this forces Git to create _one_ merge commit, even if it is a fast-forward merge FWIW the two above can be used individually…

We use feature branches, using atlassian stash rather than github. I'm confused though -- I thought that if you rebased & squashed something after you pushed it, then it would confuse the git clients of anybody who had pulled before the squash? Thanks so much for all the suggestions!

It does confuse anyone who has pulled before the squash, but if you're working on feature branches, then there shouldn't be anyone else who's working on the branch. If the feature is too large for one person, let's say you have 5 people working on a feature branch; then each one of those 5 people should be branched off the feature branch, for the same reason.
Post reply on HN