Hacker News Reader

Comment by trevor-e | Hacker News Reader

Maybe my workflow is a lot easier than others, but I work on a team of 10+ engineers and my Git usage is dead simple. I do everything from a GUI (Fork for macOS) and very rarely have to deal with any complicated issues that require a terminal.

- Always pull w/ rebase for the current branch.

- Always merge other branches into your current branch, eg master -> feature.

- Always stage individual chunks of code one at a time to make sure I'm committing the right stuff.

- Always squash feature branches into a single commit when merging back.

- Stash changes if needed when switching branches.

- Cherry-pick one-off commits if needed.

- Append a previous commit that I haven't pushed yet if I happened to forget something.

- For complicated merge conflicts I switch to Visual Studio Code which also has a great GUI.

I think this covers 99% of the stuff I encounter in my day-to-day.

View on HN

I agree with basically everything you wrote except I’ve had much better experience rebasing my feature onto origin/master instead of merging master into feature. Keeps the [branch] history cleaner.

I hate merges. "Merged ... into ..." is such an uninformative message! Some codebases are filled with those. I prefer seeing each individual commit messages, so... rebasing all the way for me! One problem I have with this is that the committer date of all commits become identical instead of retaining their original date aligned with the author date (which I would like to be the committer date). Is there a way to workaround this or fix it in a "non-dirty" way? It might be the case that I am doing something wrong, if so, what am I doing wrong exactly, or how should I go about it?

Merge flows are vital for understanding the history after the fact. It should be trivial to make a view that just hides merge commits, if you're so allergic to them, but you can't recover them once they're gone.

For the sake of your future sanity (and your coworkers'), please stop trying to rewrite history for the sake of aesthetics. The defaults are what they are for a reason.

It is not for the sake of aesthetics though. When I do, say, git pull remote-foo master, then it opens up my text editor with the default "Merge branch 'master' of git://.../foo into bar" commit message. How is this useful or informative? There are lots of repositories with this uninformative commit message. Yes, perhaps rebase is not the best way to go about it, but then could it just be a limitation of git? Or am I missing something? I am not sure. I am looking forward for https://pijul.org/ though, it seems to solve this issue.

Additionally, if I do the aforementioned git pull, I have no way of turning the commit message into an informative one because I have no information regarding the commits. Is there a way to actually know it beforehand to turn that message into a meaningful one? If so, how would you do it? If it is possible, should I just have a list of all the commits' message in that one merge commit? Regardless, I see lots of "Merge branch ... of ... into ..." commit messages and they are not useful to me at all. Why do you think people keep doing it?

It's much more informative than not having any information about where or whether a merge happened at all, regardless of what the message is.

> Additionally, if I do the aforementioned git pull, I have no way of turning the commit message into an informative one because I have no information regarding the commits. Is there a way to actually know it beforehand to turn that message into a meaningful one?

If there are any conflicts then it will force you to stop and resolve them, which seems like a decent point to document anything that needs to be. Otherwise, you can always amend in a more relevant message afterwards.

> If there are any conflicts then it will force you to stop and resolve them

Rebasing does this too. Can't we compromise, and agree to never allow "git pull" to spontaneously and unthinkingly create a merge commit with two parents?

Instead, let's do merges of our rebased feature branches, into the trunks that they are based on, but with "no-ff" – this retains the information you wanted about what feature branches have merged into what trunks, and when. But the history of each branch maintains linearity and no commit ever has more than one parent.

I don't have to work with either of you, but this is how we resolved this debate on my team, and we haven't looked back. It's not even worth having this conversation unless you need branches to be long-lived. But if someone else ever has to rebase your branch with merges in it, they'll thank you if you have honored this, and curse you under their breath if you have left these thoughtless merge commits around.

Do merge, but please only merge deliberately. (I also recommend checking out Deliberate Git for a great talk on Git, with similar ideas! https://vimeo.com/72762735)

> Rebasing does this too. Can't we compromise, and agree to never allow "git pull" to spontaneously and unthinkingly create a merge commit with two parents?

No. Shorter-lived branches naturally bring a smaller window to create nonsense history, but the risk is still there, and the benefits are as absent as ever.

> But if someone else ever has to rebase your branch with merges in it, they'll thank you if you have honored this, and curse you under their breath if you have left these thoughtless merge commits around.

So.. don't? That seems like a good thing, software should discourage you from shooting yourself in the foot.

Making a commit with two parents is shooting yourself in the foot, because every other kind of commit can be summarized as a single diff, which means you can definitely do bisect without misery.

What is the simple diff content of a merge commit which solves a conflict between two parents? There isn't one, change my mind.

We both agree that software should discourage shooting yourself in the foot. We disagree about which one of us is using the feature that encapsulates the moment where shooting ourself in the foot happens. It's not nonsense history if it reflects the order that branches were actually merged, which is far more interesting than the order in which commits were written concurrently across disparate branches IMHO.

If you are working with other people that can't read your thoughts, especially those who are too distant to reach you to return the favor when you have inflicted pain on them, they will appreciate it if you rebase your feature branch before submitting your PR and don't send forward an unmerged conflict unless we actually need to talk it over for some reason.

On the other hand I don't know anyone who will be mad that you did this. The rebase feature exists for a reason, and so does amend, reset, squash, etc. How many of these features do you think I shouldn't use? I am only discouraging the use of one feature, the automatic octopus merge that happens when you thoughtlessly run "git pull".

Why do thoughtless things? Don't you want to review the code you've pulled?

Rebasing also guarantees that the commit your CI has tested is identical to the commit that becomes head after the branches merge. How do you guarantee that your branches still function properly after merges? Carefully running the tests by hand between merge and push? My test suite is too large, and we are too busy for that, friend.

I think the fundamental disagreement here is about whether commits represent diffs/patches or snapshots of the entire file tree.

If you care about patches then the structure or order of the history doesn't really matter as long as the dependencies of each patch are satisfied (they produce the same final file when applied, and no conflicts). Take this philosophy to its extreme, and you end up with Darcs or Pijul.

If you care about tree snapshots then each commit is a promise that "I have made these changes, and afterwards the entire combined codebase still works and makes sense". If you alter the untouched code then this still breaks the promise, because "the entire combined codebase" is now different. Take this philosophy further and you end up closer to Mercurial.

Personally I lean hard towards the latter. Code tends to make a lot of assumptions about its surroundings that won't show up in a naive text-based diff (and thus won't generate conflicts), such as "class X exists and contains method Y".

The confusing thing about git is that it doesn't really make a clear choice. Some commands only make sense in a diff-based world (such as rebase and friends), while some only make sense if you think in snapshots (such as bisect, which tests whether your app satisfies some expectation at a given snapshot, not whether your diff does what it claims to).

And besides..

> Rebasing also guarantees that the commit your CI has tested is identical to the commit that becomes head after the branches merge. How do you guarantee that your branches still function properly after merges? Carefully running the tests by hand between merge and push? My test suite is too large, and we are too busy for that, friend.

If you care about bisecting then a rebase requires you to retest each commit in the branch, while a merge only creates one new commit to test. As a wise person once said:

> My test suite is too large, and we are too busy for that, friend.

> If you care about tree snapshots then each commit is a promise that "I have made these changes, and afterwards the entire combined codebase still works and makes sense"

This is an unreasonably high bar to reach for each commit. This is the right test to apply (among others) for whether a PR has the right stuff to get merged into a trunk, or not.

> What is the simple diff content of a merge commit which solves a conflict between two parents? There isn't one, change my mind.

Treat it as a squash where the individual commits can be recovered. Git treats commits as left-biased, so the branch you're merging into will be the primary parent.

I have to treat it as history now, because it's in my trunk. If it turns out to represent a test failure, then I don't want it in my trunk, but it's too late. Even though we waited for CI and only merged when the suite was green, we wound up with a failure in the trunk, because of the surprise merge conflict that got resolved after testing had already been performed. Neither parent head can be tested by itself to prove that the merge will pass all the tests. So unless you're pushing that feature branch up with the merge in it preemptively, before it merges back, then I don't know how your approach can fulfill this requirement. (If you do, then you'll wind up with twice as many merges, many of them with the shape of an octopus or multi-parent. IMHO this greatly hinders traceability and readability in the commit history, absolutely by enough to want to edit it out. Nobody is going to read that.)

I'm coming at this from my angle as a team lead, or mediator between novice contributors who are both pointing the finger at each other. If the two parent branches both passed, but the merge fails, and both upstream committers are gone, I no longer can have only one throat to choke. I have to check out both branches and confer with both contributors in order to resolve the conflict again.

One contributor or the other has broke the build. It will require additional investigation to decide which. If one branch has merged first, and the other second after rebase, then I never have this problem, and my debugging process has only one throat to choke. Delegation becomes much easier.

Whoever won the race to get their PR approved and merged first is not the one at fault. (This is the greatest incentive to get your stuff tested and merged, also!) The branch that has been rebased on the other one, then, must be at fault, because his merge came later. It's not a value judgement on a person, I am just keeping it simple. My one and only motivation for operating this way is to have 100% certainty that contributors' PRs which (we) have decided to merge after reviewing the test outcomes, are the same, so that all the intensive testing we performed and spent our time reviewing before the merges will not have been a waste.

I generally don't want merges in my feature branches, and I don't think you will convince me to want otherwise. But I appreciate you having engaged me in this debate. Every time I get to talk about my strongly held beliefs, I get a better perspective on why someone else might disagree. :+1:

My teams have usually been very small, and I can't say for sure that my strategy can scale. But we have scaled it successfully past 2 and into 4 developers. It requires everyone's cooperation, but once we have it this delegation subjectively seems about a thousand percent more reliable.

Rebasing and keeping commits makes very easy to read history, everything is in a logical order. The order may not be the exact chronological order in which is was written but that is rarely needded, the rebases guarantee that it _could_ have been written as the history shows and you can see all changes afterwards.

I have used this in projects and it worked great for the whole team for a long time. You can of course do something else which can work for you and your team.

If you're using rebase there's the `--committer-date-is-author-date` and `--ignore-date` flags. One uses the author date for both and the other uses the commit date for both.

Without using either flag rebase should update the commit date and preserve the author date.

If by rebase you meant GitHub's rebase merge option I think you're out of luck :-/

They might be just what I am looking for! I will check them out soon. Thank you! :)

One trouble we're having with rebase is that it loses our PGP signatures, so the commits don't look Verified anymore.

Hmm, it does? I was not aware of this. I did it twice (with two independent projects) earlier and it seemed to have retained the signature for some reason. It shows "Signature made ..." and "Good signature from ..." for all the commits I made earlier. I will pay more attention to it because those signatures matter a lot to me. Thank you for pointing it out, I will keep this in mind and make sure to double check.

I think what I said should be equivalent to what you do. When I merge my feature back to origin/master I do `git merge --squash myFeatureBranch` which automatically rebases everything and keeps a clean history.

This is really the only command I do by hand because I can't find the equivalent (yet, probably haven't looked hard enough) in Fork.

edit: oh I think I misread what you said. When working on a feature branch I don't care too much about the branch history since I know it's eventually being squashed back into a single commit.

Isn't this (or at least the end state) the same as rebasing myFeatureBranch from master before merging it in? I don't use Fork, but I assume it can do those 2 things with clicks.

Same thing here. If I'm working on a feature that I haven't pushed up yet I might squash my commits together for a cleaner history (it also helps with rebasing). If you ever mess up a rebase and finish it before you're able to abort you can use `git reflog` to get a reference back to the previous commit. It's come super handy a few times.

This likely works because a) you know what you're doing (cherry-pick), and b) you're being careful (staging carefully).

Anything works when both of those prerequisites are met. You're unlikely to do the bad things that force more advanced needs.

Everyone should do this. Think back to how much time you've lost due to git problems. It'd probably take less time to learn it correctly up-front, and never have to deal with them ever again.

I am in a similar boat, except I just Githubs desktop client. In the past 4 years, I think I have had to use the command line under 10 times.

Am I missing something, or is it impossible to, y'know, check out a previous revision using github desktop? Create a branch at a previous revision? Reset the branch to some previous commit? Any of these things?

It seems to have next to zero functionality. What is the point of it? What you you use it for, other than commit, push?

You can do most of the things you have mentioned using atlassians desktop client https://www.sourcetreeapp.com/

I know that, I'm just wondering what the point of GitHub Desktop is.

I use Sublime Merge, but no Git GUI I've used comes close to tortoisehg for mercurial. Tortoisehg is actually superior to and a comprehensive replacement for the command line. I wish something like it existed for git, if not for me then for the newbie-ish people I need to instruct on project workflows.

I agree. Almost every time I hear of someone having issues unpicking a complicated git issue it's because they were trying to be too smart with it and use every feature just because they are there.

Find a _simple_ git workflow, document it in a style guide, stick to it. Git doesn't have to be complicated.

I am similar but avoid rebasing entirely in favor of squashing. Squashing can also be used to turn a messy branch into a new branch full of nice clean independent commits.

I also don't bother appending (though my GUI lets me undo the last commit if I haven't pushed which is maybe the same thing.)

Most developers get way too fancy with Git and screw something up. I use GitHub Desktop and rarely touch the command line for Git. It has a great UI for being able to just pop over and see my current changes, and easily commit just a line or two from them to make commits other people can understand.

I will never understand why people use a UI for git. 99% of the time people who do that don't understand how git works. When something deviates from the normal workflow they struggle.

Never understand? I mostly use Git CLI, and it's a big pain. Weird terminology, needing to memorize branch names for easy use, differences between staged and pushed commits. And when you mess your incantation you ripped from SO up you get errors with strange terminology. I understand it's benefits and use it, but older simpler versioning systems like SVN had their own benefits.

While there are definitely UX problems, the following aren't:

- needing to memorize branch names for easy use: there is tab completion for this;

- differences between staged and pushed commits: I'm not sure what you refer here. the closest concept to the "stage" term is "staged changes". this is by design; the idea is that while one applies changes within a single commit, some are definitive, some are evolving; for this workflow, it's very convenient. if one doesn't want, they can just add all and commit (preferrably, with a single alias ;-)).

The "most extensive" Git UX problem is possibly the excess of functionality given to the `checkout` command, which in fact is being split.

(I don't imply that Git UX is good, though)

I think that's just your own personal bias on the matter – 99%, really? To me (IMO), Git is something that's inherently visual and not really suited to a CLI, it has nothing to do with not understanding how Git works under the hood.

> Git is something that's inherently visual

It absolutely is. The whole "branch" paradigm evokes topology. The visual structure of the thing you're working with ought to be made clear to you, the user.

If a GUI has trouble when the workflow deviates from normalcy, it's just not powerful enough.

That being said, there will always be users who prefer the command line, and that's totally fine.

Although git supports it, one doesn't normally need to use complex branch tree topologies that require visualization.

I use git UI because I want to have a good graphical overview of the repository. Really helpful on larger repos.

Agreed. Been using SourceTree for years. Still use CLI for various tasks but a UI is extremely helpful to:

- visualise the project in its current state which may spread across several feature branches all coming in and out of master

- code preview (hugely valuable) across one or more files

- see your branches

- see your stashes

- remotes, etc

- all of the above across multiple, simultaneous, projects.

Large projects can be difficult to manage if you don't have context and oversight, which is harder to obtain from the CLI.

Of course we can get this information from the prompt but it is much more difficult to get the information in an easier-to-consume fashion.

To be honest, staging individual hunks without a UI is a pain. I use Tig (a TUI) just for this.

`git add -p`

I use Tig as well, but more often than not the git cli is sufficient.

Yeah it's entirely possible but Tig makes it easy and I can do it in a fraction of the time.

Git is well suited to graphical interfaces, since it's quite useful to visualize the commit graph and for viewing diffs. The fact that the git command line tool is quite awful makes this even more of a no-brainer.

I get what you're saying, but not that they necessarily don't understand git. I guess it's just personal preference.

I don't know why, but I've always felt uncomfortable using git in a GUI, but I know a lot of people who love it.

For some reason, anytime I try to use a GUI, I don't feel like I'm really doing git, if that makes any sense. Also, I've personally never felt the need to see the branches visually. And if I do get the itch to 'see' them, nothing a quick

    git log --oneline --graph

cant fix!

And if they didn't use a GUI they either wouldn't use git at all or they would struggle with that too.

It's only an alternative interface... not much different pushing a button you don't understand than copy/pasting some commands.

Totally agree with everything on this list, with two exceptions:

* I almost always just do a regular merge to master (rather than squash).

* I use GitKraken which (in the pro version) has a great merge tool.

A lot of people seem to want "clean history" so just I'd just like to put it out there that it's not really necessary (there's nothing wrong with it, of course), and regular merges work just fine. In my experience, the two main reasons I look at git history are:

(1) Checking when a feature was done and what releases it got into

(2) Finding out why a particular line of code exists (blame)

For (1), with software with numbered releases, you end up following the branches anyway. Having the individual commits from feature branches makes you scroll more, but it doesn't make it any harder to follow. If you really don't like seeing them, you can hide anything but merge commits.

Even simpler, if all you care about is whether a given feature branch is done (merged) or not, that's easy to see and the same as a squash-merge workflow.

With continuously-deployed ("cloud") services, things are even simpler - you start at the hash currently deployed and go backwards. It makes no difference if there's one branch or many feature branches (other than scrolling past more granularity).

For (2), the greater granularity from individual commits is generally useful (at least provided that each commit has a ticket number and useful description), and squashing erases this detail.

Also, a nice thing is if you end up merging the same branch to multiple places (master and a release branch, for example) it's obvious what happened by looking at the tree. Contrast to if you cherry pick a squash merge commit, the only way to see that is to read both commits and realize they're the same -- and this is much less obvious if there's other commits between them.

Basically, squash merging doesn't help with either of these, and in fact actively hinders (2).

My team has been doing this for a few years, and I'm not even sure if it was a conscious decision to merge this way (or not do squash merge) but we've had no reason to change. It does depend on every commit being well-formed, but this is pretty easy to ensure in a paid team that works on this every day (whereas with open source I'm not sure it'd work well).

Anyway, like many things in git, there's more than one way to do it, and there's no clear "right" or "wrong" way.

Nearly every time that I google a git command, it's something related to tags.

Why do you always rebase? Is your master essentially the stable branch of the program you are collaborating on?

Same here but from Visual Studio, Eclipse and Tortoise GIT, while missing Subversion and Mercurial.

kdiff3 for merge conflicts is nice (I think)

In my experience, if you ever use more than clone, fetch, pull, push, checkout, merge(tool), reset, add, and commit then somebody messed up.

I rebase all the time FWIW.

I constantly use

    git commit --fixup 6138D3A
    git rebase --autosquash --interactive origin/master

to keep a clean history of cohesive commits. Rarely do I change _everything_ required for an objective in one go, I still like to commit as I work, I just like the finished product to _seem_ like I did it in one go, for future maintainers' sake.

And I rebase to catch up with upstream, I can't stand having intermediate merge commits in my history and rebasing lets you resolve conflicts as they're introduced, instead of an all-at-once at the end.

You might find this git alias useful. Wrote it a few years ago and find it useful daily.

    [alias]
      fix = "!_() { c=$(git rev-parse $1) && git commit --fixup $c && if grep -qv \"No local changes\" <<<$(git stash); then s=1; fi; git -c core.editor=cat rebase -i --autosquash $c~; if [[ -n "$s" ]]; then git stash pop; fi; }; _"

The workflow becomes:

    $ git add ... # stage the changes you want to apply to 6138d3a
    $ git fix 6138d3a

Wow, I always love when a git/shell elder comes along and shows me something like this. I didn't know about `git -c` before, I'm assuming it's setting per-command config values? I've also not used/seen `!_()` before... I'm assuming it's introducing something like an anonymous function and calling it at the end... but why not just break out the body of the function and execute it directly in the alias? Does it help with error propagation?

Thank you!

git will append all remaining command line arguments to the end of the aliased command. Therefore `!f() { ... }; f` is the usual style for this kind of git alias to get access to the arguments as needed with $1, $2, etc. in the shell function.

Reply on news.ycombinator.com