Git

Common knowledge

1. Git Clone vs Git Pull

• git clone is how you get a local copy of an existing repository to work on. It's usually only used once for a given repository or get a working copy of the remote repository)

 After the clone, a plain git fetch without arguments will update all the remote- tracking branches, and a git pull without arguments will, in addition, merge the remote master branch into the current master branch

• git pull (or git fetch + git merge) is how you update that local copy with new commits from the remote repository. If you are collaborating with others, it is a command that you will run frequently

1. Git Fetch vs Git Pull

You can do a git fetch at any time to update your remote-tracking branches under refs/remotes/<remote>/. This operation never changes any of your own local branches under refs/heads and is safe to do without changing your working copy

When you fetch, Git gathers any commits from the target branch that do not exist in your current branch and stores them in your local repository. However, it does not merge them with your current branch. This is particularly useful if you need to keep your repository up to date, but are working on something that might break if you update your files. To integrate the commits into your current branch, you must use merge afterwards.

When you use pull, Git tries to automatically merge. It is context sensitive, so Git will merge any pulled commits into the branch you are currently working on. pull automatically merges the commits without letting you review them first. If you don’t carefully manage your branches, you may run into frequent conflicts.

Git pull does a git fetch followed by a git merge

1. Git Merge vs Rebase

In Git, there are two main ways to integrate changes from one branch into another: the merge and the rebase

Git Merge: https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging

Git Rebase: https://git-scm.com/book/en/v2/Git-Branching-Rebasing

There is no difference in the end product of the integration, but rebasing makes for a cleaner history.  If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel.

Merge vs Rebase. Which one is better?

Now that you’ve seen rebasing and merging in action, you may be wondering which one is better. Before we can answer this, let’s step back a bit and talk about what history means.

One point of view on this is that your repository’s commit history is a record of what actually happened. It’s a historical document, valuable in its own right, and shouldn’t be tampered with. From this angle, changing the commit history is almost blasphemous; you’re lying about what actually transpired. So what if there was a messy series of merge commits? That’s how it happened, and the repository should preserve that for posterity.

The opposing point of view is that the commit history is the story of how your project was made. You wouldn’t publish the first draft of a book, so why show your messy work? When you’re working on a project, you may need a record of all your missteps and dead-end paths, but when it’s time to show your work to the world, you may want to tell a more coherent story of how to get from A to B. People in this camp use tools like rebase and filter-branch to rewrite their commits before they’re merged into the mainline branch. They use tools like rebase and filter-branch, to tell the story in the way that’s best for future readers.

Now, to the question of whether merging or rebasing is better: hopefully you’ll see that it’s not that simple. Git is a powerful tool, and allows you to do many things to and with your history, but every team and every project is different. Now that you know how both of these things work, it’s up to you to decide which one is best for your particular situation.

You can get the best of both worlds: rebase local changes before pushing to clean up your work, but never rebase anything that you’ve pushed somewhere.

Resolve Conflict

1. Resolve conflict by Tortoise Git (KDiff3)

- https://blog.coding-mayhem.com/2016/06/setting-up-kdiff3-to-work-with.html

- https://www.youtube.com/watch?v=CU6y02xq-KM

Install KDiff3: https://blog.coding-mayhem.com/2016/06/setting-up-kdiff3-to-work-with.html

and then setup to use KDiff3 as merge tool in Tortoise Git

+ Diff Viewer: C:\Program Files\KDiff3\kdiff3.exe %base %mine %theirs --L1 Base --L2 Mine --L3 Theirs

+ Merge tool: C:\Program Files\KDiff3\kdiff3.exe %base %mine %theirs --L1 Base --L2 Mine --L3 Theirs -o %merged

1. Resolve conflict by IDE (Visual Studio Code)

- https://www.youtube.com/watch?v=kBIMGOxqqnk

Note: Git mergetool generates unwanted .orig files. You can configure to remove .orig file

- https://stackoverflow.com/questions/1251681/git-mergetool-generates-unwanted-orig-files