Updated by
Modified
GitWorkflow.md- Ignore whitespace
+Once your branch has been created, it's time to start making changes. Whenever you add, edit, or delete a file, you're making a commit, and adding them to your branch. This process of adding commits keeps track of your progress as you work on a feature branch.
+Commits also create a transparent history of your work that others can follow to understand what you've done and why. Each commit has an associated commit message, which is a description explaining why a particular change was made. Furthermore, each commit is considered a separate unit of change. This lets you roll back changes if a bug is found, or if you decide to head in a different direction.
+[Atlassian on Pull Requests](https://confluence.atlassian.com/display/BITBUCKET/Work+with+pull+requests)
+A pull request has source code that comes from one repository (fork or branch) into another. When a pull request originates in a branch of your repository, it is commonly called "a pull across branches." You can incorporate a pull request into your repository using Bitbucket. You can also incorporate a request by pulling the code manually into your local repository and pushing the resulting repository back to Bitbucket.
+If a pull request conflicts with your repository, you must manually pull the code to your local repository and resolve the request there. You resolve the conflicts locally by merging or whatever other means works best. Then, push the changes back to Bitbucket. After the push, Bitbucket shows the request as accepted. Pulling a request locally is also a means for evaluating a code change before accepting the change.
+A pull request has a source and a destination repository. The source is the repository where the changes reside. The destination repository is the repository into which you want to pull (merge) your changes. Both the source and destination also have a branch () designation:
+- To see the list of all the pull requests against this repository, click Pull Requests in the navigation bar.
+If the pull request is a small change with little impact, then it's OK for the person who created the pull request to merge it into the master branch. If the change is a larger change, then the merge should be done with another member of the team.
+ The pull request details appear and the view defaults to the Diff context. You can also view the Commits or the comment Activity on the request.
+It's possible that a pull request may have conflict (e.g. two people have changed the same source code file.) When this happens, Bitbucket should give instructions on how to resolve the conflict.
+It's all too easy to just compile the current branch locally, and push it out to the test server. This isn't as scalable as it could be, and there's a tendency for code to be included that isn't in source control. Because of this, I would like quite a strict release process. It should be :
You can clone a snippet to your computer for local editing. Learn more.