Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Add some "nevers"

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.

...

Merges to master will be done locally by integrators.  See Integrator Guide for more info.


Additional Topics


 This section will be used to house additional information for people who are interested. It will attempt to clarify some of the comments made in the development reference by expanding a bit more on them. Developers can safely ignore this content, it's only provided for educational purposes. 

The list of "nevers":

  • Never merge from master to your feature branch.
  • Never merge "next" to "master"
  • Never use "cherry-pick" on "next"
  • Never commit directly to "master" or "next".  Only use merge commits of branches.

Working with Remote repositories

...

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. pushpull, and fetch.

...


git pull <remote-name> <branch-name>

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.

...