#to get started with dev -create a fork of the Signal-iOS repo https://github.com/WhisperSystems/Signal-iOS (click fork)
-clone that repo into a nice local directory
-add the original repository as a remote
git remote add upstream https://github.com/WhisperSystems/Signal-iOS.git
-clone your fork and when you are ready to work on a new feature off of the master branch:
git fetch upstream
git checkout upstream/master
git checkout -b my_feature
git commit -am "my changes 1"
git commit -am "my changes 2"
git commit -am "my changes 3"
you can also push to your fork
git push origin my_fork
- rebase your changes into a single (or few) commits:
git rebase -i HEAD~3
- rebase your changes on top of master:
git fetch upstream
git rebase upstream/master
- push to your fork (if you rebased since pushing to your fork you will need to create a new branch)
git checkout -b my_feature_PR
git push origin my_feature_PR
submit your PR!
i have some problems with this one...
what if you need your upstream fork be protected against any pushes?
why have so much noise in upstream branch?
why can`t you just add two remotes? like
git remote add originUpstream git:upstreamurl.
git remote add originFork git:forkfurl
after that you can do this.
git pull origin master
git checkout -b branch_name
git push originFork branch_name
no more branches on upstream... only on forks..
pr`s will be created for originUpstream/master <-> originFork.
all the junky branches will be on forks, again no noise.
upstream can be protected against other branch pushes.
gatekeeper has a better overview without the branch noise.
if you have 20 developers pushing new branches on originUpstream -> junk....
collaboration.....
other collaborator can add your for as a remote at their local machine and continue work in that place....
git remote add originOtherUserFork git:otherUserforkfurl
also commit messages should have [task-name] in all commits.
squash pr merge.