Resolving Merge Conflicts and Publishing Work

1 hello 100644 ba42a2a96e3027f3333e13ede4ccf4498c3ae942 2 hello 100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello ------------ In our example of only two files, we did not have unchanged files so only 'example' resulted in collapsing. But in real-life large projects, when only a small number of files change in one commit, this 'collapsing' tends to trivially merge most of the paths fairly quickly, leaving only a handful of real changes in non-zero stages. To look at only non-zero stages, use `--unmerged` flag: ------------ $ git ls-files --unmerged 100644 557db03de997c86a4a028e1ebd3a1ceb225be238 1 hello 100644 ba42a2a96e3027f3333e13ede4ccf4498c3ae942 2 hello 100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello ------------ The next step of merging is to merge these three versions of the file, using 3-way merge. This is done by giving 'git merge-one-file' command as one of the arguments to 'git merge-index' command: ------------ $ git merge-index git-merge-one-file hello Auto-merging hello ERROR: Merge conflict in hello fatal: merge program failed ------------ 'git merge-one-file' script is called with parameters to describe those three versions, and is responsible to leave the merge results in the working tree. It is a fairly straightforward shell script, and eventually calls 'merge' program from RCS suite to perform a file-level 3-way merge. In this case, 'merge' detects conflicts, and the merge result with conflict marks is left in the working tree.. This can be seen if you run `ls-files --stage` again at this point: ------------ $ git ls-files --stage 100644 7f8b141b65fdcee47321e399a2598a235a032422 0 example 100644 557db03de997c86a4a028e1ebd3a1ceb225be238 1 hello 100644 ba42a2a96e3027f3333e13ede4ccf4498c3ae942 2 hello 100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello ------------ This is the state of the index file and the working file after 'git merge' returns control back to you, leaving the conflicting merge for you to resolve. Notice that the path `hello` is still unmerged, and what you see with 'git diff' at this point is differences since stage 2 (i.e. your version). Publishing your work -------------------- So, we can use somebody else's work from a remote repository, but how can *you* prepare a repository to let other people pull from it? You do your real work in your working tree that has your primary repository hanging under it as its `.git` subdirectory. You *could* make that repository accessible remotely and ask people to pull from it, but in practice that is not the way things are usually done. A recommended way is to have a public repository, make it reachable by other people, and when the changes you made in your primary working tree are in good shape, update the public repository from it. This is often called 'pushing'. [NOTE] This public repository could further be mirrored, and that is how Git repositories at `kernel.org` are managed. Publishing the changes from your local (private) repository to your remote (public) repository requires a write privilege on the remote machine. You need to have an SSH account there to run a single command, 'git-receive-pack'. First, you need to create an empty repository on the remote machine that will house your public repository. This empty repository will be populated and be kept up to date by pushing into it later. Obviously, this repository creation needs to be done only once. [NOTE] 'git push' uses a pair of commands, 'git send-pack' on your local machine, and 'git-receive-pack' on the remote machine. The communication between the two over the network internally uses an SSH connection. Your private repository's Git directory is usually `.git`, but your public repository is often named after the project name, i.e. `<project>.git`. Let's create such a public repository for project `my-git`. After logging into the remote machine, create an empty directory: ------------ $ mkdir my-git.git ------------ Then, make that directory into

This section continues explaining the Git merge process, including resolving conflicts and using 'git merge-one-file' and 'git merge-index' commands, and then moves on to publishing your work by creating a public repository, setting up a remote repository, and using 'git push' to update the public repository from your local repository.