347 Matching Annotations
  1. Nov 2022
    1. 自己虽然有梯子,可以正常访问github页面,但是在发现“git clone”命令速度特别慢,有时还经常卡掉。本文通过设置git 代理,解决被墙问题。

      git clone 无法拉取被墙的 repo

    1. It is handy to manually generate the diagram from times to times using the previously created command: npm run db:diagram:generate. Though, getting the diagram to update itself on its own automatically without a developer interaction would ensure that it the diagram is never obsolete. There are several ways of doing this.You could use a pre-commit git hook or even better simply configure your CI/CD pipeline(s) to run the npm script whenever something gets merged into the main branch 🙂
    1. [Solved] Git: LF will be replaced by CRLF the next time Git touches it’ problem solving and thinking

      Trouble shooting git add . issue.

      Setting method one for Windows system working with others:

      git config --global core.autocrlf true

    1. You can then edit files in that repository and commit and push them like this: cd 0a30d52feeb3ff60f7d8636b0bde296b # Edit files here git commit -m "Edited some files" -a git push
    2. But if you want to be able to make local edits and then push them back, you need to use this recipe instead: git clone git@gist.github.com:0a30d52feeb3ff60f7d8636b0bde296b.git You can find this in the "Embed" menu, as the "Clone via SSH" option.
    3. You can clone them anonymously (read-only) just using their URL: git clone https://gist.github.com/simonw/0a30d52feeb3ff60f7d8636b0bde296b
    1. Changing the second line to: foo.txt text !diff would restore the default unset-ness for diff, while: foo.txt text diff will force diff to be set (both will presumably result in a diff, since Git has presumably not previously been detecting foo.txt as binary).

      comments for tag: undefined vs. null: Technically this is undefined (unset, !diff) vs. true (diff), but it's similar enough that don't need a separate tag just for that.

      annotation meta: may need new tag: undefined/unset vs. null/set

  2. Oct 2022
    1. git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main

      Probably would be better to use:

      git remote set-head origin -a

    2. git config --global init.defaultBranch main
    1. git remote set-head origin -aThe above command will query the remote host for the HEAD upstream and it updates that upstream in the local.
    1. But for all of its features, GitHub implements only a subset of git. For instance, GitHub lacks the default merge strategy of git—the fast-forward merge.
  3. Sep 2022
    1. Rename the existing default branch to the new name (main). The argument -m transfers all commit history to the new branch: git branch -m master main
    1. If we ever moved a file to a different location or renamed it, all its previous history is lost in git log, unless we specifically use git log --follow. I think usually, the expected behavior is that we'd like to see the past history too, not "cut off" after the rename or move, so is there a reason why git log doesn't default to using the --follow flag?
    1. Note: Git 2.6+ (Q3 2015) will propose that in command line: see "Why does git log not default to git log --follow?" Note: Git 2.6.0 has been released and includes this feature. Following path changes in the log command can be enabled by setting the log.follow config option to true as in: git config log.follow true
    1. If you want to replace many blobs, trees or commits that are part of a string of commits, you may just want to create a replacement string of commits and then only replace the commit at the tip of the target string of commits with the commit at the tip of the replacement string of commits.
    1. As of Git 1.6.5, the more flexible git replace has been added, which allows you to replace any object with any other object, and tracks the associations via refs which can be pushed and pulled between repos.
    1. The next step is to graft the two branches together, skipping the two commits which renamed the folder. (Otherwise there will be a weird jump where everything is deleted and recreated.)
  4. Aug 2022
    1. A related technique is git submodules, but they come with annoying caveats (for example people who clone your repository won't clone the submodules unless they call git clone --recursive),
    2. git-subtrac (from the author of the earlier git-subtree) seems to solve some of the problems with git submodules.
    3. # Do this the first time: $ git remote add -f -t master --no-tags gitgit https://github.com/git/git.git $ git subtree add --squash --prefix=third_party/git gitgit/master # In future, you can merge in additional changes as follows: $ git subtree pull --squash --prefix=third_party/git gitgit/master # And you can push changes back upstream as follows: $ git subtree push --prefix=third_party/git gitgit/master # Or possibly (not sure what the difference is): $ git subtree push --squash --prefix=third_party/git gitgit/master
  5. Jul 2022
    1. Documentación Git del comando Git restore

    2. git-restore - Restore working tree files

      Aunque dice que restablece working tree files, también restablece el Index (desde HEAD)

    1. GitHub Blog post donde se hace referencia a los nuevos comandos:

      • Git switch
      • Git restore

      Nuevos en la versión 2.23 de Git

    2. Highlights from Git 2.23
    1. Proceso para clonar una sola rama de un repositorio Git remoto
  6. Jun 2022
    1. Git also has a built-in command (maintenance) to optimize a repository’s data, speeding up commands and reducing disk space. This isn’t enabled by default, so we register it with a schedule for daily and hourly routines.

      git maintenance

    1. Remove the commit from step 2. We will merge ignoring the failure. Remove the commit from the other, check it passes with the other commit now on main. Merge the other. We will trigger builds for the main branch of affected repositories to check if everything is in order. Steps 5-8 should happen continuously (e.g. one after another but within a short timespan) so that we don't leave a broken main around. It is important to triage that build process and revert if necessary.

      It is important to not leave a broken main around.

  7. May 2022
    1. git diff-tree -p COMMIT

      command to show code change in given commit

    2. git show COMMIT --compact-summary

      command to show code change in given commit

    3. git diff <root_commit>^!

      command to show code change of one commit: git diff <root_commit>^ git diff <root_commit>^!

    1. You could also start a new email with the contents of this file, by making x-success use the mailto: scheme with something like working-copy://x-callback-url/read/?repo=my%20repo&path=README.md&x-success=mailto%3A%3Fbody%3D If you need to debug your callbacks, setting x-success=mailto%3A%3Fbody%3D

      Holy god in fuck...

    1. A properly formed Git commit subject line should always be able to complete the following sentence:If applied, this commit will your subject line hereFor example:If applied, this commit will refactor subsystem X for readability

      An example how to always aim for imperative commits

    2. Git itself uses the imperative whenever it creates a commit on your behalf.For example, the default message created when using git merge reads:Merge branch 'myfeature'

      Using imperative mood in subject line of git commits

    3. Commit messages with bodies are not so easy to write with the -m option. You’re better off writing the message in a proper text editor.

      I've tested it on Windows, and in PowerShell or Git Bash it is as simple as:

      ```console git commit -m "Subject line<ENTER>

      body line 1 body line 2"<ENTER> ```

      However, it does not work in CMD.exe (pressing [ENTER] will not move to the next line)

    4. Firstly, not every commit requires both a subject and a body. Sometimes a single line is fine, especially when the change is so simple that no further context is necessary.

      Not every commit requires a body part

    5. Summarize changes in around 50 characters or less More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of the commit and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); various tools like `log`, `shortlog` and `rebase` can get confused if you run the two together. Explain the problem that this commit is solving. Focus on why you are making this change as opposed to how (the code explains that). Are there side effects or other unintuitive consequences of this change? Here's the place to explain them. Further paragraphs come after blank lines. - Bullet points are okay, too - Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here If you use an issue tracker, put references to them at the bottom, like this: Resolves: #123 See also: #456, #789

      Example of a great commit message

    6. Separate subject from body with a blank lineLimit the subject line to 50 charactersCapitalize the subject lineDo not end the subject line with a periodUse the imperative mood in the subject lineWrap the body at 72 charactersUse the body to explain what and why vs. how

      7 rules of great commit messages

    7. What may be a hassle at first soon becomes habit, and eventually a source of pride and productivity for all involved.
    8. Commit messages can do exactly that and as a result, a commit message shows whether a developer is a good collaborator.
    9. A diff will tell you what changed, but only the commit message can properly tell you why.

      Commit messages are important

    10. Look at Spring Boot, or any repository managed by Tim Pope.
  8. Apr 2022
    1. The eagle-eyed among you may notice that there isn't a .git directory in the app-example-2 working tree. Instead, there's a .git file. This file points to the git directory in the original clone, and it means that all your usual git commands work inside the app-example-2 directory, as well as in the original app-example directory.

      The working of git worktree

    2. Anecdotally, I've found IDEs get much less "confused" if you use their built-in support for switching git branches, instead of changing them from the command line and waiting for the IDE to "notice" the changes.
    1. GIT_INDEX_FILE is the path to the index file (non-bare repositories only).

      export GIT_INDEX_FILE=".git/index.linux" if you are working on Linux

      export GIT_INDEX_FILE=".git/index.windows" if you are working on Linux

  9. Mar 2022
    1. Flatpak is built on top of a technology called OSTree, which is influenced by and very similar to the Git version control system. Like Git, OSTree allows versioned data to be tracked and to be distributed between different repositories. However, where Git is designed to track source files, OSTree is designed to track binary files and other large data.
    2. Internally, Flatpak therefore works in a similar way to Git, and many Flatpak concepts are analogous to Git concepts. Like Git, Flatpak uses repositories to store data, and it tracks the differences between versions.
    1. The underlying architecture might be summarized as “git for operating system binaries”.
    1. $ git config --list http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt http.sslbackend=openssl diff.astextplain.textconv=astextplain core.autocrlf=true core.fscache=true core.symlinks=false credential.helper=manager user.name=xxj user.email=hea@exa.com credential.helper=store credential.username=xxxj core.repositoryformatversion=0 core.filemode=false core.bare=false core.logallrefupdates=true core.symlinks=false core.ignorecase=true remote.origin.url=ssh://@ remote.origin.fetch=+refs/heads/:refs/remotes/origin/ branch.master.remote=origin branch.master.merge=refs/heads/master

      此种配置下, git push 出现如下提示:

      fatal: Could not read from remote repository.

      Please make sure you have the correct access rights and the repository exists.



      remote.origin.url=ssh://@ 缺少了 username

  10. Feb 2022
    1. Can't annotate the comments for some reason, so I am copying the below:

      The Jerk talked about getting hit by a bus, etc. I said who cares about code if a guy’s in hospital or there’s a war, we’ve got better things to worry about than a few days of lost code.

      I feel the pain. I do. I understand. I get scared. I want to check in early and often, but source control isn’t your personal unlimited undo. When I look at history I don’t want to see rubbish. I want to see snapshots of working code.

      Don’t hold back, and don’t go dark, but use your f’ing head. It’s far better to locally integrate multiple times per day and merge back after a few days because guess what, no surprises.

    1. You have just told Git to combine all seven commits into the first commit in the list. It's now time to give it a name: your editor pops up again with a default message, made of the names of all the commits you have squashed

      Put the message you like.

    2. mark all the commits as squashable, except the first/older one: it will be used as a starting point

      After git rebase -i HEAD~N or

      git rebase -i [commit-hash] your editor of choice will pop up, showing the list of commits you want to merge and you'll mark a commit as squashable by changing the word pick into squash next to it (or s for brevity, as stated in the comments).

    3. git rebase --interactive [commit-hash]

      Another way, where [commit-hash] is the hash of the commit just before the first one you want to rewrite from. So in my example the command would be.

    4. The first thing to do is to invoke git to start an interactive rebase session

      git rebase --interactive HEAD~N # or -i where N is the number of commits you want to join, starting from the most recent one.

    5. In Git you can merge several commits into one with the powerful interactive rebase

      "glueing" commits with rebase.

    6. It's a handy tool I use quite often; I usually tidy up my working space by grouping together several small intermediate commits into a single lump to push upstream.

      Could be a good practice. During work, I'll commit small chunks of work but when the feature is done they are put together to facilitate code review.

    1. Changing an Older or Multiple Commits

      git rebase -i HEAD~N # N is the number of commits * The command will display the latest X commits in your default text editor; * Move to the lines of the commit message you want to change and replace pick with reword; Save the changes and close the editor; * For each chosen commit, a new text editor window will open; * Change the commit message, save the file, and close the editor; * Use --force in case of pushed commits.

    2. Force push to update the history of the remote repository

      Use --force after ammend a pushed commit.

    3. Generally, you should avoid amending a commit that is already pushed as it may cause issues to people who based their work on this commit. It is a good idea to consult your fellow developers before changing a pushed commit.

      Take care ammending pushed commits

    4. Changing the Most Recent Commit

      git commit --amend

  11. Jan 2022
  12. Dec 2021
    1. At last a git workflow site that makes sense for the 21st century!

    1. it is best to limit the number and scope of branches in your repository. Most implementations suggest that developers commit directly to the main branch or merge changes from their local branches in at least once a day.

      Actually this is the "agile" motto - release early, so no long feature-branches.

  13. Nov 2021
    1. Here are the impressive detailed statistics from their repository as of 2015, for which more recent data is challenging to obtain.

      Interesting statistics (mostly inside diagrams) from 2015 on Google's big [[monorepo]] (which is NOT git).

    1. git ls-files is more than 5 times faster than both fd --no-ignore and find

      git ls-files is the fastest command to find entries in filesystem

    1. The overall flow of Gitflow is: A develop branch is created from main A release branch is created from develop Feature branches are created from develop When a feature is complete it is merged into the develop branch When the release branch is done it is merged into develop and main If an issue in main is detected a hotfix branch is created from main Once the hotfix is complete it is merged to both develop and main

      The overall flow of Gitflow

  14. Oct 2021
    1. Hotfix branches are a lot like release branches and feature branches except they're based on main instead of develop. This is the only branch that should fork directly off of main. As soon as the fix is complete, it should be merged into both main and develop (or the current release branch), and main should be tagged with an updated version number.

      Hotfix branches

    2. Once develop has acquired enough features for a release (or a predetermined release date is approaching), you fork a release branch off of develop. Creating this branch starts the next release cycle, so no new features can be added after this point—only bug fixes, documentation generation, and other release-oriented tasks should go in this branch. Once it's ready to ship, the release branch gets merged into main and tagged with a version number. In addition, it should be merged back into develop, which may have progressed since the release was initiated.

      Release branch

    3. feature branches use develop as their parent branch. When a feature is complete, it gets merged back into develop. Features should never interact directly with main.

      Feature branches should only interact with a develop branch

    4. When using the git-flow extension library, executing git flow init on an existing repo will create the develop branch

      git flow init will create:

      • feature branch
      • release branch
      • hotfix branch
      • support branch
    1. The main condition that needs to be satisfied in order to use OneFlow is that every new production release is based on the previous release. The most difference between One Flow and Git Flow that it not has develop branch.

      Main difference between OneFlow and Git Flow

    2. The most difference between GitLab Flow and GitHub Flow are the environment branches having in GitLab Flow (e.g. staging and production) because there will be a project that isn’t able to deploy to production every time you merge a feature branch

      Main difference between GitLab Flow and GitHub Flow

    3. 4 branching workflows for Git
      1. Git Flow
      2. GitHub Flow
      3. GitLab Flow
      4. One Flow
    4. release-* — release branches support preparation of a new production release. They allow many minor bug to be fixed and preparation of meta-data for a release. May branch off from develop and must merge into master anddevelop.

      release branches

    5. hotfix-* — hotfix branches are necessary to act immediately upon an undesired status of master. May branch off from master and must merge into master anddevelop.

      hotfix branches

    6. feature-* — feature branches are used to develop new features for the upcoming releases. May branch off from develop and must merge into develop.

      feature branches

  15. Sep 2021
  16. Aug 2021
    1. This one implements the behavior of git checkout when running it only against a branch name. So you can use it to switch between branches or commits.

      git switch <branch_name>

    2. When you provide just a branch or commit as an argument for git checkout, then it will change all your files to their state in the corresponding revision, but if you also specify a filename, it will only change the state of that file to match the specified revision.

      git checkout has a 2nd option that most of us skipped

    3. if you are in the develop branch and want to change the test.txt file to be the version from the main branch, you can do it like this

      git chekout main -- test.txt

  17. Jul 2021
    1. rebase is really nothing more than a merge (or a series of merges) that deliberately forgets one of the parents of each merge step.

      What rebase really is

  18. Jun 2021
    1. To try and make things a little bit more secure, Githooks checks if any new hooks were added we haven't run before, or if any of the existing ones have changed
    2. git diff --cached --diff-filter=ACMR --name-only
    1. To address this problem, I offer git undo, part of the git-branchless suite of tools. To my knowledge, this is the most capable undo tool currently available for Git. For example, it can undo bad merges and rebases with ease, and there are even some rare operations that git undo can undo which can’t be undone with git reflog.

      You can use git undo through git-brancheless. There's also GitUp, but only for macOS

    1. From pretty format documentation: '%w([<w>[,<i1>[,<i2>]]])': switch line wrapping, like the -w option of git-shortlog[1]. And from shortlog: -w[<width>[,<indent1>[,<indent2>]]] Linewrap the output by wrapping each line at width. The first line of each entry is indented by indent1 spaces, and the second and subsequent lines are indented by indent2 spaces. width, indent1, and indent2 default to 76, 6 and 9 respectively. If width is 0 (zero) then indent the lines of the output without wrapping them.
    1. There are many projects that does not use the master branch as default. For example, Next.js uses the canary branch, the npm CLI and many more other projects uses stuff like prod, production, dev, develop, release, beta, head.
    2. I'm not sure if there's any cost in terms of contributing either, especially when by design git can have any branch as default, and will not hinder your experience when you use something other than master.

      git is neutral/unbiased/agnostic about default branch name by design

      And that is a good thing

    3. The primary branch in git can have any name by design.
    4. In the context of git, the word "master" is not used in the same way as "master/slave". I've never known about branches referred to as "slaves" or anything similar.
  19. May 2021
    1. Normally, git diff looks for non-printable characters in the files and if it looks like the file is likely to be a binary file, it refuses to show the difference. The rationale for that is binary file diffs are not likely to be human readable and will probably mess up your terminal if displayed. However, you can instruct git diff to always treat files as text using the --text option. You can specify this for one diff command: git diff --text HEAD HEAD^ file.txt You can make Git always use this option by setting up a .gitattributes file that contains: file.txt diff
    1. If you insist on using Git and insist on tracking many large files in version control, you should definitely consider LFS. (Although, if you are a heavy user of large files in version control, I would consider Plastic SCM instead, as they seem to have the most mature solution for large files handling.)

      When the usage of Git LFS makes sense

    2. In Mercurial, use of LFS is a dynamic feature that server/repo operators can choose to enable or disable whenever they want. When the Mercurial server sends file content to a client, presence of external/LFS storage is a flag set on that file revision. Essentially, the flag says the data you are receiving is an LFS record, not the file content itself and the client knows how to resolve that record into content.

      Generally, Merculiar handles LFS slightly better than Git

    3. If you adopt LFS today, you are committing to a) running an LFS server forever b) incurring a history rewrite in the future in order to remove LFS from your repo, or c) ceasing to provide an LFS server and locking out people from using older Git commits.

      Disadvantages of using Git LFS

    1. :/<text>, e.g. :/fix nasty bug A colon, followed by a slash, followed by a text, names a commit whose commit message matches the specified regular expression.

      :/<text> - searching git commits using their text instead of hash, e.g. :/fix nasty bug

    1. git worktree add <path> automatically creates a new branch whose name is the final component of <path>, which is convenient if you plan to work on a new topic. For instance, git worktree add ../hotfix creates new branch hotfix and checks it out at path ../hotfix.

      The simple idea of git-worktree to manage multiple working trees without stashing

    1. Preserving history; we often find ourselves using the git blame tool to discover why a certain change was made.
    2. Preserving commit hashes; we use commit hashes in binary names and our issue tracker; ideally, these references remain intact.
    1. New changes to the old repositories can be imported into the monorepo and merged in. For example, in the above example, say repository one had a branch my_branch which continued to be developed after the migration. To pull those changes in: