Master should always be in a deployable state.

Any commit that lands on master must include unit tests that demonstrate that it works (or at least doesn't break anything).

Incomplete features that will take more than a week or so to develop should be merged to master early protected by feature flags. This avoids long running branches.

I like squash commits: build a feature iteratively in a branch + pull requests, squash to master once it has the tests and documentation bundled together with the implementation. This gives you linear history.

People who prefer to review smaller commits can do so in the pull request - it's only the finished item that gets squashed into a larger commit.

This gives you a few things:

1. More predictable deployments (let's deploy every week with X items)

2. Better rollbacks (rollback to last production deploy instead of guessing SHA1 of last acceptable state)

Master = deployable state (stable)

Every deploy gets a tag (named with its version). Rollback to previous tag in event of failure. Deployments remain just as predictable.

It could be said:

> What we found to be most workable is develop is always "stable", then we deploy from master.

The only thing that changes is the configuration variables which are replaced at each env. This ensures predictable deployments and if we want to rollback we just pick the last release bundle and re-deploy that.

Gitflow is fine - better to use it (w/the girl extension) than spend time arguing branches.

Does anyone know of a layer that you can use on top of git to make the occasional squash and rebase easier?

I know gitless is a helpful layer on top of git but not sure it support this specifically.

It can be done if the commits are separate logical units of work rather than work in progress commits. One approach I take is to take the diff between your branch and master, make a new branch based off of master and stage parts of that diff (parts that make a logical unit of work) and make a commit out of it. You can do that with commands like git apply with the relevant diff hunks.

Then, to test whether each commit works, you can run git rebase --exec "your-test-commands" master and it will apply each commit in your branch and run the test commands. If they fail, then you can fix the issue in that commit and run git rebase --continue to move onto the next commit.

This way, you can get a logical set of commits where each of them are in a working state.

Are there really teams that don't do this?

I've worked on multiple projects over the years that had mostly a common code base but had to build and release to support different hardware platforms. In some cases, these needed significant but permanent divergence between the code for one platform and another.

In this sort of environment, concepts like "master branch" and "continuous deployment" have no meaning, and neither does a principle like always being ready to deploy. Your whole approach to things like branches, merging, rebasing, cherry-picking, bug tracking, and what a version number means is probably different to, say, deploying a long-running web application with frequent updates and all users running the same code.

And with multiple teams sharing the same code base, breaking master is going to slow a lot of people down a lot more.

I have little experience with multiple teams working on a single code base, but it sounds like a recipe for disaster no matter how you organise that. Make your code as modular as possible, so each team can take responsibility for their own code.

Merging can happen more than the (simple calculation) times a day though. What openstack does is check each branch on its own, but then tries to merge all a number of waiting PRs at one time. If they pass on fake master again, that's merged into real master.

Say you branch off of master, make some changes, and make a PR. Call this branch A.

Then you want to make a new branch, that depends on branch A. Call this branch B. The PR for branch A is still waiting to merge when you finish with branch B.

If you make a PR to merge branch B to master, you get a diff showing both PRs worth of changes. That's annoying to review.

If you make a PR to merge branch B to branch A, you get the correct diff for B. Huzzah! But if branch A's PR then merges, Github deletes the branch B PR and any comments/review. You have to remember to retarget branch B PR to master, then merge branch A.

Trying to keep master consistent without git-flow means we get PRs sitting around for a month and merge-conflict hell days when we merge everything to make a build to send to QA.

Git-flow is bad if you have CD. Git-flow is great if you can't do that.

You still should merge often to develop, which when tested becomes master.

Master is a working branch. Releases are pushed to Release and tagged with a date.

Isn't that what the develop branch in Git Flow is for? Your project might need some additional steps as part of its release process, and those can take place using the corresponding release branch, but the idea is that you can start a new release off develop whenever you want.

I like squash commits: build a feature iteratively in a branch + pull requests, squash to master once it has the tests and documentation bundled together with the implementation. This gives you linear history.

Indeed. We're talking about using Git. Even if you're using a Git Flow style of workflow, why wouldn't you regularly rebase any feature branches back onto develop if they're lasting more than a short time, so you are keeping up-to-date, and why wouldn't you squash the finished feature down to a single commit that can be fast forwarded onto develop when it's ready, to maintain a linear history with one commit for one significant feature or fix?

The only time I've seen non-FF merges in a Git Flow style project is for bug fixes on release branches, but those tend to be characterised by two key properties: they are relatively simple and relatively important. If it's not simple, you probably need to abort that release and go back to your main development line to do whatever more substantial work is required before continuing, then make a new release. If it's not important, you probably ship that release with the known bug, and the fix gets made on the "develop" branch via the usual process for incorporation in future releases. So the effort involved in merging bug fixes from release branches back to develop is typically both relatively small and well justified, and if you do need any manual conflict resolution, that implies divergence since the point when the release branch was started and then it probably is a good idea for someone to take a more careful look and make sure the bug is properly fixed on develop as well.

In gitflow, “develop” is master. The master branch serves no real purpose.

The intent of “master is always deplorable” is really that every commit, on every branch is deployable.

To me, this is the whole point of CI. Commits need to be restructured in such a way that everything works incrementally, otherwise you’re asking for trouble — how do you even bisect problems?

Yes, it serves a real purpose.

Develop is technically deployable (in CI/CD/CD terms it is delivered but not deployed), Master is that plus socially deployable, and hence actually deployed.

Now, some organizations don't have social controls on deployment that have timelines that necessitate a separation between those things plus release branches to support getting the technically deployable to be socially deployable, but some do, and those are often outside the control of the development organization, potentially the IT organization, and sometimes even the whole organization as they may be external controls.

I think this is a good treatment about why rebasing is bad: https://medium.com/@fredrikmorken/why-you-should-stop-using-...

I disagree with squashing commits when merging to master, here's why:

Your commit history is what you will use later down the line (think 6 months, a year, 2 years later) to find a very nasty yet incredibly subtle bug in your application.

Imagine said bug was introduced by a feature that took about 1 full month to code, introducing 1000 lines and removing 500.

That feature was probably made of many small commits (say, 25 commits total), on a feature branch called "super-feature".

If your developer cared at all about making "atomic" meaningful commits, each one of those commit will be introducing a small very well defined subset of the entire "super-feature".

The "super-feature" will in the end be the result of all of those commits together.

Squashing that history of 25 commits, will create one giant commit of 1500 changes. Have fun finding where in those 1500 changes that little nasty bug was introduced!

Instead, if you hadn't squashed, you simply use `git bisect` and find in no time that the bug was introduced by the 12th commit of that branch, which itself was a small commit of 1 little change:

  diff --git a/statistics.php b/statistics.php
  index 69e435aa9f..46666daa93 100644
  --- a/statistics.php
  +++ b/statistics.php
  @@ -8,7 +8,7 @@

  - a = b + c
  + a = b - c

  git rebase master super-feature
  git merge super-feature --no-ff

=======

TL;DR: Your commit history is as important as your code! Don't squash it away! I wish github never introduced that feature and instead developers were taught how to create a meaningful history of commits.

=======

> commit of 1500 changes. Have fun finding where in those

> 1500 changes that little nasty bug was introduced!

100% agree, the only purpose of this is to make "pretty graphs" at the cost of destroying the history of the code changes.

I prefer to write small commits with simple messages that explain exactly what that change does. Sometimes it costs some time in Git Gui selecting the lines that make up the commit, but ultimately it's worth it.

Though I will say that git has one big glaring problem with merge commits: they are effectively black boxes, and when you've have a big merge conflict, many git tools don't tell you how that was resolved in that merge. I recently came across a merge that wiped out some of my changes with no clear reason why. I redid that merge and there was no merge conflict at all, so it's still a mystery what happened there.

Still, rebasing has caused far more problems in my experience. It's only suitable for trivial, local cases and never on commits that have already been shared (pushed).

My workflow typically involves rebasing my local branches on master every time I switch a branch or start a work session, so typically conflicts that need to be resolved are very clear and small things (e.g. someone else adds a case to a switch statement in the same place your branch does).

The biggest benefit to this that I see is that your diffs are then much more clear in what they're doing, and you have the option to update the commit message to reflect the conflict resolution if required.

That said, if you have a big feature branch and try to rebase it after a month vacation, you're gonna have a bad time.

Basically you'd have to rebase after every single commit. That would keep it the most painless, I guess. But I can also just do a single merge and I'm done.

These are essential if you work with forced rebase mode like in Gerrit. (ugh)

You still have to be moderately careful and read the code again.

> with merge commits: they are effectively black boxes, and

> when you've have a big merge conflict, many git tools

> don't tell you how that was resolved in that merge. I

> recently came across a merge that wiped out some of my

> changes with no clear reason why. I redid that merge and

> there was no merge conflict at all, so it's still a

> mystery what happened there.

Hmm, I don't think a merge magically removes the need for testing. If I build a feature A that replaces feature B, and another programmer builds a feature C that relies on some aspect of feature B, when merging, although it will merge and compile fine, it's possible it is still broken.

This is a good argument for well defined interfaces, but it's possible to see how a successful merge may not produce a successful source.

As for things disappearing, I think there is some edge case where it looks like one branch deleted something after you made some change to it. Generally it's best to not have people working on exactly the same part of code. On the plus side, you have a full working history, therefore can recover :)

Still, the commits that were merged both still existed, to it was easy to redo the merge. I shudder to think what would have happened if this had been a rebase; then the original commit might have been gone.

One thing people should include in commit messages is why the change is being made. In other words, what's the purpose of the change. That can provide a lot of context that can be lost over time. So my commit messages include both what was done and why it was done. The why part can range from things like this method is needed for this feature that does something, or this fixes a bug that was causing this issue, or this other feature is no longer needed in context of this other reason, etc.

> the change is being made.

In a perfect world, there would be a massive document with each commit, specifying exactly how it behaves, all the possible edge cases considered, why it was implemented, other implementation choices and a justification for why this one was selected, etc, etc.

I think the reality of the matter boils down to a few points:

1. Commits are not read that often and if they are, it's usually recent history. If they are being read very much in the future, then the "why" may not even make sense either.

2. Unbounded limits on commit message lengths leads to some people waffling in their commits. If you can't explain it in 80 characters, you should very much consider breaking it down.

3. Usually it's not possible to isolate a commit from the context of the commits around it.

4. Usually it's not possible to understand a commit without the larger context of the system.

Generally if some implementation requires an explanation, it can be better understood as a comment next to the implementation in question.

It depends. If you're looking at the commit log directly, then you would tend to look at recent history, but if you're using something like git blame, you can easily come across commits that are far less recent.

For example, part of your change is to update a line of code in a file. You run git blame and see the commit that introduced that line of code, run git show for that sha1 and see the context around why that line was introduced (e.g., a bug fix). If you don't look at the history, you could easily introduce a regression in the code without realizing it. In other words, the VCS history can be used as a tool to help determine what potential effects a change could have.

> 2. Unbounded limits on commit message lengths leads to some people waffling in their commits. If you can't explain it in 80 characters, you should very much consider breaking it down.

There's no restriction on how long a commit message should be. Convention from the Linux kernel and git itself says the title should be limited to 50 characters and the body should be wrapped at 72 characters (other than things like links and error messages/log lines). There's no restriction on how long a commit message should be.

As for whether to split the commit up, that really depends on whether you're doing multiple things in a single commit, which may or may not have a relation to how long the commit message is. Typically, if you see something like "do A and do B", then that's a sign that the commit should be split into separate ones where one does thing A and the other does thing B.

> Usually it's not possible to isolate a commit from the context of the commits around it.

If you use a combination of git blame and git log, you can get that context. git has a feature that can be used with git log where you can search for whether a string/line was added or removed in a range of commits with the -S flag, or if the number of instances of a string/line changed with the -G flag.

> Usually it's not possible to understand a commit without the larger context of the system.

That's true for people who are new to the project, but using something git blame can help people new to the project find the person/people to ask about why that code was written the way it was.

> Generally if some implementation requires an explanation, it can be better understood as a comment next to the implementation in question.

That largely depends on whether people are diligent about updating the comments when they update the code. If you use git blame and look at the associated commit message for that line of code, it will always be up to date. If you make a change to that line of code, then the new commit message would be associated with that line. In fact, a tell tale sign that a code comment may be out-of-date is if the git blame output shows different commits for the comment and the associated line(s) of code.

And separate "cleanup" commits from commits that make meaningful changes. A commit that changes every line in a file because it's fixing incorrect indenting is fine. A commit that does that but also introduces a small functional change, makes that change invisible.

> A commit that does that but also introduces a small functional change, makes that change invisible.

While it's sometimes possible to separate the actual change from the formatting change by ignoring whitespace if the diff, it's definitely better to make each type of change in a separate commit.

Bottom line: the history, content, and message of each commit, in addition to the resultant repo state, are all artifacts of your work and are worth shaping and crafting in order to optimize for communicating to yourself and your fellow developers in the future.

The merge commit is important though. It helps delimiting a set of commits that have meaning all together from the rest of your commit history. Here's an example:

  a -> b -> c -> d -> e -> f -> g -> h -> i -> j -> k 

Compare the previous history to this:

          c -> d -> e -> f -> g -> h 
  a -> b /                          \ i -> j -> k 

My history here is still very linear. Yes, there's 1 little branching off, but that's all.

At my previous company we had a codebase of well over 20k commits entirely made of those little branches branching off master, then merging back in. It made it for an incredibly readable history.

An other added advantage of not removing the merge commit is that you can revert the entire merge of your branch in one go.

Without the merge commit, you need to remove each commit one by one (and that's granted you remember which commit was the first one and which one was the last one).

As for reverting merge commits, I'd rather not personally have to remember the rules as to how to re-apply after the revert (revert the merge revert, then merge the branch again)[1], let alone working on spreading that knowledge losslessly across the organization. This is admittedly something I haven't done much of, but I'd rather revert ~3-9 individual commits, squash the reversion commits (usually with a bit more context on why we're reverting), and push. And it could be scripted. I haven't made a script for it as it doesn't happen that often, but between using rev-parse and a sed script in the GIT_EDITOR environment variable it would be pretty quick.

Having merge commits also means that you have to teach everyone how to view diffs of merge commits, which admittedly isn't that hard, but it is still just one more barrier to know/teach/overcome, and the default behavior of showing a zero-line diff for a no-op merge commit doesn't help.

[1] https://mirrors.edge.kernel.org/pub/software/scm/git/docs/ho...

No, it won’t. If I didn’t catch it then, I will have to read the code and understand it and spot it.

At work, where my builds take anywhere from 30 minutes to 3 hours depending on the target, your git bisect on 1500 commits represents days of building and testing. Or I could just read the code again.

Commit messages should provide context for going through the process of rereading the code, and little else. If a commit message literally describes what the code does (“change constant from X to Y”), it’s self-describing and unnecessary.

In git, a "branch" is just a tag on a particular commit. What we intuitively think of as a branch is the set of commits starting from where we diverged on master and ending up with the commit that is tagged with the branch name. There is nothing in git that actually stores that, though. When you rebase the branch, squashing commits, you create a new commit that is that sum of all the other commits. The other commits are left unreachable by any other branch and will be removed the next time you GC the database.

What you are saying (I think) is to add a new branch called "merged-2020-03-03-BRANCHNAME" that points to the same commit as "BRANCHNAME" and then rebase BRANCHNAME, squashing the commits. In that way the old commits are still reachable and won't be removed.

The downside, of course, is that it's a bit of a PITA if you want to find out what commit changed a line of code and why. You would narrow it down to "BRANCHNAME" and then you have to search for the archived version of it, switch to it and then continue looking at your code. But, in principle it could be done.

This is why you use rebase --interactive or other ways of amending commits before submitting a PR. It is not an argument for commit squashing.

like 90% of developers (maybe 95%) don't even know how to rebase from master before they submit a PR, so I doubt, highly, that they'll learn how to do a `git rebase -i` in order to make things cleaner. I've personally never seen a repo that utilizes all these "fancy" git commands (fancy to those developers) to make a clean history, I've always seen the messiest shit. Maybe that's sad for me in my career, though.

I agree with you this is the best technical way, though, after reading some more comments in here, but not the best way for everyday developers.

The case the other way is that what should matter at the end of the feature development is the visible contribution it makes to the overall project, i.e., the finished code, tests, etc.

This has two fundamental consequences. Firstly, in this model, your final commit that goes onto whatever you call your primary development branch should be a complete, self-contained piece of work, like adding a new feature or fixing some specific piece of broken behaviour. It should include any related tests, data files, etc. It should be something that can be reviewed in isolation and make sense. It should ideally be something that has minimal interactions with any other code that aren't strictly necessary, so it can be removed or replaced later if necessary with minimal effort to resolve or rewrite anything else that has happened since.

Secondly, requiring all work-in-progress commits to also be meaningful and live forever in your shared repo significantly limits the usefulness of source control for the developer during the development stage. They might be experimenting with different approaches but want to keep track of a version where some specific aspect of the code is currently working. They might be about to refactor to clean some new code up but want to make sure they can't lose the exact version they had just got working due to unintended side effects. They don't want to be getting every individual commit code-reviewed or run any slow testing processes, just in case someone later comes along and cherry-picks that particular point in history to use as the basis for something else.

So I will respectfully disagree with you that the full commit history at this level is as important as the final code. My reason for that is that the final code is complete, tested, reviewed, and going into the finished product, while anything in the work-in-progress commits that didn't survive to that point was determined, by the developer doing all of that work, at the time, with the aid of all of the testing and reviews and tools that were involved, not to be as valuable as the final version.

If there really were interesting alternatives considered during development that might be useful to keep around for later reference, you can always tag or branch at that specific point and give it a meaningful name. However, I would suggest that this is like keeping issues open in your bug tracker when you know you'll never fix them: unless you also have some process for keeping track of such ideas and why they are valuable to refer back to them and take some useful action later, you're better off not having them clutter your main development process and tools forever.

I think I should have been more explicit when saying "your commit history is as important as your code". Because I definitely agree that your commit history, representing all the thought process you went through while developing whatever you're coding, does not have its place in the history, and I, as a colleague and reviewer of your code, couldn't care less about it.

I make a distinction between "WIP commits" and "atomic" commits that have well defined boundaries.

While developers work on their feature branches, they should be free of committing however they want, making "WIPs" commits left and right, adding code in one commit, removing that same code in a subsequent one, refactor, type terrible commit messages with no meaning, or not committing at all even.

However, once a feature is ready to be reviewed (and then released), I'm arguing that developers, before submitting their work, should re-organize their commit history: remove WIPs commits, remove refactors that happened during development, squash distinct commits that are part of the same logic, amend commit messages, etc.

The final commit history shouldn't be a series of commits that represent everything that went through the mind of the dev who coded the feature: that's not what I'm arguing for.

The final commit history should simply be multiple small digestible and reviewable chunks of work, that make sense on their own and in the context of the pull request they are part of. Those commits should represent the code in its final, best, most well thought out form.

And once you've gone through the trouble of organizing your work into meaningful, atomic, digestible, chunks of work, with appropriate descriptive commit messages, there's no reason not to merge that work.

As it was useful to the reviewer of your code during the pull-request review, it will also be useful many months later, when you need to review that same old code that seems to be having a bug or to understand why it was written the way it is.

Well, at least, IMO.

I agree that this is the optimal solution but isn't this a hefty piece of work that even might introduce subtle bugs?

Eg. I'm thinking of the overall feature needs work to be done in two separate "areas" of the code base and your wip-commits are touching these two areas "separately". Then when you are finished, reordering and squashing the wip-commits into two atomic commits seem like an obvious thing to do. But in a minority of commits you change that tiny little shared part back and forth, from both contexts. Finally you figure out how the shared part should work in the final wip. When you try to reorder the commits the changes in the shared part changes order with leads to merge conflicts when rebasing/reordering/squashing that needs to be solved.

So I'm on the fence of doing that extra work which in practicality could involve an unknown amount of "made up work" to get the clean atomic commits. And those commits then risk being a lie since the reordering, like the shared part in my contrived example, could have made that the first "atomic commit" that never existed also has a bug that never existed that someone down the line potentially stumbles upon when bisecting.

An alternative approach is to create a new branch off of master (or whatever the base branch is) and take the diff of the HEAD of your branch with your work in progress commits and stage the hunks of the diff to make a commit that contains a logical change (and repeat the process for the remaining parts of the diff). The git apply command us very useful in this regard.

I'm going on a bit of a tangent here, but unit tests don't demonstrate that it works – acceptance tests demonstrate that it works. Unit tests help reduce the time to narrow down problems and in some cases help with refactoring (if refactoring is limited to the inside of methods).

+1 to this and squashing commits. I'd even go far as saying trunk based deployment model over trunk based development.

This can be done via Pull requests or short lived branches. I prefer having all the context, discussions and testing added to the pull request. Even setting up environment per pull request. It's much easier to track and get feedback.

I think the head of master should always be deploy-able, but ultimately it seems better to make use of tagging of specific hashes which realize some degree of reliability for field use.

Obviously you have your unit tests and other kinds of tests, but ultimately nothing beats just using it. If it "feels" reliable (which can be hard to quantify sometimes) or has proven itself (you've been using it without issue for some time), then it's probably worth tagging for that fact.

> Incomplete features that will take more than a week or so

> to develop should be merged to master early protected by

> feature flags. This avoids long running branches.

I prefer to properly scope the time/effort required to complete a feature, rather than having massive features. If a feature is taking more than a few weeks to bring into fruition (assuming ~1 dev per branch), then it's probably too large of a feature and needs to be broken down. A properly sized feature should probably fit within a sprint cycle.

Ideally, I agree, though this does depend on what your business requirements are. Some features are just fundamentally complicated, and it might not be possible to implement the feature itself, or even decompose it into meaningful parts that can be implemented, in one short round of work. Fortunately, that doesn't happen very often for most types of development work!

> Fortunately, that doesn't happen very often for most types

> of development work!

Every problem should in theory have some of breaking it down, otherwise we have no hope in programming it. We should be able to break it down far enough that it can be reasonably sanity checked. If the feature is too complicated then you're asking for bugs.

From an objective/goal stand point, we also need some way to measure our progress and be able to evaluate whether a pivot is required. It's very easy to get stuck in a problem for a long time if we have no external measure.

I don't see why we should expect that to be the case. For example, I once had to implement an algorithm to visualise a certain set of data using a certain type of diagram, where there were a lot of technical factors that determined exactly how that diagram should be drawn. IIRC, it took a few weeks to implement that algorithm, but there weren't any natural breaks where you could, say, draw only half of the data set or half of the diagram features and get a meaningful result. It was inherently a relatively complicated, all-or-nothing feature.

For example:

Step 1 : Extract relevant data

Step 2 : Massage data into the correct format for graphing

Step 3 : Graphing tool visualization for simple example data set

Step 4 : Write tests for graphing/visualization

Step 5 : Plug real data into graphing tool

  git log --simplify-by-decoration

* Early adopter independently comes up with an idea that works well for his/her team.

* Writes an innocent well-written article or book.

* Idea somehow becomes dogmatic. Even for situations that don't make sense.

* After some time, people rebel against dogma because they realize it doesn't make sense for every situation.

* Original idea now considered anti-pattern even though it may still make sense for some people or situations.

    1. See success
    2. Want success
    3. Copy behaviors
    4. Behaviors were only part of success

I'm going to say this rather rashly (and maybe regret it sometime in the future): any "Agile" process that includes a status meeting for developers is broken. Status should be determinable from the artifacts that have been produced. If management can not see or understand the artifacts, then your process is broken. If they prefer not to look at the artifacts, then your management is broken. If they need status on something that is "taking too long" then you haven't broken up your tasks enough. If you have broken them up enough and it's still "taking too long", then there really isn't much to say other than "this blew up on us" -- which is obvious.

What a standup is good for is casually checking with your teammates that the approach you are taking is reasonable and to discuss other strategies. It's useful for asking for help, swapping pairs (or getting one in the first place). If you find yourself doing the "This is what I did yesterday. This is what I'm going to do today" dance, then you are not getting much value. It should be blindingly obvious what you did yesterday, because code was written, reviewed and hopefully merged. Possibly you may want to say, "Hey, can you review my code?" It should be blindingly obvious what you are going to do today, because you grabbed a card/task from the backlog. The only thing you need to talk about is, "I'm confused. How do I do this?" and the like.

/end rant ;-)

Hell yes! Status meeting can be a band aid while you get people to properly document and communicate those though. You often don’t need the whole team for that though.

It's a bit of a joke.

I think experimental evidence helps, but if you look at the physical sciences more closely, you'll find tons of similar narratives. This is a fairly universal human behavior unfortunately. Nonsense becomes "canonized" as I put it, and then continues to be repeated by people until someone finally looks into it and realizes it's nonsense and publishes an article saying so. But unfortunately that's not always the end of the nonsense. Even things which have been debunked can continue to be cited and used. One great example (not engineering but the point stands):

https://www.youtube.com/watch?v=WRoe3xXFtmM

> In one sense we won. We got our points across. People now understand that this research is wrong. But this 2005 article by Fredrickson and Losada gets citations today at 3 times the rate of our article that demonstrated that it was just utter rubbish.

(Note that I'm using "nonsense" as an example here, but the top level comment was more general in that it mentions practices which apply in some situations erroneously being applied for all situations.)

No doubt there will be arguments for how oracles for ethereum are different, and so on

> While I hesitate to say “Worrying about merge conflicts” is a valid reason not to pursue a branching strategy like gitflow

I do not hesitate! This is _very good_ reason to avoid gitflow.

Merge conflicts by definition require human intervention. And human intervention means an opportunity for human error. Resolving merge conflicts properly ranges from trivial to nearly impossible, depending on the specific changes you're trying to merge.

Often none of the authors involved in the conflict are in a good position to understand why it happened. One person makes a small bug fix change to a few lines of code. But that fix required hours of research and a solid understanding of the problem. Meanwhile, someone else is doing a refactoring of that same code in another branch, unaware of the bug.

Neither of these two people may be in a good position resolve the conflict. The bug fixer doesn't understand the refactoring, so they don't know how to apply the bug fix in the new code. The refactorer doesn't understand the subtleties of the bug fix and the code being fixed is just gone in the refactor. It's going to require the two of them working together to fix this, and it may took several more hours and they still may not get it right. And that's the best case! Realistically, one person will muddle through the merge and hope that things still work properly.

Of course, merge conflicts are a fact of life in _any_ version control scheme without exclusive locks (remember RCS?), but minimizing them is a very valid goal.

In general, I feel a lot more confident with using feature flags and the like to keep work in progress from prematurely going live than I do using branches to do the job.

Or, if I could take a stab at saying it pithily: Having your code be continuously integrated is a prerequisite of doing continuous integration.

Merge conflicts are rare for two major reasons:

1. We plan our changes to avoid the likelihood of merge conflicts. Specifically, we try to avoid two people working on similar areas of code at the same time. 2. We have functionality split into a fair number of different repos (though I probably wouldn’t call them microservices), which not only makes 1. easier, but simply reduces the chance of two people pushing commits to the same repo.

Part of 1. also involves giving slightly bigger pieces of work to a single developer, so that person can see it all the way through from the start. That way, there may not be as many short PRs that are quickly merged, but that developer can really wrap their mind around the complexity of the problem and hopefully have a higher quality functioning product at the end.

Of course, we also have our use cases reasonably solidified when we start building, since our company is over 8 years old and we take the time to know our customers’ desires fairly well (and are always learning more, or course!).

On the other hand, its a lot easier to see if a conflict resolution attempt didn't work during a rebase because the individual commit diffs and the overall diff would make obvious (e.g., unrelated code in the master branch was changed out removed).

I really didn't understand this post. To me, it seemed like someone writing a critical perspective of a process they don't fully understand. I know it's not because of a lack of documentation, git flow has been blogged about ad nauseam.

I have friends who use different branching strategies who complain constantly about the same pain points the author brought up. The only thing I agreed with the author with is to find a strategy that works.

That way, merge conflicts, if any, are limited to merges that involve porting bug fixes back to earlier released versions.

Ultimately I think the problem is that Git solves too many problems - it provides a very general data structure that can be used in a lot of different ways, but the tooling itself is mostly agnostic to how you want to use that data structure. Teams can define preferred workflows on top of that, but the tooling itself doesn't enforce the workflow, or provide any specific affordances that help you properly comply with the workflow. Instead, every developer is supposed to keep the workflow in their head, and make judgement decisions every time they interact with it.

The cost of this is huge. We're sorely in need of opinionated tooling that sits above Git's data structures and makes real-world workflows simple to follow correctly, and difficult to mess up.

It's funny, I can't remember the last time I had to give serious thought about how to use git.

Sure, there's a learning curve. When I was just starting out, I didn't get it all right away. But it's been years since I've thought much about branching strategies and stuff. And I don't get myself into "terrible messes" that take hard thought to get out of.

Not saying you're 100% wrong. But it doesn't line up with my experience.

Every time, they are mentally unwilling to learn git.

And before anyone mistakes that for complexity on git's side… often, these folks have trouble with even basic questions, like, "is this the change you intended to make on this branch?" when shown a diff.

I've seen people like this too, when reviewing PRs, I often see unwanted code being committed, and I just don't understand why this keeps happening. One of my defaults when committing code is to run "git status", then run "git diff" on each file I'm committing. I thought this was a pretty well used flow, but apparently it's not.

If you only ever use `git add -N .` and `git add -p` you'll never have unexpected changes in your commit.

Needless to say, this caused a bunch of issues that made them think git was bad. When I asked "why don't you just checkout the branch you want to work on?" The answer I got was "I don't like working that way... Now fix my horrible mess of esoteric git features that I misapplied"

And yet I don't run into such behavior from people using SVN or mercurial.

Git springs to mind for one, but (capital A) Agile definitely wins the championship.

I find the biggest issues are people who don't really understand Git enough doing silly things, or just being careless. Like somebody cherry-picking something to Master and then cherry-picking it to a branch we're working on, but on top of some stuff that has changed in that branch, requiring them to fix a merge conflict. But then when it comes to rebasing the branch on Master to merge it, you then have two more conflicts to deal with that you didn't need to have, if it had just gone once to the right place! It's not hard to fix, but annoying, and you risk introducing errors to the code if you accidentally miss a line or something.

So the biggest issues are probably 1) people not following our workflow, creating extra work to fix, 2) people not understanding Git enough; or possibly for some people, 3) you team/company's git workflow isn't very good.

In most teams for 3 (which is probably one of the more common ones), you really only need one or two people who really understand Git well to set up the workflow and enforce it.

I follow Linux kernel posts on vger.kernel.org and I've yet to see Linus complain about a git commit failing. I guess he isn't very experienced either?

The git portion of that is pretty straightforward, but whatever the linter is doing looks rather complex.

It doesn't have binaries in it, 'cause git-lfs. But I don't remember the last time I had a problem with it other than PEBKAC rebases and the like.

You make unwarranted assumptions about another person's experience base simply because it supports your position to do so.

> * Binaries

> * Large Repositories/branches

> * A disparate set of development platforms/clients

> * Git auth/credentials

I have experience with all of these things and have not had a commit fail.

Sure, SVN doesn't have as many features as git, and merging sucks, but it offers the most important features of version control (recording "who has done what, when", and undoing changes). Teaching SVN usage to a non-techie takes literally a few minutes (especially with an intuitive UI like TortoiseSVN), and it's very hard to break something.

Also anything like visual studio / vscode you have 99% of what you normally do right in the UI.

I think it's anal people who like to make things as complicated as possible who try to make git as complicated as possible for others.

But of course we've cargo-culted it everywhere, and anyone who objects runs up against the pervasive attitude that there are no bad user interfaces or difficult-to-use software, only stupid people.

What's happening under the hood is mostly fine (mostly, because git completely breaks down with large binary files, and solutions like git lfs don't help much with this problem).

What's really bad is the git "frontend", that there's no obvious standard workflow, instead there's a thousand ways to do the same thing. That's great if you have a lot of time for tinkering and meddling with the tools layer, but not when you simply need to get shit done. The version control system should essentially 'disappear' and never require attention.

We had simpler, easier to operate version control tools. Git traded off some of that simplicity for other benefits the community at large seems to value enough to have migrated away from the simpler tools.

I'm skeptical the "git is too complicated for newbies" cry is truly a turning point in tech cycle where we see the folly of our ways and begin to decry the current flavor of the month at the new anti-pattern after enough real-world experience has been accumulated to show us the error of our ways.

I think it's just "I don't like the way this makes me feel".

70% of students screw up their repository every year.

My experience is that SVN is just as hard as git for the purposes of managing versions and branches of your work.

99% of the behavior it implements people do not use.

Git is not the correct level of abstraction.

  git init
  git clone
  git clone --recursive
  git remote add
  git checkout
  git branch
  git merge --no-ff
  git add
  git add -p
  git rm
  git reset
  git commit [-a] [-m]
  git commit -p
  git commit --amend
  git submodule add
  git push
  git push -u
  git pull
  git log
  git show
  git status
  git update-index --assume-unchanged (aliased to ignore)
  git update-index --no-assume-unchanged (aliased to unignore)

If we're doing something other than git I'll be happy with those. Specifically add/commit -p are important to me.

While working, I’m freely taking advantage of Git’s capabilities on a personal level, producing many sometimes messy WIP (work in progress) commits, trying things on short lived branches, reverting changes, and so forth, but afterwards I am able to copy edit the results to produce a sequence of finalized commits that form a coherent narrative that reads like how I would describe my work to a colleague or manager.

To me, interactive rebasing has been the difference between “my team uses Git” and “I first and foremost use Git for myself, and then also use it to share the results with my team”.

I like presenting and merging tidy changes.

"git blame" is also very useful.

"git bisect" is remarkably useful once a month or so. It does a binary search to find the commit that broke whatever thing you've recently discovered is broken.

Recently my coworker asked for help tracking a regression after spending hours finding the culprit, I bisected it in a couple minutes and his mind exploded :-)

And git reflog is indispensable for fixing things.

And I'm surprised you didn't mention git diff. I do that all the time to compare things, like having a single diff of all commits between the origin diff base and current HEAD. Also useful for summarizing changes of entire feature branches.

Git is like C++. People learn and use a different subset of it and everyone claims their own chosen subset is powerful enough and entirely sufficient for everyone.

Rebase -i is a lot to fun, I ought to practice it more. Haven't had to use reflog yet, but I'll be expecting it now thanks~

      1 git clone
      2 git cherry-pick
     10 git reset
     17 git merge
     23 git fetch
     34 git checkout
     37 git rebase
     66 git diff
     75 git pull
     79 git log
     87 git branch
    126 git commit
    135 git add
    141 git push
    201 git status
    205 git grep

    122 git bug
    124 git branch
    169 git show
    247 git reset
    274 git rebase
    308 git fetch
    310 git fixup
    576 git commit
    633 git push
    692 git pull
    889 git stash
    949 git diff
   1122 git add
   1681 git checkout

After github, things became much easier and it is likely the main reason people use git over mercurial.

Of course, now I work at a place that uses Mercurial, because Git can't handle the size of our repo (an order of magnitude, at least, bigger than the Linux kernel)...

Whether it is programs like Photoshop and Excel or programming languages like C and JS, general purpose tools have a lot of appeal: learn the once, use it for anything.

Of course there is the opposite as well: niche tools that solve a specific problem in an opinionated way, like photo filter apps, Elm, R, etc...They have a lot of appeal too because they are better suited to the task at hand, but have limited use outside their specific domain.

But the most popular and widespread tools are always from the former group. R is great, but there are always going to be more python repos on github than R repos. If git was opinionated, it would serve a smaller niche better, but other niches worse, so it wouldn't be the industry standard it is today.

For better or worse, I've observed that powerful with footguns is always more popular than more limited options .

That's almost all you need to know. Get that down path and you're on your way to being a Git power user.

If you can't handle that, then maybe you can't handle programming either.

The last thing we need is more opinionated version control tooling. We've tried it (e.g., Mercurial), and it has failed in the market. But if you want opinionated version control tooling, well, there it is for you to use.

Git is a glorious tool, but such tremendous power implies a lot of complexity and a lot of different ways that you can work with it. You can have 10 engineers and find they have 10 different opinions and everything ends in ego fightings. The best way is to have an owner of this, make the team understand the governance issues being resolved with the flow and disagree and commit (pun intended ;)

Didn't you just break the golden rule of Git which is to never rebase onto a public branch?

The fact that a) there even needs to be a golden rule, b) it's not obvious c) not everyone knows about it ... and I'm sure for many other reasons is a very strong reason to be spooked.

Git is like uranium, powerful, but so many don't even know what they are getting into.

Or maybe it's like C++ - really dangerous, but after a while, you learn to avoid most of the pitfalls and then it starts to feel 'ok' even though such pitfalls shouldn't exist in the first place ...

[1] https://www.atlassian.com/git/tutorials/merging-vs-rebasing#...]

Again it troubles me that even the language of Git is sometimes ambiguous.

I feel that there should not be a 'golden rule' of something that should never be done - it's a flaw in the product. It simply should not be possible, or at least not with someone without super-admin rights.

I feel Git is very much an administrative level tool, and that there should be something else for devs; something that is fairly obvious, consistent, encourages/forces the org. the policy and makes it so that devs don't have to think to much and really hard to screw up. Admins can give special privileges to the 'true experts' on an as-needed basis.

Rebase workflows are the best. We used them at Sun long before anyone called it rebasing, long before even any VCSes had the feature in any way. It's the only workflow that works in large codebases (monorepos, repo forests) with thousands of developers. Merges stop being interesting very quickly once you've got a) a large number of developers, and b) a high rate of commits on the same codebase -- it's just too much metadata.

Linear history works like a charm and is super easy to understand (because it's linear).

Nobody cares about the internal history of a feature branch that has delivered. One should only care about what mainline bugs were fixed and what features were added -- bugs that never made it to the mainline are simply not interesting at all to developers on the mainline (though admittedly they might be to someone studying developer performance, but then, feature branch history can be kept and archived, just not on the mainline).

Theoretically, one could also use merges on the feature branch and rebase once at the end of development (as git will auto-remove all merge commits during rebase), but that only works well if you have just a single commit between merges on the feature branch.

[1] https://git-scm.com/book/en/v2/Git-Tools-Rerere

[0] https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee650...

I do sometimes have to rebase across thousands of commits because I let a branch rot, and that can be hard to rebase, but it can be equally difficult to merge. Instead I use a bisecting rebase approach where I try to rebase straight to the new upstream, and if there's conflicts, abort the rebase and try rebasing to halfway to the new upstream, continuing the process until the rebase was across just one commit, thus I can resolve conflicts directly with the upstream commit that caused them, then restart the process until done.

(Viktor here is https://github.com/vdukhovni/, and I did heavily alter that code.)

Thanks for the gist

Merging doesn't have that problem, it usually just merges fine unless there are conficts in the latest commit (not all previous ones).

is this solved by enabling git-rerere ?

https://medium.com/@porteneuve/fix-conflicts-only-once-with-...

Also, with this script you get to see which of your commits is conflicting with which upstream commits. That's really important information to me.

I'd really like git to have this feature built-in to it...

One can implement that even with Fossil or any other VCS that pretends it does not implement rebase and pretends it never will.

Squashing public commits I'm also against. People say it 'cleans' the history. I would say it erases it. Who, when, why - all gone. For what? to save a few commit lines? Like I said, our commits are tagged with the ticket number already, if you want a summary of what the changes were and all the commits that were part of it, you open the ticket, or filter the git log on the ticket. No need to move commits around in the history, they show in the same order when you apply a filter.

In my book, it's easier to auto-import sensible git logs into JIRA than trying to do the reverse. Then again, I'm of the opinion that git history matters, specifically for commit messages. Otherwise, you might as well create a pre-commit hook pointing to http://whatthecommit.com

If you keep your development rationale with the code, you can always change or rearrange the rest of your tooling without losing vital information. If you put your edit history in a loosely-coupled system, you've now made that system as essential to your codebase's survival as the code itself.

I hardly ever refer to the commit log. However, I do often run `git blame` to figure out what changes were done to the code base together with a specific modification to a specific line of code. That works so much better if people have actually spent some effort to make sure related work is in a single commit.

(Note that this doesn't mean "squash every PR together" - it means rebasing before submitting a PR to make sure the commits also work as documentation. The result of that rebase might very well be several commits.)

Squashing down a PR to a single commit erases all of that history and we have no idea when the change was made, who made it, who to talk to, or why it was made other than it was part of a larger feature set.

It might work fine for smaller PRs, but where I am we have multiple teams each working on a task that can take months to complete with lots of testing before it's ready to merge into a release branch.

I don't argue for squashing down the whole branch into one commit. That's silly and could be throwing away valuable information. But cleaning up the history using rebasing is still possible. We use "fixup!" commits so that a simple autosquash does the right thing most of the time.

I've actually had developers undo over-eager squashing before and introduced them to both the reflog and interactive rebasing. They are shocked the first time they learn to "undo" a rebase, but it's a liberating experience to actually understand git.

The reason you use blame is to find the exact commit that changed a specific line, and hope to find the rational / decisions that lead up to this change, assuming people are disciplined enough to document that in their commit messages. If not, maybe you could even ask Josh if they still remember why they changed things a certain way.

Many developers commit append-only until their feature works, which means there are a lot of noise commits in between, which they don't (know how to) clean up. Rather than having all this noise, projects opt to squash the commits instead.

But I didn't want to lose the detailed history either, so our squash commit message contains the complete list of squashed messages, and we keep the old feature branch alive forever on a separate remote.

Here's Linus Torvalds' thoughts on rebasing. https://yarchive.net/comp/linux/git_rebase.html

I have no problem if you want to locally squash your commits. Just don't rewrite public history. It's not worth it. At our commit rate, no one is reading the combined history logs without filters first.

One day you'll find a commit labeled "removing comments" that breaks something because the dev palmed the trackpad while hitting the delete key and lopped off a line of code. You want that to be something you can find with a bisect.

It amazes me to see a bunch of discussion here from people arguing that one should throw away history so that some silly graph view is prettier.

History isn't meant to be pretty. It's meant to be history.

But once history has been shared (pushed, generally), it really shouldn't be touched anymore.

Gitflow doesn't work in a CI environment on a modern software application that has good testing culture and systems that are resilient to failure.

Tools and processes work a lot better when they work for you, not the other way around. KISS.

I don't know if I fundamentally misunderstood gitflow but this was my take on it from the beginning and I've never had issues with it that made me want to jump ship.

We didn't use hotfix or support branches, and we never really used tags for anything either. Not using them didn't cause any noticeable overhead.

The nice thing about git-flow in my opinion is that you can implement it without all of the CI stuff, then add that later over time. This is a godsend when you take over a legacy product with little to no test coverage and no CI pipelines.

I've also never run into a ton of merge conflicts, but the largest team I've had is 70 people so maybe it breaks down at some point that I haven't experienced yet.

In my setup I have a develop branch and the idea is that anything in it can be deployed to prod. Of course, that is if nothing fails.

If nothing fails, it merges with master (what’s actually on prod).

Use something by applying it with common sense, in the right amount and customization and it will have a chance to work.

Use something as if it is a religion and it will introduce weird side effects.

Sure it does.

It isn't necessary in such a culture if there aren't bureaucratic barriers to continuous deployment which limits you to continuous delivery.

If you have such barriers, you very quickly need Gitflow’s split between permanent “develop” and “master” branches as well as temporary “release” branches.

How do you roll back in a process like this? I was imagining that a release would consist of tagging master, so a rollback would be going back to the previous tag. Or perhaps you just keep track of the previously deployed commit hash and roll back to that?

I just was working with a client that used something like git-flow, where develop was deployed to staging in order to test, master was always production, and the codebase is largely a monorepo. Then there were a couple other legacy repos, which also are using git-flow. It... "works", but it also is a needless source of pain. You need to PR to develop, then PR develop into master, and I'd inevitably get bitten with merge conflicts in the process. All that for what gain? I saw no upside to it. Maybe if you have steady release cycles, but git-flow never seemed to fit the whole disposable branches, master is good to deploy dozens of times per day sort of workflow I've gotten used to.

So if you are doing full gitflow or if you are doing this degenerate case of gitflow you still shouldn't be getting merge conflicts when releasing develop (merging develop into master). This should basically be a fast-forward with perhaps a merge commit for record keeping. The only way to get conflicts in this case is if there is some other process that is changing master independent of the "releases" from develop.

In gitflow those other changes are managed through the hotfix branching rules, which ensures that you resolve the conflict when you close the hotfix and back merge it into develop.

While it's great that you've found a branch strategy that works for you, I would hesitate to take recommendations from anyone who doesn't rebase their patches. Then it's just an elaborate way of doing cvs style development.

Which there is nothing wrong with of course. That works great for many people. It's just not what git does best.

It always sounds like this happens at a hellish organisation where some Agile consultant once came in and said not to bother with boring stuff like management or software architecture. These must be strange places to work, because reportedly they also need to be prepared for requirements to change significantly every 27 seconds, and not being able to deploy changes in minutes is an existential threat even though the new feature has barely finished running the automated test suite and doesn't yet have any kind of user documentation, knowledge among the sales and support teams, etc.

Personally I do find rebasing and squashing to be very useful in workflows that involve Git, but there are plenty of effective ways to run a project and use a source control tool that don't rely on a 100% linear history with GitHub-style pull requests for change management.

Conflicts have only given me a hard time when someone did something out of the ordinary. Even very large and unstructured open source projects such as the Linux kernel will see people naturally gravitate to different parts of the code. It's not often a filesystem developer suddently change the networking stack, for example.

This article is full of bluster about how bad gitflow is, but very little actual reasoning why.

I don't like the ceremony all that much, but its working really well at my current large corporate gig across thousands of repos and engineers.

Doesn't git-flow explicitly keep a long lived branch around by design? The whole concept of having "develop" run in parallel to master is introducing a long lived branch. That's typically the branch that I'd always have the most trouble with.

Feature A is in staging ('develop'), but can't get into prod ('master') yet. However, the opposite is true of Feature B -- a customer needs it now and timelines get changed by sales or management (your largest customer needs it now). It conflicts with something in A and can't go into staging just yet (another team needs it). So that feature branch needs to go straight into master without hitting develop. The whole deployment infrastructure was designed on the (false) assumption that develop is always deployable to staging, and master to prod, rather than being able to quickly deploy and test feature branches at whim. So now we've diverged between master and develop a bit, and while we could still get our way back to a "clean" git-flow at this point pretty easily, if you're not careful this can keep compounding. I've seen it compound for months, and personally have wasted days trying to clean up conflicts that set in because teams I'm consulting for weren't careful.

It's easy to have an inexperienced startup team make these git-flow based decisions early on, get stuck with them for some time, hit rapid growth, and then get themselves into a messy place.

My point is sure, use it if you have pretty steady release and deploy schedules. But if you're deploying dozens of times per day you need to design your infra and CD strategy to handle it. Typically I've seen teams with fragile deploy strategies they've adopted due to assumptions they made from starting with git-flow.

So why even do it? There are simpler strategies like GitHub Flow that force a team to design a deployment strategy that accepts that feature branches can be tested in a real environment, and master can always be delivered (or rolled back).

Specifically, the algorithm is something like this (not tested; I've a script I should publish):

  bisect_rebase() {
    local ultimate_target=$1
    local target=$2
    shift 2
    
    b=$(git merge-base HEAD $target)
    while [[ $b != $(git rev-parse $target) ]]; do
      n2u=$(git log --oneline $b..$ultimate_target | wc -l)
      n=$(git log --oneline $b..$target | wc -l)
      
      # Try rebasing directly onto the target
      git rebase --onto $target $b && return 0
      
      # If we have conflicts and rebased across just
      # one commit, stop here
      ((n2u == 1)) && return 1
      if ((n == 1)); then
         echo "Fix conflicts and exit 0 to continue or 1 to stop"
         if $SHELL -i; then
             git rebase --continue
             return 0
         else
             git rebase --abort
             return $?
         fi
      fi
      git rebase --abort
      bisect_rebase $ultimate_target $(git log -n $((n/2)) --pretty=%h $b..$target)
    done
  }