Common Lifecycle Commands

 So you're looking to work on some code and want ot know how you can use git to track the progress of development in a reasonable way? Here's a quick outline of what might be required over a standard set of changes to a codebase.

Clone Repo

  Firstly we'll need a repo to work on, I'll assume you know what you want to work on here and have a cloud/remote repo that holds the codebase. The first task is to clone a version of that repo to your computer, this means creating a folder and initialising git inside it, connecting that git install to a remote repo and pulling the files in the master branch. Fortunately git has that simplified to a single line of code, depending on your connnection type you'll use a command in the format below, I'd recommend setting up SSH though and there are pages around here somewhere that can help with that.
 

# SSH connection format
workspace$ git clone git@bitbucket.org:UserName/projectRepo.git

# HTTP connection format
workspace$ git clone https://UserName@bitbucket.org/UserName/projectRepo.git

Update your Remote

If you've just created your respo by using the above then you won't need to perform this step but to ensure that the info your local repo holds the latest information from your remote run this command, it will ensure that when the tracking branch is created it is created with the latest information.

git pull origin master

Create your Branch

Now that you've got a version of the repository locally you'll be in the default branch initially whish is usually 'master'. It's good practice to separate out each change or set of changes into their own branch.

# Create a branch locally called 'dev' that tracks the current branch
git checkout -b dev

# As above, create a local branch but this pulls from the branch 'dev' on origin and has the upstream set
git checkout -b dev origin/dev

Submodules? (Initialising someone else's)

If the project you're working on (or branch if you've just grabbed one from origin) has submodules you'll need to make sure that you've got them initialised. Fortunately as with a lot of git, the series of commands that you'd need to enter to do this can be rolled into the below

git submodule update --init --recursive

Working

Submodules? (Adding one to your branch)

One of the really nice things about git is that it lets you store your code in chunks and track the progress of those chunks, if however you want to use one of those chunks in a new solution then submodules are what you need and as you're basically pulling a new git repo into your current one the syntax is very similar to the initial cloning commands above.

# SSH connection submodule addition
git submodule add git@bitbucket.org:UserName/projectRepo.git

# HTTP connection submodule addition
git submodule add https://UserName@bitbucket.org/UserName/projectRepo.git

Saving your changes to a Commit

  when you've made changes to files in your branch git will initially hold these as 'Unstaged Changes'. To commit these changes you will need to 'stage' them beforehand, to take a look at what's happening here run the familiar favourite Git Status. on doing that you'll see the status of each file that git is aware of a change for and whether each change has been staged:

• Git Status -w- output

You can stage files in either of the following two ways, hit git status again to show that your files are staged.

• git add [filepath]

• git add .

  • The second of these commands will add -everything- so be careful with it's use if your .gitignore file isn't up to scratch or you've got files which you'd rather not track as part of your work - in that instance it's much easier to add something to tracking than it is to remove
• Git add ., git add "", git status

to revert changes or remove a file from being staged try these or take a look here:
 

• git reset, git checkout previous etc..

Once you've got all of your files properly staged or reverted then commit your changes to your local repo using the following. Make sure that the message that you include is useful, it'll really help if you need to isolate specific changes later.

• git commit -m "message"

• git commit -m "update of sql generation classes to include proper IN handling"

Pushing your Commit to your Remote Repository

  At this point your changes are sat, commited to your local repository, now you need to get them to the remote for the rest of the process to continue. Depending on your security setup it's entirely possible that you can't simply push back to the remote branch that you based your branch on, a common setup is for these updates to be managed via 'pull requests'. Before you push anything it's worth taking a look to see which branches you have and what the upstream branch is for each of them (the remote branch to which your local branches refer). The command for this is simply:

• git branch -a -vv

If you haven't pushed this change set before then the upstream on your current branch will still be 

# git push [remoteName] [branchName]
git push -u origin thisbranch

# git push [remoteName] [branchName]:[newRemoteBranchName]
git push -u origin thisbranch:newbranchname

Merging and Pull Requests

  As mentioned above, if there have been changes to the initial repository in the period of time that you've had your branch then you'll need to resolve any merge conflicts. To do this simply pull from the branch that you're trying to merge into and fix any conflicts that arise. Your most recent commit is still there so if you want to outright overwrite a file that's been amended in both the remote and your local repository you can use the same line as above:

• git checkout hash filename

Tidying up the Local Repository

git remote prune origin