To recap, I think these are my personal rebase rules I follow:

However, as we want to do perform the bisection automatically using as criterion ./calc.py 14 0, we run git bisect run ./calc.py 14 0

Git Bisect! It allows us to find the commit that broke something. Given a “good” commit (a commit that is not broken, created before the introduction of the bug), and a “bad” commit (a commit that certainly is broken), Git will perform a binary search until the broken commit is found.

What are the tools that comes on your mind when someone say “debug”? Let me guess: a memory leak detector (e.g. Valgrind); a profiler (e.g. GNU gprof); a function that stops your program and gives you a REPL (e.g. Python’s breakpoint and Ruby’s byebug); something that we call a “debugger” (like GDB, or something similar embedded on the IDEs); or even our old friend, the print function. So, in this text I’ll try to convince you to add Git to your debug toolbelt.

git log -SFoo -- path_containing_change

git remote set-head origin -a

You should never rely on the presence or contents of anything under the .git directory. That's git's territory, not yours or the build system's. Use it's plumbing commands to get access to the information you need, rather than trying to read files directly. Git provides no guarantee about the location or contents of any of those files as far as I'm aware.

Note that UTF-8 characters can be used in branch names:

>, ==> and -> are valid branch names

Pull requests are quite welcome, and should target the next branch.

diff-so-fancy strives to make your diffs human readable instead of machine readable

The increment-after-release model makes sense for branching too. Suppose you have a mainline development branch, and you create maintenance branches for releases. The moment you create your release branch, your development branch is no longer linked to that release's version number. The development branch contains code that is part of the next release, so the version should reflect that.

git diff 本身只显示尚未暂存的改动，而不是自上次提交以来所做的所有改动。

在工作一段时间后， 它们的状态可能是未修改，已修改或已放入暂存区

git log --oneline --graph --decorate --all

git config --global alias.tree 'log --oneline --graph --decorate --all'

Getting Started git-cliff can generate changelog files from the Git history by utilizing conventional commits as well as regex-powered custom parsers. The changelog template can be customized with a configuration file to match the desired format.

Visual Studio Code has integrated source control management (SCM) and includes Git support out-of-the-box. Many other source control providers are available through extensions on the VS Code Marketplace

Track changes for each screen automatically – like Git for designs.

git branch --delete --remotes origin/X git branch -dr origin/X # Shorter

Annoyingly, git fetch --depth=<N> won't pick up new tags

git fetch --depth 1 origin <sha1>

merge queue prevents semantic merge conflicts by automating the rebase process during merge, and ensuring that the trunk branch stays “green.”

amend

Changes not staged for commit

Changes to be committed:

git add

$ git init

Although 4-part numbers are supported, Microsoft no longer recommends this format.

tip

First, although not directly relevant to the answer, it's important to remember that Git does not have remote tags. Git just has tags.

git config --global --unset http.proxy

Setting the proxy for Git

Setting the proxy for other tasks

Instead of manually backtracking what changes each developer made, three-way merge does just that for us! This is because modern version control systems, such as Git, can automatically find what's known as the "nearest common ancestor", aka base revision (or merge-base). It is called "3-way" since it uses three revisions to produce a final merged version.

Whenever two or more developers make changes to the same file respectively and later try to fuse the versions, merge conflicts will likely occur.

git

In recent git versions, git restore is supposed to be a "better" way to revert undesired local changes than the overloaded checkout. Great, that sounds reasonable - a nice simple purpose-built tool for a common operation.

Kilka przykładów z wykorzystujących Conventional Commits:

Conventional Commits – type

Commity o treści refactor, added XXX czy cr fixes, to smutna i nudna rzeczywistość.

Small Collision Probabilities

So the short answer is to pick rebase or merge based on what you want your history to look like.

In very large code bases, it is likely impossible to make a change to a fundamental API and get it code reviewed by every affected team before merge conflicts force the process to start over again.

Result of lots of searching on net is that pre-checkout hook in git is not implemented yet. The reason can be: There is no practical use. I do have a case It can be achieved by any other means. Please tell me how? Its too difficult to implement. I don't think this is a valid reason

In ~/.githelpers, define a bash function:

For ordinary commits, it's trivially obvious what to compare: compare this commit's snapshot to the previous (i.e., parent) commit's snapshot. So that is what git show does (and git log -p too): it runs a git diff from the parent commit, to this commit. Merge commits don't have just one parent commit, though. They have two parents.1 This is what makes them "merge commits" in the first place: the definition of a merge commit is a commit with at least two parents.

Your changes preserved through git stash are saved in your project’s .git directory, usually, the path is /.git/refs/stash

Git 里面的 origin 到底代表啥意思?

百度、阿里、腾讯之类的大公司用 Git 吗？他们如何管理源代码？

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

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 🙂

[Solved] Git: LF will be replaced by CRLF the next time Git touches it’ problem solving and thinking

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

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.

You can clone them anonymously (read-only) just using their URL: git clone https://gist.github.com/simonw/0a30d52feeb3ff60f7d8636b0bde296b

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).

git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main

git config --global init.defaultBranch main

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.

git show | cat -A

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.

fetch = ^refs/heads/_*

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

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?

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

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.

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.

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.)

git ls-tree --name-only [branch]

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),

git-subtrac (from the author of the earlier git-subtree) seems to solve some of the problems with git submodules.

# 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

The main problem here is that the problem itself is a little bit poorly defined.

git-restore - Restore working tree files

Highlights from Git 2.23

Proceso para clonar una sola rama de un repositorio Git remoto

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.

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.

git diff-tree -p COMMIT

git show COMMIT --compact-summary

git diff <root_commit>^!

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

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

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'

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.

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.

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

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

What may be a hassle at first soon becomes habit, and eventually a source of pride and productivity for all involved.

Commit messages can do exactly that and as a result, a commit message shows whether a developer is a good collaborator.

A diff will tell you what changed, but only the commit message can properly tell you why.

Look at Spring Boot, or any repository managed by Tim Pope.

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.

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.

GIT_INDEX_FILE is the path to the index file (non-bare repositories only).

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.

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.

The underlying architecture might be summarized as “git for operating system binaries”.

Commits are snapshots, not diffs