GIT-REINTEGRATE(1)

πŸ’– GIT-REINTEGRATE(1) πŸ’–

okay bestie, gather round, because this is the git-reintegrate page from the Git manual and it is genuinely one of the most useful little helpers ever. it's a tool for managing integration branches in Git, and yes we're gonna go through every single flag together, no skipping, periodt.


✨ SYNOPSIS ✨

git reintegrate --create <name> [<base>]
git-reintegrate --generate <name> [<base>]
git-reintegrate --add=<name>
git-reintegrate (--edit | --rebuild | --apply | --cat | --status) [<name>]
git reintegrate (--continue | --abort)
git-reintegrate --list

🌸 DESCRIPTION 🌸

so this tool is a little helper that makes managing integration branches in Git actually easy. how does it do it? by letting you specify a list of merges to be applied on top of a base branch. and the cute part: each one of those merges can have a description attached, and that description becomes the merge commit message. iconic behaviour honestly.

this instruction sheet can be autogenerated, and you can also modify it in all sorts of ways from the command line, or just manually edit it like a normal person. your choice, no judgement 🫢

and then finally β€” the payoff β€” the integration branch can be rebuilt, and any previous conflict resolutions get reused for free thanks to git rerere. chef's kiss. πŸ’…


πŸ‘‘ OPTIONS πŸ‘‘

  • --create β€” makes you a brand new integration branch. if you don't specify a base, master is assumed. default behaviour, we love a default.
  • --generate β€” generates the instruction sheet based on an existing integration branch. it parses the messages of each merge commit to build up the instructions. those messages should be in the standard form Merge branch 'name' (or remote branch, if that's your situation). and again, if no base is specified, master is assumed.
  • --[no-]rebuild β€” rebuilds the integration branch. that's it. that's the whole thing.
  • --edit β€” opens up the instruction sheet for editing.
  • --cat β€” prints the instruction sheet. cat behaviour, truly.
  • --status β€” prints the status of the integration branch.
  • --add=<branch> β€” appends a line merge <branch> to the instruction list, which means that branch gets included in the integration branch the next time it's rebuilt. you can specify this one multiple times to add multiple branches, so stack 'em up bestie.
  • --continue β€” restarts the rebuild process after you've resolved a merge conflict. the "okay I fixed it, we move" button.
  • --abort β€” aborts the rebuild operation entirely. no notes, we're out.
  • --[no-]autocontinue β€” continues automatically if the rerere mechanism manages to resolve all the conflicts during a merge. the lazy-girl dream, fr fr.
  • --list β€” lists all the current integration branches.
  • --delete β€” deletes an integration branch. lowkey important detail: it does not delete the branch itself, only the integration information. so the branch survives, the bookkeeping doesn't. πŸ™ˆ
  • --apply β€” applies the instruction sheet of the integration branch on top of the current branch. and if a branch you're supposed to merge is already completely merged into the current branch, it gets skipped. efficient queen.
⚠️ real talk: if --continue or --abort are specified, then no other options may be given. that's the rule. don't fight it.

πŸŽ€ CONFIGURATION πŸŽ€

  • integration.autocontinue β€” sets the default for the --autocontinue option.
  • integration.autorebuild β€” automatically rebuilds the integration branch after creating or editing it, if --no-rebuild is not specified.

πŸ¦‹ FORMAT OF INSTRUCTIONS πŸ¦‹

okay so the instruction sheet is made up of a series of instructions that all begin in column zero. each of those instructions may then be followed by indented comments. here's everything that's supported:

  • base <ref> β€” resets the state of the integration branch to the specified revision. this should always be the first instruction in the instruction sheet, and it should appear only at the top of the instruction sheet. main character energy, first in line, no exceptions.
  • merge <ref> [<options>] β€” merges the specified ref into the integration branch. any comments that follow the instruction get appended to the merge commit's commit message. and if any options are given after the ref (on the same line, bestie, same line), those get passed straight to git merge. super handy if you need to specify an alternative merge strategy for a branch.
  • fixup <ref> β€” picks up an existing commit to be applied on top of a merge as a fixup.
  • commit β€” adds an empty commit with the specified message, mostly so you can use it as a comment.
  • pause β€” pauses the rebuild process so you can go do certain actions manually. for example: fixing a wrong conflict resolution. we all make mistakes, it's fine, this is your moment.
  • . <args...> β€” ignores this command and its description. this one's for removing a branch from the integration branch without needing to delete it and its description from the instruction sheet. sneaky, clever, we stan.

⭐ Example ⭐

base master

merge my-experimental-feature

  I think this is a good idea, but want to dogfood it before I
  decide whether to submit it upstream.

merge my-site-specific-changes

  Some changes to suit my environment.  DO NOT SUBMIT THESE.

and that's the whole page, bestie!! every flag, every config key, every instruction, all accounted for. no cap. 🧚

this was GIT-REINTEGRATE(1) from the Git manual, dated 01/17/2021. stay integrated, stay slaying. πŸ’œπŸŒˆβœ¨
πŸ“¦ where this page comes from