commits a los repositorios
Me parece súper importante porque así se puede ver si alguien hizo cambios después de las indicaciones o si siguió las reglas que se dieron.
Un commit es una acción en sistemas de control de versiones (como Git) que guarda los cambios realizados en los archivos de un proyecto dentro del repositorio. Es como tomar una “foto” del estado actual del código para poder revisarlo, compartirlo o revertirlo en el futuro.
From one obsessive, insane history editor to another, thanks for posting the question! ;D
annotated tags point to a tag object in the object database. git tag -as -m msg annot cat .git/refs/tags/annot contains the SHA of the annotated tag object: c1d7720e99f9dd1d1c8aee625fd6ce09b3a81fef and then we can get its content with: git cat-file -p c1d7720e99f9dd1d1c8aee625fd6ce09b3a81fef
I would argue that "whole tree" thinking is enhanced by --follow being the default. What I mean is when I want to see the history of the code within a file, I really don't usually care whether the file was renamed or not, I just want to see the history of the code, regardless of renames. So in my opinion it makes sense for --follow to be the default because I don't care about individual files; --follow helps me to ignore individual file renames, which are usually pretty inconsequential.
git update-index --skip-worktree <files>
Relaxo is a transactional database built on top of git.
Relaxo uses the git persistent data structure for storing documents. This data structure exposes a file-system like interface, which stores any kind of data.
A git repository is a development tool, not a distribution mechanism for end users.
If the value of the variable is a relative path
Meaning git config can include relative paths
Use case 1: Delete a ref, useful for soft resetting the first commit
An alternative approach would be to rebase the "top" of the stack, part-3 on top of dev. We could then reset each of the branches to the "correct" commit in the newly-rebased branch, something like this:
Don't think that I just naturally perfectly segment these commits when creating the feature. I heavily rebase and edit the commits before creating a PR.
it is a really good idea to check the status before doing an add .
maybefore, but check mainly AFTER indexing new files !
To recap, I think these are my personal rebase rules I follow:
Recommendations for doing git rebase (see bullet points below annotation)
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 run ./calc.py 14 0 ← example of running git bisect automatically. * If the commit is good, then the command should return 0; * If the commit is bad, then the command should return anything between 1 and 127, inclusive, except 125; * If it is not possible to tell if this commit is good or bad, then it need to be ignored, and the command should return 125.
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.
Git Bisect can be run manually or automatically
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.
6 differen debugging tools
git log -SFoo -- path_containing_change
Excellent command to search in git history of a specific file!
if (!stat(worktree_git_path(wt, "rebase-apply"), &st)) {
if (!stat(worktree_git_path(wt, "rebase-apply/applying"), &st)) {
state->am_in_progress = 1;
if (!stat(worktree_git_path(wt, "rebase-apply/patch"), &st) && !st.st_size)
state->am_empty_patch = 1;
} else {
state->rebase_in_progress = 1;
state->branch = get_branch(wt, "rebase-apply/head-name");
state->onto = get_branch(wt, "rebase-apply/onto");
}
} else if (!stat(worktree_git_path(wt, "rebase-merge"), &st)) {
if (!stat(worktree_git_path(wt, "rebase-merge/interactive"), &st))
state->rebase_interactive_in_progress = 1;
else
state->rebase_in_progress = 1;
state->branch = get_branch(wt, "rebase-merge/head-name");
state->onto = get_branch(wt, "rebase-merge/onto");
} else
return 0;
return 1;
git remote set-head origin -a
Resolved the problem I had where I mistakenly deleted this [local tracking branch]?
ls .git/refs/remotes/origin/HEAD ls: cannot access '.git/refs/remotes/origin/HEAD': No such file or directory
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 diff --staged 命令
在工作一段时间后， 它们的状态可能是未修改，已修改或已放入暂存区
Jetbrains IDE 默认并不会开启暂存区功能，会自动都添加到暂存区
git log --oneline --graph --decorate --all
show commits of git as a tree
To show the last 2 commits use this!
git log --oneline --graph --decorate --all HEAD~2..HEAD
git config --global alias.tree 'log --oneline --graph --decorate --all'
configuration to make a shortcut to show commits of git as a tree
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.
with emacs
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
This is an excellent resource for learing about Git integration with VS Code
Track changes for each screen automatically – like Git for designs.
Codeberg is a collaboration platform providing Git hosting and services for free and open source software, content and projects.
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.”
merge queue - new GitHub feature
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.
Where is the recomendation?
tip
The tip of a branch deserved its own term.
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
git config --global http.proxy http://proxyuser:proxypwd@proxy.server.com:8080
Setting the proxy for Git
git config --global --add http.proxy http://USERNAME:PASSWORD@PROXY_ADDRESS:PROXY_PORT git config --global --add https.proxy http://USERNAME:PASSWORD@PROXY_ADDRESS:PROXY_PORT
Setting the proxy for other tasks
export HTTPS_PROXY=http://USERNAME:PASSWORD@PROXY_ADDRESS:PROXY_PORT
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.
3-way merge
Whenever two or more developers make changes to the same file respectively and later try to fuse the versions, merge conflicts will likely occur.
conflict definition
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:
Examples of Conventional Commits (see the block below)
Conventional Commits – type
Conventional Commits types: - feat - fix - docs - chore - refactor - tests - perf - styles - ci - build - revert
Commity o treści refactor, added XXX czy cr fixes, to smutna i nudna rzeczywistość.
Small Collision Probabilities
How probable is for some git hash-ids (some chars, not the full length) to collide:
for a small project with ~100 commits:
for a big project: with ~10.000 commits:
As confirmed with the vecto repo, with these ipython commands: ```ipython
!git rev-list --all --count 14042 def collissions(k,N): ...: return 1 - e((-k(k-1)/(2N)))
collissions(14042, 16**6) 0.9971938358691735 !git rev-list --all | cut -c -6 | sort | uniq -cd 2 5af40d 2 6a6c62 2 914c24 2 d83979 2 e8060f
collissions(14042, 16**7) 0.3073608000674162 !git rev-list --all | cut -c -7 | sort | uniq -cd 2 e8060f9
collissions(14042, 16**8) 0.022691464724788335 !git rev-list --all | cut -c -8 | sort | uniq -cd <nothing> ```
So the short answer is to pick rebase or merge based on what you want your history to look like.
Quick summary of rebase vs merge
```sparql PREFIX wd: http://www.wikidata.org/entity/ PREFIX gist: https://ontologies.semanticarts.com/gist/ PREFIX dcterms: http://purl.org/dc/terms/
SELECT DISTINCT ?commitTitle ?commitTime ?filename ?textLine WHERE {
?commit a wd:Q20058545 ; # it's a commit gist:hasPart ?part ; dcterms:subject ?commitSubject ; gist:atDateTime ?commitTime .
?commitSubject dcterms:title ?commitTitle .
?part gist:produces ?contiguousLines .
?contiguousLines gist:occursIn ?file ; http://example.com/containedTextContainer ?textContainer .
?file gist:name ?filename . ?textContainer ?line ?textLine .
FILTER(contains(?textLine,"music")) } ```
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
Location where git stash saves files
Git 里面的 origin 到底代表啥意思?
百度、阿里、腾讯之类的大公司用 Git 吗？他们如何管理源代码？
自己虽然有梯子，可以正常访问github页面，但是在发现“git clone”命令速度特别慢，有时还经常卡掉。本文通过设置git 代理，解决被墙问题。
git clone 无法拉取被墙的 repo
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
Trouble shooting git add . issue.
Setting method one for Windows system working with others:
git config --global core.autocrlf true
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).
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
git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main
Probably would be better to use:
git remote set-head origin -a
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
Command to find a zero width no-break space
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.
git
fetch = ^refs/heads/_*
Ignore git branches when fetch from remote.
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]
git ls-tree --name-only @ for current 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.
Documentación Git del comando Git restore
git-restore - Restore working tree files
Aunque dice que restablece working tree files, también restablece el Index (desde HEAD)
GitHub Blog post donde se hace referencia a los nuevos comandos:
Nuevos en la versión 2.23 de Git
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.
git maintenance
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.
git diff-tree -p COMMIT
command to show code change in given commit
git show COMMIT --compact-summary
command to show code change in given commit
git diff <root_commit>^!
command to show code change of one commit: git diff <root_commit>^ 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
Holy god in fuck...
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
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
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)
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
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
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
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.
Commit messages are important
Look at Spring Boot, or any repository managed by Tim Pope.
2 great examples of clean commits: * https://github.com/spring-projects/spring-boot/commits/master * https://github.com/tpope/vim-pathogen/commits/master
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
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).
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
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”.
Remove a file from staging area git rm --cached <filename>.......
Commits are snapshots, not diffs
$ 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://@192.168.2.172:29418/hea_storage_model.git 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://@192.168.2.172:29418/hea_storage_model.git
remote.origin.url=ssh://@ 缺少了 username
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.
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.
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).
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.
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.
In Git you can merge several commits into one with the powerful interactive rebase
"glueing" commits with rebase.
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.
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.
Force push to update the history of the remote repository
Use --force after ammend a pushed commit.
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
Changing the Most Recent Commit
git commit --amend
Visualize the evolution of a file tracked by git.
<figure>
</figure/>
At last a git workflow site that makes sense for the 21st century!
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.
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).
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
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
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
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
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
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:
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
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
4 branching workflows for Git
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
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
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
GIT_PAGER= git diff
Gurantees git diff works in a non-interactive way.
NOTE ABOUT e MANUAL EDITING
how to edit hunks in git reset -p
pbcopy < ~/.ssh/id_ed25519.pub
Adding a new SSH key to your GitHub account