Difference between revisions of "Git notes"

From Wiki at Neela Nurseries
Jump to: navigation, search
m (→‎^ Git Rebase: - amend note on overcoming "cannot fast forward" git pull error.)
(→‎^ Git Branching: minor formatting.)
 
(7 intermediate revisions by the same user not shown)
Line 21: Line 21:
 
*  [https://docs.zephyrproject.org/latest/contribute/contributor_expectations.html#contributor-expectations Zephyr Contributor Expectations] good git practices highlighted in Zephyr RTOS Contributor Expectations document
 
*  [https://docs.zephyrproject.org/latest/contribute/contributor_expectations.html#contributor-expectations Zephyr Contributor Expectations] good git practices highlighted in Zephyr RTOS Contributor Expectations document
 
</ul>
 
</ul>
 +
 +
There are many books written about git and its use and common workflows.  As of 2024 Q4, local author notes the following book that's available for free online and linked from https://www.git-scm.com/book/en/v2.  Written by Scott Chacon and Ben Straub, a brief history of git is provided in the chapter linked by:
 +
 +
<ul>
 +
*  https://www.git-scm.com/book/en/v2/Getting-Started-A-Short-History-of-Git
 +
</ul>
 +
 +
More book references to be added here soon.
  
 
<!-- comment -->
 
<!-- comment -->
Line 172: Line 180:
  
 
   $ for name in branch1 branch2 branch3; do git checkout ${name}; git log | head -n 3; done
 
   $ for name in branch1 branch2 branch3; do git checkout ${name}; git log | head -n 3; done
 +
 +
 +
To search for most recently edited branches:
 +
 +
  $ git branch --sort=-committerdate
 +
 +
 
<!-- odne komentar -->
 
<!-- odne komentar -->
  
Line 183: Line 198:
 
   $ git pull origin &lt;branch&gt;
 
   $ git pull origin &lt;branch&gt;
  
 +
Some git client versions do not by default report by how many commits local branch and corresponding remote branch differ, e.g. Git for Windows bash client does not provide this difference information.  To invoke `git rev-list ...` provides an alternate way to  see commit history differences between local and remote branches.
 +
 +
*  https://stackoverflow.com/questions/10420575/see-exact-divergence-commits-between-local-and-remote-git-repo
  
 
<!-- odne komentar -->
 
<!-- odne komentar -->
−
<!-- comment -->
 
  
 
== [[#top|^]] Git Inner Workings ==
 
== [[#top|^]] Git Inner Workings ==
Line 229: Line 246:
 
   *  https://stackoverflow.com/questions/20568971/git-pull-keeps-telling-me-to-stash-local-changes-before-pulling
 
   *  https://stackoverflow.com/questions/20568971/git-pull-keeps-telling-me-to-stash-local-changes-before-pulling
  
−
<i>Excerpt from above link:</i>
+
Excerpt from above link:<br />
−
<pre>
+
<ul>
−
It sounds like your local branch does not have all of the changes on origin.
+
<i>
 +
It sounds like your local branch does not have all of the changes on origin.<br />
  
−
Firstly, stash your changes
+
Firstly, stash your changes<br />
  
−
git stash
+
git stash<br />
  
−
Then, pull in the changes from origin.
+
Then, pull in the changes from origin.<br />
  
−
git fetch origin && git rebase origin/(branch name)
+
git fetch origin && git rebase origin/(branch name)<br />
  
−
Next, add the stash back in to your working directory:
+
Next, add the stash back in to your working directory:<br />
  
−
git stash pop
+
git stash pop<br />
−
</pre>
+
</i>
 +
</ul>
  
  
Line 371: Line 390:
 
*  https://stackoverflow.com/questions/29914052/how-to-git-rebase-a-branch-with-the-onto-command
 
*  https://stackoverflow.com/questions/29914052/how-to-git-rebase-a-branch-with-the-onto-command
 
</ul>
 
</ul>
 +
 +
<!-- git rebase --onto Stackoverflow answer by Enrico Campidoglio.  Answer noted here in case Stackoverflow site ever becomes not available:
 +
750
 +
tl;dr
 +
 +
The correct syntax to rebase B on top of A using git rebase --onto in your case is:
 +
 +
git checkout B
 +
git rebase --onto A B^
 +
 +
or rebase B on top of A starting from the commit that is the parent of B referenced with B^ or B~1.
 +
 +
If you're interested in the difference between git rebase <branch> and git rebase --onto <branch> read on.
 +
The Quick: git rebase
 +
 +
git rebase <branch> is going to rebase the branch you currently have checked out, referenced by HEAD, on top of the latest commit that is reachable from <branch> but not from HEAD.
 +
This is the most common case of rebasing and arguably the one that requires less planning up front.
 +
 +
          Before                          After
 +
    A---B---C---F---G (branch)        A---B---C---F---G (branch)
 +
            \                                        \
 +
              D---E (HEAD)                              D---E (HEAD)
 +
 +
In this example, F and G are commits that are reachable from branch but not from HEAD. Saying git rebase branch will take D, that is the first commit after the branching point, and rebase it (i.e. change its parent) on top of the latest commit reachable from branch but not from HEAD, that is G.
 +
The Precise: git rebase --onto with 2 arguments
 +
 +
git rebase --onto allows you to rebase starting from a specific commit. It grants you exact control over what is being rebased and where. This is for scenarios where you need to be precise.
 +
 +
For example, let's imagine that we need to rebase HEAD precisely on top of F starting from E. We're only interested in bringing F into our working branch while, at the same time, we don't want to keep D because it contains some incompatible changes.
 +
 +
          Before                          After
 +
    A---B---C---F---G (branch)        A---B---C---F---G (branch)
 +
            \                                    \
 +
              D---E---H---I (HEAD)                  E---H---I (HEAD)
 +
 +
In this case, we would say git rebase --onto F D. This means:
 +
 +
    Rebase the commit reachable from HEAD whose parent is D on top of F.
 +
 +
In other words, change the parent of E from D to F. The syntax of git rebase --onto is then git rebase --onto <newparent> <oldparent>.
 +
 +
Another scenario where this comes in handy is when you want to quickly remove some commits from the current branch without having to do an interactive rebase:
 +
 +
          Before                      After
 +
    A---B---C---E---F (HEAD)        A---B---F (HEAD)
 +
 +
In this example, in order to remove C and E from the sequence you would say git rebase --onto B E, or rebase HEAD on top of B where the old parent was E.
 +
The Surgeon: git rebase --onto with 3 arguments
 +
 +
git rebase --onto can go one step further in terms of precision. In fact, it allows you to rebase an arbitrary range of commits on top of another one.
 +
 +
Here's an example:
 +
 +
          Before                                    After
 +
    A---B---C---F---G (branch)                A---B---C---F---G (branch)
 +
            \                                            \
 +
              D---E---H---I (HEAD)                          E---H (HEAD)
 +
 +
In this case, we want to rebase the exact range E---H on top of F, ignoring where HEAD is currently pointing to. We can do that by saying git rebase --onto F D H, which means:
 +
 +
    Rebase the range of commits whose parent is D up to and including H on top of F.
 +
 +
The syntax of git rebase --onto with a range of commits then becomes git rebase --onto <newparent> <oldparent> <until>. The trick here is remembering that the commit referenced by <until> is included in the range and will become the new HEAD after the rebase is complete.
 +
Share
 +
Improve this answer
 +
Follow
 +
edited Oct 31, 2023 at 8:18
 +
answered Apr 28, 2015 at 10:05
 +
 +
-->
  
  
Line 450: Line 539:
 
$ git stash list --all                        # . . . list stash entries for all branches of present local repository
 
$ git stash list --all                        # . . . list stash entries for all branches of present local repository
 
</pre>
 
</pre>
 +
 +
"Use of Git stash should be the exception and not the rule." - Cameron McKenzie, Editor In Chief, TechTarget
 +
 +
*  https://www.theserverside.com/blog/Coffee-Talk-Java-News-Stories-and-Opinions/How-to-list-and-show-the-git-stash-history
 +
 +
$ git stash show
 +
 +
$ git stash show -p
 +
 +
See also details on meanings and uses of:
 +
 +
$ git stash pop
 +
 +
$ git stash apply
 +
 +
$ git stash drop
  
 
<!-- odne komentar -->
 
<!-- odne komentar -->
Line 477: Line 582:
  
 
*  https://www.atlassian.com/git/tutorials/git-log
 
*  https://www.atlassian.com/git/tutorials/git-log
 +
 +
To prune deleted remote branches from local git log:
 +
 +
  $ git remote prune origin
  
 
<!-- comentario -->
 
<!-- comentario -->

Latest revision as of 13:15, 5 November 2024

-- 2017-12-04 Monday - somvaar - सोमवार--
Git Notes


^ OVERVIEW - अवलोकन

Following article / document collection of notes on version control software named git. To learn git is not a gentle or short learning curve. This said, there are some key concepts worth mentioning at the beginning of a git learning journey. Some of these concepts include:

There are many books written about git and its use and common workflows. As of 2024 Q4, local author notes the following book that's available for free online and linked from https://www.git-scm.com/book/en/v2. Written by Scott Chacon and Ben Straub, a brief history of git is provided in the chapter linked by:

More book references to be added here soon.


^ Common Commands - सामान्य आदेश

This section is meant to be first a collection of references to external articles which summarize and or present common, frequently used git commands.

Basic git commands:

2020-05-06

Atlassian article on Git's edit/stage/commit pattern of use (Invoke `git add` to stage local file changes.):

Setting up ssh key pairs for secure authentication:

Why are my local changes getting lost? Git commit-and-push-sequence not sufficient to transfer file changes to given git repository . . .

Git references found while answering specific git task questions: 

  $ git diff HEAD .

2022-01-10 Commands in `git` to rename local and remote branch:

ejemplo - board `anda-m`: 

  1  2003  git checkout andam-board-bring-up
  2  2004  git branch -m anda-m-board-bring-up
  3  2005  git branch
  4  2006  git push origin -u anda-m-board-bring-up
  5  2007  git push origin --delete andam-board-bring-up
  6  2008  history

Markdown and .md file formatting at Github

Git and Working with Remote Repositories

Release tag creation and naming in Git


^ Git Commit Messages

Git Conventional Commits document, to aid in meaningful and searchable git commit messages. Link to standard here:

Git conventional commit messages have colon separated descriptors, the first of which are most standardized and narrow in count. These descriptors include:

  • feat . . . feature
  • fix
  • "BREAKING CHANGE"

Some additional identifiers for types of code work committed in git tracked projects include:

  • build
  • chore
  • ci . . . Continuous Improvement
  • docs
  • style
  • refactor
  • revert . . . when a commit reverts a previous commit
  • perf . . . ??? performance enhancement ???
  • test

Other commit note descriptors permitted as per the Angular Convention.


^ Git Command Examples

This section a collection of locally used commands, with some comment on the situations around and benefits of their use.

^ git querying commands

On the local work station, to see from which remote git repository a working copy comes: 

 $ git remote -v

A git invocation to perform pattern matching like `grep`: 

 $ git -C ../modules/hal/nxp/mcux/mcux-sdk grep -nC3 'FLASH_Init'

Within a git repository a developer may identify the full path to the repo or project root by issuing command: 

 $ git rev-parse --show-toplevel


^ git log related commands

A short form summary of commit messages with just the first line of each shown: 

 $ git log --oneline

An `ncurses` like character graphic tree representation of a repository's commit history: 

 $ git log --oneline --graph --all

Capture given git log to text file: 

 $ git --no-pager log > log.txt


^ To search for changes

This sub-section touches on searching with git for files that have changed, and for changes in files between two or more commmits.

Capture sets of changed files over a range of commits: 

 $ for hash in COMMIT_HASH_1 COMMIT_HASH_2 COMMIT_HASH_3; do git diff-tree -r $hash; done

To find out which files have changed in a given branch, call git this way: 

  $ git diff --name-only COMMIT_HASH_1 COMMIT_HASH_2

To see the changes in one file between two commits, call git with the 'diff' command and these four arguments: 

  $ git diff COMMIT_HASH_1 COMMIT_HASH_2 -- RELATIVE_PATH_AND_FILENAME

Note: the double dash '--' separates commit hash args from filenames, as commit hashes may number more than two. !!Pay attention note!!: in this invocation to find file differences between two commits, git will not complain or warn of a pathspec which points to a non-extent file

Compare commit dates to find most recently touched local branch among n branches (substitute `branch1 branch2 branch3` with your needed branch names): 

 $ for name in branch1 branch2 branch3; do git checkout ${name}; git log | head -n 3; done


To search for most recently edited branches: 

 $ git branch --sort=-committerdate


^ small git workflows

- To discard local commits and pull a newer commit history -

Sometimes to fetch remote repository updates and attempt to pull changes to a particular branch results in local git client detecting that local branch and remote branch have parted ways in their respective histories. Git may complain `Not able to fast-forward, aborting`. When this occurs, and fast-forwarding merges is enabled, and a developer knows that the local history does not need to be saved the following command sequence may be used to overcome this conflict of histories: 

  $ git status                      # to see by how many commits the local branch has departed from its remote counterpart
  $ git reset --HARD HEAD~n         # where 'n' is the number of commits by which the local branch is ahead of the remote corresponding branch
  $ git pull origin <branch>

Some git client versions do not by default report by how many commits local branch and corresponding remote branch differ, e.g. Git for Windows bash client does not provide this difference information. To invoke `git rev-list ...` provides an alternate way to see commit history differences between local and remote branches.


^ Git Inner Workings

Key words: Three Places of Git : "Three Places of Git" : git tracked changes stored in three places

Good trio of articles by Zvonimir Spajic, on `git` inner workings, how git works under the hood. These tutorials also explain some important git terminology. Among the git details presented here Zvonimir explains that git "sees" a developer's changes in three places: working directory, staging directory and local repository. The staging directory contains a particular version controlled project's git index file. Staged but not committed changes are kept in this index file.

Atlassian's tutorial on `git reset` discusses git internals, the three places of git identified and described in Zvonimir's posts, but in slightly different ways:


^ Git Terminology

What it means to 'rebase' in context of git . . . 

  *  https://git-scm.com/docs/git-rebase


^ Git Branching

An official starting point for git branch use can be found at https://git-scm.com/docs/git-branch. Some articles on the large topic of best branching practices include:

When there are local changes that haven't been committed . . . 

  *  https://stackoverflow.com/questions/20568971/git-pull-keeps-telling-me-to-stash-local-changes-before-pulling

Excerpt from above link:

    It sounds like your local branch does not have all of the changes on origin.
    Firstly, stash your changes
    git stash
    Then, pull in the changes from origin.
    git fetch origin && git rebase origin/(branch name)
    Next, add the stash back in to your working directory:
    git stash pop


2022

2021 Renaming local and remote branches:

0404


^ Git Merge

History re-writing git tools achieved through . . .

2023-07-12 git Kraken site:


^ Git Rebase

To rebase in git has many uses. Two of the highly helpful use cases are the (1) non-interactive git rebase invoked `git rebase <branch>`, and (2) interactive rebase invoked `git rebase -i HEAD~n`. In the interactie use n is some n'th commit older than the current tip or HEAD commit.

TODO: test whether it is trivial to use `HEAD~1` as an argument to `git rebase -i`.


For (1) the non-interactive git rebase 'branch' can be any valid commit. A valid commit may be expressed by a branch name, and may alternately be expressed by a commit hash.

A or the primary use of non-interactive git rebase is to move a given branch from one parent commit to another parent commit. In this use case a common motivation is to bring in new code features from another branch. Non-interactive git rebase gives also the benefit of creating and maintaining a linear commit history.

Note: in this conversation "non-interactive" does not mean there will be no code conflicts to resolve during a given rebasing task. It is common for a branch code set undergoing rebasing to conflict with code from the new parent branch. Git client prompts a user to resolve these conflicting code changes, and to `git add` the modified files or otherwise resolve the conflicts if the files should not be changed, or present in the new commit history.


For (2) interactive git rebase, a common general motivation is to edit one or more commits in a range of commits. This use of git rebase works well when the commits themselves have one or more of the following needs:

    1. commit needs to have commit message changed
    2. commit needs to have one or more files edited, added and or deleted
    3. commit needs to be combined with prior commit

In an interactive rebase the invocation can be of the form: 

  $ git rebase -i HEAD~n

The HEAD~n git syntax specifies how many commits from the branch tip to rebase. And in this use, rebasing commits means editing commits.

Once called to rebase interactively the git client presents a list of the commits with a column left of each commit's first line of the commit message. This column can be edited to hold patterns or single letter abbreviations for actions like "edit", "squash" and similar. If a commit needs to have a file edited, added or deleted, that particular commit in the list should have its default "pick" named action in the left hand column replaced with "edit" or "e". If a commit needs to be combined with the prior commit, then that given commit should have its "pick" named action replaced with "squash" or "s".

Note:  In order to squash commits there need to be at least two commits in the commit range specified by the last argument, `HEAD~n` given in the git command invocation.

As a supporting note not directly related to interactive git rebase, it can be helpful during rebasing workflows to have a second local project repository on hand. That second repository can point to one and the same remote as the working local project repo. It can then be pointed to a branch for comparison during interactive rebasing. In other words, it may hold the branch being rebased, and show all that branch's commits during the rebase.

To see all the commits of a branch during rebase can help clarify when files need to be changed, added or removed. In the branch undergoing rebase, only commits up to the latest commit being edited or otherwise changed are visible.

In other words, not everything in the branch being interactively rebased is visible during the rebasing steps.

TODO: add note on good git strategy to split a commit to two or more commits.


TO REVIEW: . . .

Intro to git rebase:

References to and notes on `git rebase` in this section, starting with a blog post about `git rebase --onto`:

A good explanation of uses of `git rebase --onto commit1 commit2 [commit3]` by Enrico Campidoglio:


2023 September

Needed to rebase a local branch to a remote branch, namely `main`, which git could not merge in its fast-forward mode. Found solution with git invocation: 

 $ git pull origin main --rebase

First created a second branch name pointing to same commit as local `main` HEAD. Then deleted the local main branch, but not sure now whether this step is necessary.

2024 March

Ted noting that the above local branch deletion may have been a longer way to undoing local commits that are not needed. A more straight forward way to remove local commits in order to fast forward a local branch with respect to a remote branch is: 

  $ git reset --hard HEAD~n

Here n represents the number of most recent commits to prune off the local branch. This is a destructive operation, as those local commits and their respective change sets cannot be recovered locally. But when local commits are not needed and fast forwarding to pick up remote, shared repositories is needed, this is a good use of `git reset --hard ...`.


Git `rerere` - Reuse Recorded Resolution

Rebasing a branch with many commits beyond its present base commit sometimes leads to repeated conflicts, as each commit in the branch history is visited. This happens when local changes touch the same lines in the same files, between the local commits and the new base commit. The git command `rerere` stands for Reuse Recorded Resolution. It must be enabled with a global setting. (From following git article sounds as though it is disabled by default) Plus there is or are ways to use enable `rerere` per git repository, and not globally.


^ Rebase versus Merge

stub section


^ Git Diff and Related

Git difference command `git range-diff` available on Ubuntu like systems via package `git-extras`. An introductory article on basic use of `range-diff` command:

Git's range-diff command may also take arguments of the form: 

  $ git range-diff $common_base $start_of_first_commit_series $start_hash_of_second_commit_series


^ Git Tags

Command `git show <tag_name>` . . .

A few `git tag` command uses:

    $ git tag
    $ git tag --delete <tag_name>
    $ git tag -a <tag_name> -m "tagging message here" [optional_commit_hash]


^ Git stash - stash is global across branches

Note that git stash "entries" are global across branches.

Some common uses of `git stash`: 

$ git stash --keep-index --include-untracked   # . . . to create a stash entry for the present branch (NEED in-page anchor to 'git index' terminology - TMH)

$ git stash list                               # . . . list stash entries for present branch

$ git stash list --all                         # . . . list stash entries for all branches of present local repository

"Use of Git stash should be the exception and not the rule." - Cameron McKenzie, Editor In Chief, TechTarget

$ git stash show

$ git stash show -p

See also details on meanings and uses of:

$ git stash pop

$ git stash apply

$ git stash drop


^ Git log related

Keywords: git log pickaxe option

A git conventions / best practices article, specific conventions for git commit messages:

Ways to invoke `git log`:

Git's string search parameter or "pickaxe" log option `-S`:

At the command line in a color supporting terminal window, the following `git` invocation produces a useful tree like representation of local and remote branches: 

  $ git log --all --graph --oneline

How to limit count of commit log messages shown via `git log -{n}`, and other options:

To prune deleted remote branches from local git log: 

  $ git remote prune origin


^ Git remotes

Working with multiple git remotes , remote repositories. The following tutorial link to Jigarius leads to a good article. In attempting to set up a local git remote 'definition' with two remote URLs, it became clear that there are issues that break this effort when one remote repo is already created and has pre-existing history. It doesn't matter how short or simple that history is. So this is a good link, but may not be practical to set up multiple remotes to be updated with a single 'push' command when the remotes are not all fully under a given developer's control:

So another question which this prompts, this being the effort to push local work to multiple remotes, is: how does git handle symbolic links? Links at least in the Unix and Linux context?

On git handling of symlinks:

Adding ssh keys to ssh-agent, listing ssh keys, configuring multiple github emails:

How to list git configuration: 

  $ git config --list

How to modify remote repository URL: 

  $ git remote set-url origin git@github.com:[github_account_username]/[repository_name]

. . . this information thanks to post at https://stackoverflow.com/questions/2432764/how-do-i-change-the-uri-url-for-a-remote-git-repository.


^ Using Git and Subversion Together

Using Git and Subversion on one and the same project looks complicated . . .


^ Git For Windows notes

Looks like with latest (as of 2021-06-16) Git For Windows offers three different ways to configure credentials management. This seems important, here is a link provided by the Git-for-Windows installer:

Locally installed release notes at: file:///C:/Users/<user_name>/AppData/Local/Programs/Git/ReleaseNotes.html


^ References

Git fetch and merge preferrable to git pull . . .

Note: in Firefox 89.0.1 (64-bit) the key binding <CTRL>+j opens a message box showing download progress and history.



Retrieved from "https://wiki.neelanurseries.com/index.php?title=Git_notes&oldid=8143"