Working as Team with the use of GitHub and Git!

Best read for a newbie working as team using Git and GitHub……

I’m a 3rd Year Software Engineering undergraduate, So up to my 2nd year we had software development projects that are done individually ,so we don’t need to bother about working as team for software development and maintaining the integrity.

But now when it comes to Working as Team, then Version Controlling is utter most important.During this period I learned a lot of thinks regarding working as team, important good principals that need to be followed when we Use Git.

In this blog I just want to share the knowledge I gathered through this learning process. Important fact for me to share this is I couldn’t find information altogether at one place.

So Lets begin,

Here I Assume you have a basic knowledge of Git, otherwise have a look at my Blog on basic s of Git here.

First I will explain through the process, when we work as team

1. One Team member create a Repository in his GitHub account with some codes in it.
2. So Each team member needs to Fork it to their own GitHub account and clone it to their local machine
3. So basically there are there are two remote repository, one is the original one that is central to all team members, usually we call it a ‘upstream’, the other remote repository in our own GitHub account where we cloned from is called ‘origin’
4. By default ‘origin’ remote repository will be configured as we cloned it from there
5. Every Team member needs to create a new branch from master branch and they need to work on it.
6. As they work the need to regularly commit change to their local machine, once they are done with their part, merge it to master branch.
7. And finally push it to their ‘origin’ remote repository.
8. Now you can ask ‘upstream’ repository to accept the changes by creating a pull request
9. Apart from the above general flow of working as team, I will also share some advanced but very important feature we need to know

Let’s get our hands dirty!

Step 1 : Create a Fork on the repository you need to work on

1.1 Navigate to the repository you want to fork

1.2 Click to the fork button appear in the top left hand corner

1.3 Navigate to you own GitHub account,and now you see a repository created on you account with same name as you cloned

1.4 Now click on to clone or download button

1.5 Copy the URL appear in it(make sure you user name is part of URL)

1.6 Open Git bash and navigate to your desired folder location

1.7 type git clone and paste the URL you copied and press enter

> git clone https://github.com/YOUR-USERNAME/repoName

1.8 Now have cloned the repository to your local machine

1.9 check into the cloned folder and check the remote repository configuration

> cd <PARTICULAR_CLONED_FOLDER>

> git remote -v
You could see a response as follows
 > origin https://github.com/YOUR_USERNAME/YOUR_FORK.git (fetch)
 > origin https://github.com/YOUR_USERNAME/YOUR_FORK.git (push)

Step 2: Create a branch and make changes to it

2 .1 Now you have to create a branch to work on the project

### On a single go create and checkout to branch
 > git checkout -b <YOUR_BRANCH_NAME>

or
### First create a branch
 > git branch <YOUR_BRANCH_NAME>
### Then checkout to the branch
 > git checkout <YOUR_BRANCH_NAME>
Note: When naming your branch it’s a best practice to start with your initial then the feature name you going to implement, so that it will be easy to verify who made the change
 eg : git checkout -b ns_new_feature

2.2 After every code implementation stage the changes and commit to local repository

### Check the status of changes
 > git status

### Stage all the files that are modified
 > git add .
### Commit the changes with a message
 >git commit -m “commit message”

Step 3: After implementing feature merge it to master

3.1 Once you are done with all the implementation on your newly created branch now we need to merge it to master branch before pushing it to remote

### checkout to master branch
 > git checkout master
### merge the feature branch you just complete to master
 > git merge <YOUR_BRANCH_NAME>

3.2 Now you can push all the changes to ‘origin’ remote repository

### push to origin repository
 > git push origin master

note: Here we specify master to push all change in local/master to origin/master
### push to newly created branch to remote repository
 > git push -u origin <YOUR_BRANCH_NAME>
### push to all branches in local repository to remote repository
 > git push origin — all

Step 4: Pull request to upstream repository

4.1 As soon as you push to origin repository a notification of pull request will be implicitly appear in the original repository where you created your fork from

4.2 Other wise you can create a pull request manually

4.2.1 Navigate to original upstream repository GitHub page

4.2.2 There you have to click to new pull request button

4.2.3 Now you should select the option of compare across forks

4.2.4 Select the appropriate base fork and base branch where you want to make changes. Like wise select the head fork and head branch where you made your changes

4.2.5 Fill the fields of title, description of your pull request. You could also allow settings so that anyone with push access in upstream repository can make changes

4.2.6 Finally now you can create a pull request by clicking to “Create Pull Request”

Now we are done with basic flow of working as team

Now lets look in to bit advanced concept but very important when it comes to working as team

There is a instance when any of your group member finished a feature before you have finished your implementation and that member has merged the feature into upstream master branch

In that case your actual local repository is outdated from the upstream repository.

So in this case you need to make the upstream sync with you local repository in your machine

1. Now you need to configure you local repository to add the upstream repository

# Add 'upstream' config
git remote add upstream <ORIGINAL_REPO_URL>

# You can Verify 'upstream' configuration
git remote -v
### You will see a response as follows
> origin  https://github.com/YOUR_USERNAME/YOUR_FORK.git (fetch)
> origin  https://github.com/YOUR_USERNAME/YOUR_FORK.git (push)
> upstream  https://github.com/ORIGINAL_OWNER/OWNER_REPO.git (fetch)
> upstream  https://github.com/ORIGINAL_OWNER/OWNER_REPO.git (push)

2. Now you need to fetch the updated upstream repository

# Fetch from upstream remote repository
> git fetch upstream

3. Now checkout to the local repository master branch and merge the fetched upstream/master branch to it

### Checkout your master branch in local repository
> git checkout master
### merge upstream/master to local/master
git merge upstream/master

4. Now we need to add those new updated change to the feature_branch that we are currently working on. other wise the feature_branch we are working on won’t have those changes we fetched

### Checkout your feature branch your working in local repository
> git checkout newfeature

Note: Re-base is actually updating feature_branch you’re working on by re-basing commits you made over the updated master branch

### Make sure you're in a feature branch
> git rebase master

That’s it now once you are done with the implementation follow the steps 3 and 4.

It’s always a good practice to make your local repository sync with original remote repository, to avoid complex conflict at the end

Handling Conflict while merging

Another important aspect that we do need to focus is Conflict handling.

There are instances where we want to merge some of the branch we are working to another branch.In such cases conflict may arise since there may be same file that is having two different changes.

In this case merging wont be done completely until the conflicts are resolved manually.

Here we can make use of any Editors like VS code, once we resolve the conflict, in order to complete the merging process completely we need to add the changed files to staging and make commit, which implicitly complete the merging process

This bring a conclusion to the learning of Git basic flow!!!

Thanks for reading my blog….See you soon in the next blog