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

81–90 of 104 posts

Re: Comparing Git Workflows

#81

Post by sofal »

turaw wrote: post #50
sampo wrote: post #45

Earlier quoted context omitted.

> history is basically unusable. I can see how, in the second workflow (feature branch workflow), this can become a problem. If the history looks like this --------- / \ --A E-- \ / B---C---D then we can sort of guess that commit B started a feature branch and E is the merge commit that merged the feature back to master. And commits B, C and D can be "unusable" intermediate work, maybe even uncompilable. But if nobod…

> ...this is solved by the named branches in Mercurial... I'm not super-familiar with Mercurial (and only somewhat-familiar with git), but couldn't you get the same effect as named branches by just not deleting fully merged branches in git? > ... how can you tell which one of the parents is the previous commit in the master ... You can use --first-parent [1] to disambiguate that. In a nutshell, the master branch in y…

The --first-parent history can be ruined pretty easily by an inexperienced Git user. They'll use their local master as their feature branch for days and then they'll try to push it. Git will unhelpfully tell them to first do a "git pull" before pushing. So they do, which leaves them with a bullshit "merged master into master" merge commit and then they push that shit, thereby guaranteeing that --first-history will always omit the actual history of where origin/master was and instead take a trip through this dude's little feature adventure.

Re: Comparing Git Workflows

#82

Post by nhaehnle »

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 find it mildly amusing what you're calling "traditional git workflows".

It seems pretty clear to me that the traditional git workflow is the one used by the Linux kernel, which is after all the reason why git exists in the first place. The traditional git workflow strikes the correct balance between locally rebasing to create a logical sequence of meaningful commits without squashing everything when your work gets published and merged.

A lot of the noise on the git-related threads here on HN would probably be avoided or at least reduced if everybody was actually aware how the traditional git workflow f- i.e. the Linux kernel workflow - works.

Re: Comparing Git Workflows

#83

Post by cyphar »

nhaehnle wrote: post #82
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 find it mildly amusing what you're calling "traditional git workflows". It seems pretty clear to me that the traditional git workflow is the one used by the Linux kernel, which is after all the reason why git exists in the first place. The traditional git workflow strikes the correct balance between locally rebasing to create a logical sequence of meaningful commits without squashing everything when your work gets…

I completely agree. The Linux kernel workflow is the only way to use git effectively and the history is always useful and each commit is nice and self-contained. Some people apparently don't understand that "no squashing of patchsets" means that the merger shouldn't squash a patchset (not that the developer can't make the patchset clean) and that "no rewriting history" refers to master once things have been merged into it.

Re: Comparing Git Workflows

#84

Post by lmm »

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…

Commit messages are very rarely read. I'd say it's well worth committing anything that compiles (that can only help bisection, which is a much more important use for history than human readability). Even a non-compiling commit isn't really a hindrance - if it doesn't compile mark it as unknown (you're using an automated bisect script that does that, right?), and you end up with the same result as if that commit hadn't been made.

Re: Comparing Git Workflows

#85

Post by nwatson »

The article completely mischaracterizes Subversion workflows, making the mistake of treating a Subversion repo just like developers typically use git repos ... one-repo-per-project.

Subversion instead is a tree with projects as nodes toward the leaves, each project with its own trunk, branch, tags. It's each of these projects that corresponds to a git repo. Teams I worked on always treated each project as its own "repo" ... so the central single Subversion tree became like our 'github' or 'bitbucket' ... and one could do all the lockless branching within each project, no problem. YOU COULD BE AS NON-LINEAR IN THIS APPROACH AS YOU NEED TO BE, with full support for branching, tagging, merging, etc.

Where Subversion was much better was in supporting consolidated views of multi-project build / release environments, or in mixing sub-project code in parent-project code. Using svn:external it was each to put "that subproject in this place in my own project". Using git submodules and other approaches is a pain. You end up having to check out a bunch of git repos and managing your own glue.

Re: Comparing Git Workflows

#86

Post by EnderMB »

It'd be nice to see someone collate more git workflows, and what the advantages and disadvantages of these are.

Over time, my workflow has become simpler and simpler. I've worked with some weird and wacky workflows before, which have been born from a given requirement, such as quick deployment to a number of different environments, or two separate teams working on separate parts of one codebase while maintaining separate CI workflows. Some of these workflows have seemed absolutely mental, but I've seen them several times over in different places, so there must be some kind of logic to the madness.

Different dev teams have wildly different practices, so it'd be good to acknowledge the "typical" way of doing things, and embracing the workflows that work if you need to do something out of the ordinary.

Re: Comparing Git Workflows

#87

Post by qb45 »

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

Tell those guys ;)

https://git.kernel.org/cgit/

Re: Comparing Git Workflows

#88

Post by justincc »

lmm wrote: post #84
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…

Commit messages are very rarely read. I'd say it's well worth committing anything that compiles (that can only help bisection, which is a much more important use for history than human readability). Even a non-compiling commit isn't really a hindrance - if it doesn't compile mark it as unknown (you're using an automated bisect script that does that, right?), and you end up with the same result as if that commit hadn'…

I am always reading commit messages to find out why such -and-such a thing changed. I agree that making frequent commits is really great but I always want to see every commit have a meaningful message, either at the time it is made or in cleanup before pushing to the remote branch.

Re: Comparing Git Workflows

#90

Post by adamc »

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…

For those of us working in domains where auditors might care what has happened, there's a constraint: Auditors want the commit history to reflect what really happened, not the sanitized version of same. One of the nice things about git is that you can have a fork with a clean commit history and an "official" repo that reflects the real history of its merges.
Post reply on HN