This document provides details on ACME development conventions and practices.
...
important -- Items colored in red mean they are important, and should not be ignored.
one time -- Items colored in green are commands to be issued once per machine.
repo once -- Items colored in orange are commands to be issued once per local repository.
...
Your PR is not finished until it has been merged to master by the Integrator.
This document can be used to help with pull request related issues.
...
Before communicating with remotes, you might want to add or remove remotes. In order to add and remove remotes the git remote command can be used. The two uses are as follows:
git remote add remote-name protocol:address/to/repo # Creates a remote
git remote remove remote-name # Removes a remote
In order to communicate with remotes, there are three actions. push, pull, and fetch.
...
git pull <remote-name> <branch-name>
Git vs. Svn Merges
and why you don't always need to merge from master.
...
Never Merge From Master
You never need to "merge from master" to make the eventual merge of your feature branch easier. This is because, unlike svn, git is smart enough to ignore changes that have occurred in files you aren't working on when you finally merge your branch to master.
Details:
One of the main differences between git and svn is how history and branches are stored. In svn branches are virtual directories (i.e. svn copy ^/trunk branch_name) and the history is stored as a stack of revisions (providing the monotonically increasing revision number). The problem with this is that a branch isn't actually a branch. It doesn't contain the information about where it was created from or what has been "merged" into it. The same is true when a branch is merged back into trunk; there isn't a clear historical description of what has already been integrated into trunk. (NOTE: svn has put some effort into improving their branching and merging capabilities, but they are still not up-to-par with DVCS tools)
However, in git the history is stored as a Directed Acyclic Graph (DAG), and branches are first-class citizens. The DAG structure allows any commit to determine which other commits it includes changes from (or which commits have been integrated into it). Using this history structure, git is able to ignore changes from commits that have already been integrated, reducing the number of merge conflicts that occur when bringing in a large set of changes.
This also means that it is not necessary to "merge from master" if the only reason is to make your eventual merge "easier" (a common need in svn). Git is smart enough to know that only the files you have actually touched need to be merged and will ignore any differences that have developed in other files since you started your branch.
NOTE: While git is better at handing merges and branches, do not expect that you will never encounter a merge conflict. Merge conflicts still exists, and have to be dealt with. No version control tool will be able to automatically resolve a conflict when two people change the same line of code.
...