What is the correct GitHub process that I need to follow when changing code?
Developer A (myself) has a local repo and a remote repo, the remote repo is a fork of Developer B repo, local repo is a clone of remote repo.
When Developer B asks me to perform changes in the code of a program, Developer A performs the changes in RStudio (in this case), Developer A go to SourceTree, opens up the local repo, commit the changes of the program, push the changes to my remote repo and to the upstream repo. Everything is in sync and we are happy.
However, if Developer B rejects Developer A changes, then my local and remote repos are now not in sync with the upstream, Git won’t allow me to push any changes. For ignorance, what I do is to delete both the local and remote repos, fork again the remote, clone it to the local, redo the changes, commit in source tree and push again. This is way too much work, there should be a better way, right?
- Converting a development team from FTP to a Versioning System
- Exclude from Source Control not really working in Visual Studio 2013?
- Split a Subversion Repository Project to Two Git Repositories
- Git repository is out of sync after rebase
- Visual Source Safe --> TFS Migration
- Elegantly handle site-specific settings/configuration in svn/hg/git/etc?
One Solution collect form web for “What is the correct GitHub process that I need to follow when changing code?”
You should be doing all your work on topic branches (let’s call it
topic), not on the main branch (let’s call it
master). If you create a new branch for each “task” you are assigned, this branch only exists on your local repo. Later you will push this to your fork and make a Pull Request comparing
If the owner of
upstream doesn’t merge your changes, then no real harm is done;
upstream has no branch and no commits with these changes. You can simply checkout
master on your local repo and start again on a new topic branch.
While your Pull Request is open, you can continue to push changes to the branch on your fork and it will automatically update the Pull Request. The expectation here is that you’ll resolve whatever issues are preventing the owner of
upstream from merging your changes.
If you made changes to your local branch that tracks a branch in upstream, you have a few options:
- If you want to keep the changes, do a
git branchto make a new branch pointer on your current
HEAD, then simply
git reset --hard upstream/branch_name.
- If you don’t want to keep the changes, just
git reset --hard upstream/branch_name