What was the workflow in mind when Git was designed?
Comparing Git Workflows
71–80 of 104 posts
Re: Comparing Git Workflows
#72It amazes me how the entire software industry seems to be adapting its workflows around the necessity of making Git usable. While there are certainly other positive attributes about some of these workflows, the main reason people use them in my experience is because "if you don't use workflow X you get undesirable problem Y with Git". Most of these problems simply didn't exist or were not nearly as severe with previo…
> these problems simply didn't exist or were not nearly as severe with previous revision control systems
I (have to) use one of these systems you speak of without the horrors of having to worry about merge histories or organizing any branches whatsoever.
I have to worry that someone in California broke some code, somewhere right before lunch and it'll take me as long to workaround as it will to just take a second lunch.
I have to worry that if I miss a release because of QA issues I need to spend a bunch of time reversing all my changes temporarily and then redoing them in a new release and hoping nothing got borked in between.
I have to worry about how to show someone out of the office what my changes look like because they're still too janky to push into the release branch.
If I'm working from home and Comcast decides I'm due for my weekly outage then I'm SOL.
I have to worry about a failed commit going and locking files on other people because apparently I'm the only person ever to run a command that fails (granted, PEBCAK), so let's not worry about making that failure impact a centralized shared state in a negative way.
You can spend a lot of time thinking about the best way to do something in git because it lets you do a lot. The choice is essentially "Elaborate workflows" vs "bridge the inadequacies of the tooling by brittle ritualized human processes".
Git problems are VCS' first-world problems.
Re: Comparing Git Workflows
#73Earlier quoted context omitted.
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.
I have used git blame with --first-parent to get the 'un-expanded' commit identifier in the blame view.
I'm rather new to the --first-parent flag myself but I think it works with anything that supports revision options.
Here's what I see in git 2.8.1:
usage: git blame [] [] [] [--]
are documented in git-rev-list(1)
Re: Comparing Git Workflows
#74One 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..
If you're working on branch `myFeature`, simply branch to `myFeature_BACKUP` and commit your entire working copy with commit message "WIP for the night; for remote backup only". Push this to the remote to back it up and protect against a lost laptop.
The next day, do a "reset --mixed" from the tip of your backup branch back to your last good commit on the feature branch. This brings all of the remote backup code into your working copy. From there, start work again and begin making staged commits of atomic changes.
Re: Comparing Git Workflows
#75Earlier 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…
Doesn't an undeleted feature branch essentially offer the same functionality as "expand squash?"
Re: Comparing Git Workflows
#76Earlier quoted context omitted.
> 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 th…
I see; this is a very different workflow than I am describing (or am used to). While I understand it's useful as a snapshot, that's not a useful use of history in Git. In fact, it's quite useless, and I'd agree that those commits should not remain, and should be replaced with something useful.
But since context has been lost, that "useful" commit might just be a single, squashed one; I've observed this situation at work from others.
So, this is a situation where those users are digging their own hole.
Re: Comparing Git Workflows
#77Earlier 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 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 si…
Now your history is in two places and can't be inspected from a cli. If you ever stop paying github (for a private repo) or github goes out of business your data is lost.
Or you can use git to track this with merge commits and it comes along wherever you go.
Re: Comparing Git Workflows
#78One 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…
Git reflow does this (and more). If you want to do presubmit code reviews, and squash merge to master to preserve history. You might like it.
https://github.com/reenhanced/gitreflow
Re: Comparing Git Workflows
#79Earlier 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!
We also use Stash and just enforce that PR descriptions should be the "clean" version of your combined commit messages. This way you:
a) Never change pushed history
b) Have the Pull Request act as a single source of what changed in each feature branch. Since Stash also includes comments from code review, we find it offers more context than straight commit history
c) Don't have to worry about team commit-early-commit-often vs. team commit-only-when-it-works-perfectly. The changes will all be centrally documented in the PR, no matter the individual styles
Re: Comparing Git Workflows
#80One 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…
> the history is littered with utter garbage commits like the following: "commit this before I get on the plane" "whoops, make this compile" "WTF?" You have a problem with commits here, not the lack of squashing. A messy history is only messy if you make it so. > These add no benefit to history, and actually provide an impediment to bisecting (since a lot of these intermediate revisions will not even compile). This i…
It'd pe perfect, if only we could take people out of the equation.
Seriously, I think that the cost/benefit ratio of a perfect history is so terrible that there are very very few people that follow through with it.
If one submits a PR and it has a messy history, what is the reviewer supposed to do? Make them go through the commits and clean them up? How will the reviewer verify that every commit compiles? Make them squash it? We are back to square one. If you only have squash commits from PRs and run CI on them, you are sure that every commit compiles.