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

51–60 of 104 posts

Re: Comparing Git Workflows

#51

Post by servilio »

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!

To avoid this the team could agree on what branches rebase is OK, maybe adopting a naming scheme that will make clear what branches might pull the rug from under you (e.g.: branches namespaced with the developer's username (i.e.: drewg123/fix-for-bug)).

I personally prefer to rebase on a new branch, naming the new branches with a suffix in the form "-vN". Would something go wrong with the rebase, it will be way simpler to reset the new branch to the head of the old than to recover from the reflog. Nowdays I rely heavily autosquash, interactive add, interactive rebase and Magit (which makes the later two a breeze).

Re: Comparing Git Workflows

#52

Post by lamontcg »

edu wrote: post #8
useryMcUserface wrote: post #2

This article has actually been around for a while. Explains it really great. But one advice from me is that try to choose only what is sufficient to your project and team. No benefit in being overequipped for a simple job.

This, over complicating the git workflow will make people not using it. In my experience the feature branch works for 80% of the projects, gitflow works for bit projects and I guess (no experience there) that the forking will work for open source projects or HUGE code bases.

even reasonably large open source projects don't need anything beyond feature branches and one long-lived master branch.

and if you're going to back port to historical releases and hotfix and or patch them, its better to fork off master and then cherry-pick back, and then eventually end those branches.

Re: Comparing Git Workflows

#53

Post by unethical_ban »

teen wrote: post #41
zamalek wrote: post #30

You can also evolve, basically, to each model in the order that they appear in the article. As an example: I've been working on a new spike for the past 2 weeks with one other developer. Maybe 10 times a day we'll need something that the other person has committed, so we work against one branch (master). The workflow suits this extremely rapid iteration. One repo has now matured to the point where developer branches…

developer branches never make sense

There are many people in this conversation describing then as the Savior of comments for commits, as it not using them is a disservice to the team. I'm not much of a coder myself, but the suffering opinions are interesting.

Re: Comparing Git Workflows

#54

Post by developer2 »

mikegerwitz wrote: post #44
developer2 wrote: post #38

Earlier quoted context omitted.

The nice thing about git is that your commits can be garbage. Until you push (or, much less commonly on most teams, let someone pull from you), your local commits can be an utter disaster, and it just does not matter. From a purely technical standpoint, there is no excuse for messy logs. Any mess is the result of the user, not the software. The problem is that using rebase to clean up your local commit log before sha…

> The nice thing about git is that your commits can be garbage. That's a dangerous practice. When you first commit the changes, you have all the necessary context, and hopefully flow hasn't been interrupted. If you rebase hours, days, maybe weeks later, then that context is completely lost---it's just like trying to get back into a project that amount of time later. The reason the detail you'd put into your commits i…

I could have been more specific about the scenario I was referring to. Many people commit to git very frequently in such a way that their local git history is more like an IDE's undo log. You can commit 10+ times in the span of an hour, using the log as nothing more than a savepoint system. This is really common from people who for some unfathomable reason perform a commit before testing, which results in a lot of those one-liner commits that really do not deserve their own commit (this specific task can be done via amend, but you don't see it from most devs).

Git commits are so fantastically cheap, and especially easy if it's a one second task via keyboard shortcut in your IDE rather than terminal commands. You wind up with a lot of commits throughout the day all related to accomplishing a simple task, and then rebase them down into a smaller number of meaningful chunks of work.

I agree that this should not be the workflow for larger units of work. If you're working on a week-long task, you would use this flow to refactor each day's 50 commits down to what you would have normally committed (maybe 1-5 commits for the day). This allows your feature branch's log to contain meaningful information. At the end of the week, when your feature branch is complete, you then have the additional choice as to whether the branch's already-more-compact history is meaningful; if not, you can further squash the merge commit.

tldr:

>> When you first commit the changes, you have all the necessary context

Rebasing your local changes before sharing is for the case where you're spamming loads of meaningless commits that don't have - or deserve - their own context.

Re: Comparing Git Workflows

#55

Post by outworlder »

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…

Gerrit by itself won't fix the problem you are describing. It is still possible for a commit to pass code review and not compile at all.

Someone needs to start enforcing proper commits, and a CI system need to be setup to disallow broken commits.

Re: Comparing Git Workflows

#56

Post by heavenlyhash »

jedberg wrote: post #6
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…

A couple weeks ago GitHub added merge squash as an option for accepting pull requests (via the UI, you could always do it manually). As long as you don't delete the feature branch you'll still have the history of iterations in that branch.

> As long as you don't delete the feature branch

This, unfortunately, is not a great thing to propose.

Many of git's operations on refs are basically O(n). You really don't want to accumulate an unbounded number of them over time.

Re: Comparing Git Workflows

#57

Post by crispyambulance »

Kudos to atlassian for bringing some much needed clarity to a confusing topic. So many people that claim mastery of git only know particular workflows and, when attempting to mentor others, just mansplain whatever they know without consideration that there are alternative valid ways of doing things.

Without a firm grasp of one's intent(workflow) learning git commands is pointless and leads to people desperately flailing out commands.

Re: Comparing Git Workflows

#58

Post by herge »

icebraining wrote: post #11
herge wrote: post #7

Earlier quoted context omitted.

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.

Does git blame let you see the same thing? I don't see --first-parent as an argument to it.

It's only helpful if the 'un-expanded' commit is used through the whole system, from git blame, to rebases, etc.

Re: Comparing Git Workflows

#59

Post by jedberg »

heavenlyhash wrote: post #56
jedberg wrote: post #6

Earlier quoted context omitted.

A couple weeks ago GitHub added merge squash as an option for accepting pull requests (via the UI, you could always do it manually). As long as you don't delete the feature branch you'll still have the history of iterations in that branch.

> As long as you don't delete the feature branch This, unfortunately, is not a great thing to propose. Many of git's operations on refs are basically O(n). You really don't want to accumulate an unbounded number of them over time.

I agree with you, but I was responding to the request to keep "all the history". My understanding is the ref count would be the same if you merge in all the history or keep the branches around, so in those cases it wouldn't make a difference. I could be wrong though -- I don't know enough about git internals to know if one is worse than the other.

Re: Comparing Git Workflows

#60

Post by rimantas »

forrestthewoods wrote: post #37
MAGZine wrote: post #36

Earlier quoted context omitted.

> Because lord knows there will be a moment down the road where there's a line of code that doesn't quite make sense. This is that code reviews and code commenting are for. You shouldn't need to dig into the nitty-gritty of multiple commits of a single feature to understand a single line. Written once, read hundreds—right? > And I'll want _full_ history to understand where that line came from. See how it evolved. So…

There exists a spectrum from full keystroke history to squashed commit. Squashed commits throws away information. It is lost forever. Full keystroke contains all that information information but it is incredibly noisy. Per commit state snapshot is a pretty happy median. It doesn't tell you all the things that keystrokes could tell you. But it's very easy to use. And tells you a lot of things that squashed commits doe…

Data is not necessarily information. If three commits to fix a typoe make you happy, so be it. I don't need and I do not want this kind of history and information.
Post reply on HN