Difference between revisions of "Typical Git workflow"

From RidgeRun Developer Connection
Jump to: navigation, search
m
m
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
== Introduction  ==
 
== Introduction  ==
  
Normal workflow is to develop and check in on a branch, then once everything is happy, merge the branch back into the master.   
+
The normal workflow is to develop and check in on a branch, then once everything is happy, merge the branch back into the master.   
  
Local repository consists of three '''"trees"''' maintained by git. the first one is your '''Working Directory''' which holds the actual files.The second one is the '''Index''' which acts as a staging area and finally the '''HEAD''' which points to the last commit you've made. You typically only see the working directory, but as you issue git commands, it is helpful to understand the information used by git.
+
The local repository consists of three '''"trees"''' maintained by git. The first one is your '''Working Directory''' which holds the actual files. The second one is the '''Index''' which acts as a staging area and finally the '''HEAD''' which points to the last commit you've made. You typically only see the working directory, but as you issue git commands, it is helpful to understand the information used by git.
  
 
== Workflow Diagram  ==
 
== Workflow Diagram  ==
Line 17: Line 17:
 
== Typical Workflow are as follows  ==
 
== Typical Workflow are as follows  ==
  
# get local copy of code
+
# Get local copy of code
# create a branch
+
# Create a branch
# edit files
+
# Edit files
# add andcommit changes to local machine
+
# Add and commit changes to local machine
# get back in sync with changes commited by others
+
# Get back in sync with changes commited by others
# push branch to remote git repository
+
# Push branch to remote git repository
# merge local branch into local master
+
# Merge local branch into local master
# push local master to remote git repostiory  
+
# Push local master to remote git repostiory  
  
 
The cut-and-paste commands assume you have set '''REPO''' and '''BRANCH''' shell variables.  An example setting would be:
 
The cut-and-paste commands assume you have set '''REPO''' and '''BRANCH''' shell variables.  An example setting would be:
Line 35: Line 35:
 
== Get a local copy of the code  ==
 
== Get a local copy of the code  ==
  
First create a working directory (what RidgeRun calls a DEVDIR when using a RidgeRun SDK)
+
First, create a working directory (what RidgeRun calls a DEVDIR when using a RidgeRun SDK)
  
 
<pre>
 
<pre>
Line 72: Line 72:
 
git creates a commit (very much like a patch file) based on the files you want added to commit.
 
git creates a commit (very much like a patch file) based on the files you want added to commit.
  
First you tell git which files you want part of the commit.  Any changes you have made to those files will be included in the commit.
+
First, you tell git which files you want part of the commit.  Any changes you have made to those files will be included in the commit.
  
 
<pre>
 
<pre>
Line 90: Line 90:
 
</pre>  
 
</pre>  
  
Now the file is committed to the HEAD of your local repository, but the changes are not part of the repository you cloned.  However, git will not let you push your commits to the remote repository unless changes commited by others to the remote repository are part of your local repository.
+
Now the file is committed to the HEAD of your local repository, but the changes are not part of the repository you cloned.  However, git will not let you push your commits to the remote repository unless changes committed by others to the remote repository are part of your local repository.
 
   
 
   
 
Another helpful command is to see all the commits on your currently checked out branch
 
Another helpful command is to see all the commits on your currently checked out branch
Line 106: Line 106:
 
to install the gitk tool.
 
to install the gitk tool.
  
== Get back in sync with changes commited by others ==
+
== Get back in sync with changes committed by others ==
  
 
You first need to get your local master in sync with the remote repository, then merge those changes into your branch.
 
You first need to get your local master in sync with the remote repository, then merge those changes into your branch.
Line 119: Line 119:
 
If someone changed a file and pushed that change to the remote repository and you changed the file too in your local repository, then you might need to resolve which changes have priority.  There is lots of information on the Internet on how to do this sometimes complex task.
 
If someone changed a file and pushed that change to the remote repository and you changed the file too in your local repository, then you might need to resolve which changes have priority.  There is lots of information on the Internet on how to do this sometimes complex task.
  
== Push branch to remote git repository ==
+
== Push the branch to remote git repository ==
  
You can share your branch with other by pushing it to the remote repository
+
You can share your branch with others by pushing it to the remote repository
  
 
<pre>
 
<pre>
Line 148: Line 148:
 
</pre>
 
</pre>
  
== Push local master to remote git repostiory ==
+
== Push local master to remote git repository ==
  
 
To send the changes (from the HEAD of your local master branch) to your remote repository:
 
To send the changes (from the HEAD of your local master branch) to your remote repository:
Line 157: Line 157:
  
 
Change master to whatever branch you want to push your changes to.
 
Change master to whatever branch you want to push your changes to.
[[Category:HowTo]]
+
 
 +
[[Category:Git]][[Category:HowTo]][[Category:GitHub]][[Category:GitLab]]

Latest revision as of 23:24, 18 February 2021

Introduction

The normal workflow is to develop and check in on a branch, then once everything is happy, merge the branch back into the master.

The local repository consists of three "trees" maintained by git. The first one is your Working Directory which holds the actual files. The second one is the Index which acts as a staging area and finally the HEAD which points to the last commit you've made. You typically only see the working directory, but as you issue git commands, it is helpful to understand the information used by git.

Workflow Diagram

Error creating thumbnail: Unable to save thumbnail to destination

References

Typical Workflow are as follows

  1. Get local copy of code
  2. Create a branch
  3. Edit files
  4. Add and commit changes to local machine
  5. Get back in sync with changes commited by others
  6. Push branch to remote git repository
  7. Merge local branch into local master
  8. Push local master to remote git repostiory

The cut-and-paste commands assume you have set REPO and BRANCH shell variables. An example setting would be:

REPO=git@github.com:RidgeRun/eval-sdk-dm36x
BRANCH=fixed-ip-address

Get a local copy of the code

First, create a working directory (what RidgeRun calls a DEVDIR when using a RidgeRun SDK)

git clone $REPO.git sdk

Create a Branch

Branches are used to develop features in isolation from each other. The master branch is the "default" branch when you create a repository. Use other branches for development and merge them back to the master branch upon completion.

Create a new branch and switch to that branch:

git checkout -b $BRANCH

Switch back to master by running the below command:

git checkout master

A branch is not available to the others unless you push the branch to your remote repository

git push origin $BRANCH

Edit Files

Use your favorite editor to modify existing source files and create new source files.

Add and commit changes to a local machine

git creates a commit (very much like a patch file) based on the files you want added to commit.

First, you tell git which files you want part of the commit. Any changes you have made to those files will be included in the commit.

git add $FILE1 $FILE2

You can see what files will be part of the next commit, which other files you have changed, and what files have been added that are not part of the git index:

git status

Now you can create the actual commit:

git commit -m "$COMMIT_MESSAGE"

Now the file is committed to the HEAD of your local repository, but the changes are not part of the repository you cloned. However, git will not let you push your commits to the remote repository unless changes committed by others to the remote repository are part of your local repository.

Another helpful command is to see all the commits on your currently checked out branch

gitk &

You may have to run:

sudo apt-get gitk

to install the gitk tool.

Get back in sync with changes committed by others

You first need to get your local master in sync with the remote repository, then merge those changes into your branch.

git checkout master
git pull
git checkout $BRANCH
git merge master

If someone changed a file and pushed that change to the remote repository and you changed the file too in your local repository, then you might need to resolve which changes have priority. There is lots of information on the Internet on how to do this sometimes complex task.

Push the branch to remote git repository

You can share your branch with others by pushing it to the remote repository

git push origin $BRANCH

Merge local branch into local master

To merge your branch into your local master:

git checkout master
git merge $BRANCH

git tries to auto-merge changes. Unfortunately, this is not always possible and results in conflicts. You are responsible to merge those conflicts manually by editing the files shown by git. After changing, you need to mark them as merged with

git add $FILE1 $FILE2

before merging changes, you can also preview them by using

git diff $BRANCH master

Push local master to remote git repository

To send the changes (from the HEAD of your local master branch) to your remote repository:

git push origin master

Change master to whatever branch you want to push your changes to.