I’m guessing you don’t mean commits that actually bring updates from a different branch in? I’m responsible for a bunch of commits that catch my feature branch up to main and a couple that bring my branches into main.
If we were working on the same project, what would you want to see for those? This is hosted on a private gh repo, but it’s a small shop and we were working on a tight deadline for an MVP release and were not using PRs for the stuff I was working on.
The boss (co-owner of the business) is the Sr dev on the project and until recently was the only sr dev in the whole shop. I actually don’t think he has experience with using git in a team context.
One of my other tasks is working on internal docs (which didn’t exist before I joined the team) that would include git best practices for branching strategies and commit messages, so I’m interested in what folks who have more experience than I do would like to see as I try to nudge the team practices.
Great question. I’m not the one you asked, but I can answer.
Yes, merge commits, though they get useful work done, cause challenges later. If you’re using GitHub you can actually disable the ‘merge commit’ pattern in the repository settings, under ‘branch protections’, and you’ll have a much nicer time moving code between branches in the future.
Since you’re working on patterns, if you’re using GitHub, here’s my best tip - it’s related but will also cause some other nice outcomes.
If you’re using GitHub, to get a much better branching experience, you can turn on branch protections on ‘main’ and specifically turn on ‘require linear history’. This will let GitHub know that you prioritize the quality of the history in ‘main’ over that of all other branches.
Related: If your team keeps a ‘develop’ branch, you’ll need to get rid of it at the same time as making this change. Using a ‘develop’ branch is not compatible with this setup. Code that used to merge to ‘develop’ should now merge to ‘main’ and git tags should be what indicates code is ready for production.
With these settings GitHub will nudge your team towards squashing and rebasing when merging, and operations to pull other people’s code into your branch will get dramatically easier. (Edit: You’ll start to see the keyword ‘fast-forward’ a lot more often, which is great.)
If you’re not using GitHub, you can still look for tools and setups to “require linear history” to get the same benefits.
You’d hope so - and if one does, I have no concerns about whatever one chooses to do in the privacy of their own branch - but some people insist on directly merging to main (preserving two parallel histories), rather than squashing their change into a single commit. Savages ;)
I’m guessing you don’t mean commits that actually bring updates from a different branch in?
Yep, in part, I do. Say I’m working on feature which branched off from main. Time’s gone by, and there have been commits on both feature and main. I want to integrate (not I am very carefully not using the word merge!) the commits that exist on main into my feature branch so that I can use them. You can make a merge commit to do so, but there’s no point in doing so - a git pull --rebase will have the same effect (“My local branch contains both the changes from the upstream, then the changes that I myself have made ‘on top of’ them”) without requiring a merge commit.
But really, what one chooses to do in the privacy of one’s own branch is no concern of mine. I can advise and opine, but it doesn’t really affect me. What does affect me is when people insist on merging intomain. That really irritates me, because it results in horrible tangled non-linear history like this. Ideally, the history of main should be a linear history of changes which each follow on from one another, and a commit and a change are in 1:1 correspondance:
the question “which commit is the parent of this one?” should have one answer, not potentially-multiple.
there is no value in seeing the development history of the change (all the random “bugfix”, “maybe this will work lol”, “correct typos” commits) in the history of main. They are maybe useful in the PR, but the change as seen in main should only contain the finished polished-up result.
GitHub’s confusingly named “Squash And Merge” (it’s a “merge” in the git merge sense, but it doesn’t create a Merge Commit! “Squash and commit” or “Squash and push” would be more accurate) results, I think, in the outcome - a single commit on the HEAD of the target branch containing the result of the change. And if that happens, then I don’t care if you’ve been pulling in changes from main to feature via Merge commits or (correctly IMO) via git pull --rebase - because, whatever you’ve done, your development history will be (correctly) invisible from the commit on main.
(I say “I think” there because I’ve only recently started using GitHub in a professional capacity. For the decade prior to this I worked at a Big Tech company which had its own in-house Code Review tools which - probably not by coincidence - aligned a lot more closely with how I think about how Git history should be structured)
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
I’m guessing you don’t mean commits that actually bring updates from a different branch in? I’m responsible for a bunch of commits that catch my feature branch up to main and a couple that bring my branches into main.
If we were working on the same project, what would you want to see for those? This is hosted on a private gh repo, but it’s a small shop and we were working on a tight deadline for an MVP release and were not using PRs for the stuff I was working on.
The boss (co-owner of the business) is the Sr dev on the project and until recently was the only sr dev in the whole shop. I actually don’t think he has experience with using git in a team context.
One of my other tasks is working on internal docs (which didn’t exist before I joined the team) that would include git best practices for branching strategies and commit messages, so I’m interested in what folks who have more experience than I do would like to see as I try to nudge the team practices.
No, fast-forward merges only
Great question. I’m not the one you asked, but I can answer.
Yes, merge commits, though they get useful work done, cause challenges later. If you’re using GitHub you can actually disable the ‘merge commit’ pattern in the repository settings, under ‘branch protections’, and you’ll have a much nicer time moving code between branches in the future.
Since you’re working on patterns, if you’re using GitHub, here’s my best tip - it’s related but will also cause some other nice outcomes.
If you’re using GitHub, to get a much better branching experience, you can turn on branch protections on ‘main’ and specifically turn on ‘require linear history’. This will let GitHub know that you prioritize the quality of the history in ‘main’ over that of all other branches.
Related: If your team keeps a ‘develop’ branch, you’ll need to get rid of it at the same time as making this change. Using a ‘develop’ branch is not compatible with this setup. Code that used to merge to ‘develop’ should now merge to ‘main’ and git tags should be what indicates code is ready for production.
With these settings GitHub will nudge your team towards squashing and rebasing when merging, and operations to pull other people’s code into your branch will get dramatically easier. (Edit: You’ll start to see the keyword ‘fast-forward’ a lot more often, which is great.)
If you’re not using GitHub, you can still look for tools and setups to “require linear history” to get the same benefits.
This Is The Way.
You’d be squashing those when you merge back down into main anyway, no?
You’d hope so - and if one does, I have no concerns about whatever one chooses to do in the privacy of their own branch - but some people insist on directly merging to
main(preserving two parallel histories), rather than squashing their change into a single commit. Savages ;)Yep, in part, I do. Say I’m working on
featurewhich branched off frommain. Time’s gone by, and there have been commits on bothfeatureandmain. I want to integrate (not I am very carefully not using the wordmerge!) the commits that exist onmaininto myfeaturebranch so that I can use them. You can make a merge commit to do so, but there’s no point in doing so - agit pull --rebasewill have the same effect (“My local branch contains both the changes from the upstream, then the changes that I myself have made ‘on top of’ them”) without requiring a merge commit.But really, what one chooses to do in the privacy of one’s own branch is no concern of mine. I can advise and opine, but it doesn’t really affect me. What does affect me is when people insist on merging into
main. That really irritates me, because it results in horrible tangled non-linear history like this. Ideally, the history ofmainshould be a linear history of changes which each follow on from one another, and a commit and a change are in 1:1 correspondance:main. They are maybe useful in the PR, but the change as seen inmainshould only contain the finished polished-up result.GitHub’s confusingly named “Squash And Merge” (it’s a “merge” in the
git mergesense, but it doesn’t create a Merge Commit! “Squash and commit” or “Squash and push” would be more accurate) results, I think, in the outcome - a single commit on theHEADof the target branch containing the result of the change. And if that happens, then I don’t care if you’ve been pulling in changes frommaintofeaturevia Merge commits or (correctly IMO) viagit pull --rebase- because, whatever you’ve done, your development history will be (correctly) invisible from the commit onmain.(I say “I think” there because I’ve only recently started using GitHub in a professional capacity. For the decade prior to this I worked at a Big Tech company which had its own in-house Code Review tools which - probably not by coincidence - aligned a lot more closely with how I think about how Git history should be structured)