Centralized / Featrue Branch Git Workflow

Centralized Workflow

1. First, someone needs to create the central repository on a server.
Central repositories should always be bare repositories.

ssh user@host git init --bare /path/to/repo.git

Note that the .git extension is conventionally appended to the repository name to indicate that it’s a bare repository.

2. Next, each developer creates a local copy of the entire project.

git clone ssh://user@host/path/to/repo.git

When you clone a repository, Git automatically adds a shortcut calledorigin 
that points back to the “parent” repository.

3. In developer's local repository, he can develop features using the standard Git commit process: edit, stage, and commit. These commands create only local commits

git status # View the state of the repo
git add <some-file> # Stage a file
git commit # Commit a file</some-file>

4.  After finishing his feature, developer should publish his local commits to the central repository.

git push origin master

origin is the remote connection to the central repository that Git created when developer cloned it. 
The master argument tells Git to try to make the origin’s master branch look like his local master branch.  

5. Another developer can use git pull to incorporate upstream changes into her repository.

git pull --rebase origin master

The --rebase option tells Git to move all of this developer’s commits to the top of the master branch after synchronising it with the changes from the central repository. For this workflow, it’s always better to rebase instead of generating a merge commit.

Rebasing works by transferring each local commit to the updated master branch one at a time. This means that you catch merge conflicts on a commit-by-commit basis rather than resolving all of them in one massive merge commit.

6. Resolve the Conflicts. If the rebasing process generates conflicts, Git will pause the rebase at the current commit and output the following message, along with some relevant instructions:

CONFLICT (content): Merge conflict in <some-file>

Developer would run a git status to see where the problem is. Conflicted files will appear in the Unmerged paths section:

# Unmerged paths:
# both modified: <some-file>

Then, edit and stage the file(s).  Let git rebase do the rest:

git add <some-file>
git rebase --continue

Git will move on to the next commit and repeat the process for any other commits that generate conflicts.

To give up and right back to where you started before you ran git pull --rebase

git rebase --abort

After synchronizing with the central repository, developer will be able to publish his changes successfully:

git push origin master

Feature Branch Workflow
First, you need to make sure your local master is synchronized with the upstream master. Then, you merge the feature branch into master and push the updated master back to the central repository.

1. Before a developer starts developing a feature, he can request a new branch with the following command:

git checkout -b marys-feature master

2. This checks out a branch called marys-feature based on master, and the -b flag tells Git to create the branch if it doesn’t already exist. 

git status
git add <some-file>
git commit

3. On this branch, edits, stages, and commits changes in the usual fashion.

git push -u origin marys-feature

This command pushes marys-feature to the central repository (origin), and the -u flag adds it as a remote tracking branch. After setting up the tracking branch in the first time, developer can call git push without any parameters to push this feature again.

git push

4. Then, developer files the pull request in her Git GUI asking to merge marys-feature into master.

git checkout master
git pull origin marys-feature
git push

First, whoever’s performing the merge needs to check out their master branch and make sure it’s up to date. Then, git pull origin marys-feature pulling the most up-to-date version of the feature branch, and merges the central repository’s copy of marys-feature. Finally, the updated master needs to get pushed back to origin.

Reference:

https://www.atlassian.com/git/tutorials/comparing-workflows/centralized-workflow