Comparing Git Workflows
atlassian.com
Comparing Git Workflows
1–10 of 104 posts
Re: Comparing Git Workflows
#2This article has actually been around for a while. Explains it really great. But one advice from me is that try to choose only what is sufficient to your project and team. No benefit in being overequipped for a simple job.
Re: Comparing Git Workflows
#3This article has actually been around for a while. Explains it really great. But one advice from me is that try to choose only what is sufficient to your project and team. No benefit in being overequipped for a simple job.
I agree--- I've worked with several of these, but for most of the (smallish) projects we do, we end up coming back to a centralized repository, occasionally using feature branches if necessary.
We're a small shop with only 1 or 2 folks working on the code at a time, and mostly are using git as part of our deploy process... so simplest is the best for us.
Re: Comparing Git Workflows
#4One of the things I hate about the traditional git workflows describe there is that there is no squashing and the history is basically unusable. We have developers where I work that use our repo as a backup, then when things are merged to master, the history is littered with utter garbage commits like the following:
"commit this before I get on the plane"
"whoops, make this compile"
"WTF?"
These add no benefit to history, and actually provide an impediment to bisecting (since a lot of these intermediate revisions will not even compile).
At my previous job, we used gerrit. The nice thing about gerrit from my perspective is that it kind of "hid" all of the intermediary stages in the gerrit review. So you could push all you wanted to your gerrit review fake-branch thing, and when you finally pushed to master, there would just be a nice, clean atomic change for your feature. If you needed more detailed history of the steps during review, it was there in gerrit. But master was clean, and bisectable.
Is there any git other git tool or workflow which both allows people to back things up to the central git repo AND which allows squashing changes down to meaningful bits, AND which does not loose the history of review iterations?
Re: Comparing Git Workflows
#5One of the things I hate about the traditional git workflows describe there is that there is no squashing and the history is basically unusable. We have developers where I work that use our repo as a backup, then when things are merged to master, the history is littered with utter garbage commits like the following: "commit this before I get on the plane" "whoops, make this compile" "WTF?" These add no benefit to his…
You could use `git merge --squash` with Feature Branch or Gitflow. But IMHO it's better not to squash.
Re: Comparing Git Workflows
#6One of the things I hate about the traditional git workflows describe there is that there is no squashing and the history is basically unusable. We have developers where I work that use our repo as a backup, then when things are merged to master, the history is littered with utter garbage commits like the following: "commit this before I get on the plane" "whoops, make this compile" "WTF?" These add no benefit to his…
A couple weeks ago GitHub added merge squash as an option for accepting pull requests (via the UI, you could always do it manually). As long as you don't delete the feature branch you'll still have the history of iterations in that branch.
Re: Comparing Git Workflows
#7One of the things I hate about the traditional git workflows describe there is that there is no squashing and the history is basically unusable. We have developers where I work that use our repo as a backup, then when things are merged to master, the history is littered with utter garbage commits like the following: "commit this before I get on the plane" "whoops, make this compile" "WTF?" These add no benefit to his…
I wonder if 'expandable commits' would be useful, where in the full history, a change (with all it's code review fixes, etc) would appear as one commit, but if you wanted to dig deeper, you could 'expand' that commit into all it's gory details of 'draft version before review', 'tried refactoring this part but gave up', etc.
Re: Comparing Git Workflows
#8This article has actually been around for a while. Explains it really great. But one advice from me is that try to choose only what is sufficient to your project and team. No benefit in being overequipped for a simple job.
This, over complicating the git workflow will make people not using it. In my experience the feature branch works for 80% of the projects, gitflow works for bit projects and I guess (no experience there) that the forking will work for open source projects or HUGE code bases.
Re: Comparing Git Workflows
#9One of the things I hate about the traditional git workflows describe there is that there is no squashing and the history is basically unusable. We have developers where I work that use our repo as a backup, then when things are merged to master, the history is littered with utter garbage commits like the following: "commit this before I get on the plane" "whoops, make this compile" "WTF?" These add no benefit to his…
git flow has added a -S option in v0.4.2 which hasn't been released yet https://github.com/nvie/gitflow/issues/14. Should do what you want if it's combined with -k (to keep the feature branch) ?
Re: Comparing Git Workflows
#10One of the things I hate about the traditional git workflows describe there is that there is no squashing and the history is basically unusable. We have developers where I work that use our repo as a backup, then when things are merged to master, the history is littered with utter garbage commits like the following: "commit this before I get on the plane" "whoops, make this compile" "WTF?" These add no benefit to his…
Do you use feature branches, or does everyone work off `master` ? (From your comment it seems like you do)
If you use feature branches, then it might help to
- rebase interactively to clean up/edit/remove commits that are not relevant before merging
- merge into master with the `--no-ff` flag - this forces Git to create _one_ merge commit, even if it is a fast-forward merge
FWIW the two above can be used individually or together. The way I work (and many others I work with) is
- create a feature branch off master
- hack, commit, hack, commit
- rebase interactively to clean up history
- issue PR on Github
- Merge using Github (which under the covers does a `--no-ff` merge so you get ONE merge commit)
Bisecting with this workflow is a bit more coarse grained than if you did a workflow allowing fast-forward merges b/c usually the closest I get is to know that it was a PARTICULAR merge introduced a bug or a regression. That merge commit might have any number of commits that constitute it.
Hope that helps.
[Edit: Formatting]
[Update 1] - If you use the CLI to merge, perhaps alias merge to merge --no-ff so you don't forget?