#gitbranches

[visioncodekdp]

Pushing your local project to remote repository in GitHub using Command line

Step 1: Check whether git is installed in your system or not.

How to check 🤔. Is this your question answer is simple.

Open command line/terminal ----> git ----> if after entering git of it won't show any error then you can say git is installed in your system.

Step 2: Open your github account and create a new repository in your github .

Top right corner ----> click on + or add ---> Choose new repository ---> give permissions only which are needed ----> Click create

Wohoo! Done creating a new repository in remote.

Step 3: Now our task is to connect our local repository to remote repository (GitHub repository) . Follow the below series of steps

Open cmd line / terminal ----> Go to your local project path ---> git init ---> git remote add origin https://(repo_name)

Note:: repo_name is accessible from your github repository on choosing thr repository which we have created copy and paste here.

Now you have connected your local project to remote github repository project.

Step 4: Connecting our local branch to remote branch

git branch -M main

If you get any errors do not worry that branch is already existed. Go ahead with the next command

Step5: Pushing our local branch to remote branch

git push -u origin main

This doesn't work then try something like

git push --set-upstream origin master

The one good thing about command line in git is it always suggests you the proper command. That's the specialty of git in command line/terminal.

That repo link is mine update with your project repo link😅 dear.

It won't end our task now.

Now we need to commit and push our changes in our project right

First Check the changes in your project

git status

git add .

git commit -m "message"

git push

Wohooo🎉 we have done pushing our project to remote

[initialcommit]

Refresher on how to push, pull, branch, checkout, and merge in Git. Follow @initialcommit for more programming content. Check out our website https://initialcommit.io for programming articles, books, live sessions, and how to create your own code-oriented website. #initialcommit #git #gitpush #gitpull #gitbranch #gitcheckout #gitmerge #push #pull #branch #checkout #merge #python #pythonprogramming #java #javaprogramming #javascript #cprogramming #php #programming #coding #learnprogramming #learncoding #softwaredevelopment https://www.instagram.com/p/CBtB97YgM4e/?igshid=1lq77wuzvr0uq

[codeonedigest]

(via GitHub Commands Tutorial with Example for Beginners | GitHub Commands Cheat Sheet)

Hello friends, a new #video on #git #commands with #example is published on #codeonedigest #youtube channel. Enjoy #programming and #coding with an easy guide to #gitcommands with examples.

  #gitprojecttutorial #gitproject #gitprojectupload #gitprojectsetup #gitprojectvsrepository #gitrepsositorytutorial #gitrepository #gitcommands #gitcommandswithexamples #gitcommandstopushcodetogithub #gitcommandsinterviewquestions #gitcommandsforbeginners #gitcommandsingitbash #gitcommandline #gitclone #gitclonerepository #gitclonecommand #gitcloneandpushtorepo #gitclonelink #gitcloneprojectfromgithub #gitclonerepositorywindows #gitcloneusernamepasswordproblem #gitconfigcommand #gitconfigcommandexample #gitbranch #gitbranchcommands #gitbranchcommand #gitbranchcheckout #gitbranchingstrategy #gitbranchmergeconflict #gitcheckout #gitcheckoutremotebranch #gitcheckoutbranch #gitcheckoutnewbranch #gitcheckouttutorial #gitcheckoutremotebranchtolocal #gitcheckoutfile #gitcheckoutinintellij #gitcheckoutineclipse

[technteacher]

Show HN: ZeroQueue, A low-code queue management system

Show HN: ZeroQueue, A low-code queue management system 2 by gitbranch | from Blogger https://ift.tt/2D9J5Zb

[scriptsouffle]

Simplifying Code Review with Github and Caddy

I've been involved in the Caddy webserver project for a while now and use it as the main webserver for all our internal admin applications.

It is super simple to use, very easy to configure, a breath of fresh air after years of wrestling with apache, ohh and it (makes setting up a https site)[https://caddyserver.com/docs/automatic-https] so (trivial)[https://caddyserver.com/docs/automatic-https] you forget that was even a thing.

It comes with lots of great modules for doing lots of cool stuff such as browsing folders, using markdown, automagic https, fastcgi, proxy etc, but also has a whole host of 3rd party plugins that can be build right into the executable via the build server at caddyserver.com. One of those is a really great plugin called git by Abiola. This plugin will pull your repo from a github (or other) repository and respond to any commit git hooks, to make sure your site is kept up to date with any changes.

I had ignored it for a long time thinking it wouldnt work with private repos on github, but now that Windows git / github integration is better and https rather than ssh is the standard way to push changes to github on windows, it all seems to work brilliantly.

We are only a two man team and recently we started using github private repos to code review pull requests. This is fine for the codereview part but its always a bit of a pain to test out the changes on the branch prior to merging.

This is where caddy and git plugin come along.

update your caddy file with the new branch and restart.

githubbranch.example.com { root c:\\www\\mysite\\gitbranch git { repo https://github.com/tobya/privaterepo hook /webhooks/xxcaddygithook secretpassword branch issue27 } }

Now this will pull down the new branch and we can try it out there and then.

[macronimous]

#GitBranches - An independent line of Development https://t.co/rFZKOuAvm1 #WebDevelopment

#GitBranches - An independent line of Development https://t.co/rFZKOuAvm1 #WebDevelopment

— Macronimous.com (@macronimous) April 21, 2018

from Twitter https://twitter.com/macronimous April 22, 2018 at 04:08AM via IFTTT

[toddway]

Continuous integration for Firebase cloud code

In a previous post I showed how to add type-checking and unit tests to Firebase cloud code (cloud functions and database rules). Those tests are independent from any Firebase environment and independent from each other. We should be able to run them all quickly and consistently in a clean Node.js environment with a single command. We should also be able to chain that command with others so that we can build, test, and deploy each code commit directly into a live Firebase environment.

Here are the steps we want to automate:

Download project source

Download project dependencies

Compile project

Run all tests

Stop if any test fails, otherwise continue

Deploy (cloud functions and database rules) to a Firebase environment

Write a deployment summary to our Firebase environment (Git info, date, test results)

We'll assume we have a machine with Node.js and Git installed. This could be a developer machine or a dedicated continuous integration server (I try to make the execution identical for either if I can). The first three steps are pretty straightforward from the command line:

git clone git@github.com:whatever folder-name npm install tsc

Now that we have a compiled project environment, we can use Typescript/Javascript to handle the rest of our steps. From the command line, node can execute a function from a local file like this:

node -e 'require("./build.js").runAllTests()'

Now let's implement a function to run all our tests:

export async function runAllTests() : Promise<TestResultsEntity> { const Mocha = require('mocha'); const mocha = new Mocha(); mocha.addFile('./test/tests.functions.js'); mocha.addFile('./test/tests.database.js'); const results = new TestResultsEntity(); return await new Promise<TestResultsEntity>((resolve, reject) => { mocha.run() .on('pass', (test) => { results.passed++; }) .on('fail', (test, err) => { results.failed++; }) .on('end', () => { resolve(results) }); }); }

Here I'm use the Mocha API to point to our test files, run them, and keep track of how many pass and fail. Let's write a deploy function that grabs the test results and handles our last three steps:

export async function deploy() { const testResults = await runAllTests(); const gitSummary = await getGitSummary(); const summary = `${testResults.getSummary()} on ${getDateSummary()} from ${gitSummary}`; if (testResults.hasFailures()) { console.log('Deploy failed'); } else { await asyncCommand(`firebase deploy --only functions,database`); await asyncCommand(`firebase database:set /lastDeploy -d '"${summary}"' -y`); console.log('Deploy succeeded'); } console.log(summary); }

In the else clause above we run two Firebase CLI commands. The first command deploys our code to the currently configured Firebase environment. The second command writes a record to the database of that environment with a summary of our deployment. This makes it easy for anyone on the team to see:

what code is deployed,

when it happened,

and the results of the tests.

To pull all of this together into a single command, we'll use the package.json file to set up an npm script:

"scripts": { "deploy": "npm install && tsc && node -e 'require(\"./build.js\").deploy()'" }

Now we can run all steps with these two commands:

git clone git@github.com:whatever folder-name npm run deploy

Finally, here's the ancillary code referenced by the deploy() and runAllTests() functions above:

export async function getGitSummary() : Promise<string> { const gitSha = await asyncCommand("git rev-parse --short HEAD"); const gitBranch = await asyncCommand("git rev-parse --abbrev-ref HEAD"); return Promise.resolve(`${gitSha.trim()}-${gitBranch.trim()}`); } function getDateSummary() : string { return new Date().toLocaleString("en-US", { timeZone: 'America/Chicago' }).trim(); } const exec = require('child_process').exec; function asyncCommand(command : string) : Promise<string> { return new Promise<string>((resolve, reject) => { exec(command, function(error, stdout, stderr){ resolve(stdout); }); }) } export class TestResultsEntity { passed : number = 0; failed : number = 0; getSummary() : string { return `${this.passed}/${this.failed+this.passed} tests passed` } hasFailures() : boolean { return this.failed != 0 } }

[webbygraphic001]

How we use Cake to build .NET Core apps and version assemblies

Let Them Eat Cake!

Apologies for the bad pun. I couldn’t help it. Today, we’re going to talk about CakeBuild, and why Stackify decided to start using it. But first, a little background.

We like to begin with the end in mind at Stackify. As our platform started to unfold into its’ first compiled bits nearly five years ago, it quickly became apparent that we needed some decent structure around how we built and deployed the many layers of our complex stack.

Like most shops, we were in search of an ALM system that could encompass our sprint / work item management, and build services. We wanted something SaaS based as well, and ultimately we landed with the Atlassian JIRA suite. Their CI server, Bamboo, has orchestrated our builds and deploys ever since then.

Doing a build on your build server and workstation should be exactly the same.

Something that has always bothered me about CI tools and servers like this is that they rarely work in the same way as building on your machine. When you hit F5 in Visual Studio, there are a lot of different build options set that we simply don’t think about, that you need to mirror in your MSBUILD task in Bamboo. Then, you have to think about the next steps: where the artifacts go, transforms applied, what you’re doing with the output, etc.

Point is, there have been far too many times where building locally doesn’t have the same result as building on the CI server. And getting the CI server to build and behave the way we want it to is always less than ideal.

This all came to a head a few months ago when we started converting Prefix, our ASP.NET profiler, to .Net Core. I needed our build server to:

Pull the Git repo

Version the assembly

Check in the modified assembly version change

Build it – now with the .Net CLI, and not MSBUILD

Nupack it

Ship to our Myget server

Pull request this release branch back to ‘master’ in our repo

Traditionally, I’d do this with a series of Powershell Script Tasks in Bamboo, but there’s one big pain point: we use AWS Elastic EC2 instances for build agents, and to test even the slightest change you need to create a new image, and spin it up in Bamboo and have it build. It’s extremely time consuming and frustrating.

Enter Cake!

I needed a task runner that would allow anyone on our dev team to execute all of these steps locally in just the same way our build server would, both to validate the process works correctly; and in the event our build server was down or had other issues.

I came across CakeBuild and read the docs. It just made sense. With Cake, you get:

A C# based DSL (no more Powershell or command line scripting!!)

A huge library of built-in scripts for nearly any task you would need.

A system that supports third party scripts

It’s all nuget based. It pulls in everything it needs.

Good support for .Net Core

On paper, it was perfect. So let’s take a look at what it does.

I’m going to skip over the “getting started” steps, and focus on how I’ve accomplished some of the specifics, with a big focus on assembly versioning.

Task: Version Assemblies

But first, a word on our versioning methodology. With .Net Core, you can keep the assembly version in project.json, which makes a lot of sense because it’s easy to manipulate. It’s just a json string.

When we are prepping a new release, we first cut a “release candidate” branch in Git, and it will be named with the target version, i.e:

root/rc/1.2

We will do our testing and once done, cut the actual release branch, i.e.

root/release/1.2

If we have to release a fix for the version, we work on that same branch. That next builds will be 1.2.2, 1.2.3, 1.2.4, etc etc.

For all other builds, the version number will follow the default format in .Net core, i.e:

1.2.0-*, where “*” gets replaced with the branch name + build number, so you’d end up with a 1.2.0-develop-1, or 1.2.2-rc-3, etc. This allows us to push a nuget package and dll that that is testable but never ever will be confused with a release version. If you use any pre-release .Net core packages, this will seem familiar.

So, here is what my Cake task looks like to version. I’ll break it down.

var target = Argument("target", "Default"); var configuration = Argument("configuration", "Release"); var buildVersion = ""; var buildSuffix = ""; var branch = ""; bool bambooRelease = false; Task("Version").Does(() => { branch = (EnvironmentVariable("bamboo_planRepository_branchName") ?? "unknown"); var buildNumber = (EnvironmentVariable("bamboo_buildNumber") ?? "0"); var json = ParseJsonFromFile("project.json") var version = json["version"].ToString();

See that? I check the environment variables (via a built in script) which will give me the branch name if I’m running in Bamboo, otherwise I don’t care, and “Unknown” is substituted (I could still get it with a Git task, but I was lazy and it wasn’t necessary). I then also parse the project.json again with a built in script.

Next, I use another built in script to check to see if we are, in fact, running in Bamboo.

if(Bamboo.IsRunningOnBamboo){ Information("Running on Bamboo"); Information(version); Information(branch); Information(buildNumber); if(branch.Contains("release/")) { bambooRelease = true; Information("Plan is release"); var relVer = branch.Split('/')[1]; var newVer = relVer+ "." + buildNumber + "-*";

Here I am looking for the branch name to support my versioning. If it is release, I know the next part is my Major.Minor. I append on the build number, and serialize the JSON back out to the project.json file.

//only write back if it is a release build json["version"]=newVer; SerializeJsonToFile("project.json",json); } Else{

For non-release, it will generate something like “1.2.0-rc-1” and in my specific case, I don’t need to write it back out to the file.

Information("Plan is not release"); var cleanBranchName = branch.Replace("/","-"); buildSuffix = cleanBranchName+"-"+buildNumber; var newVer = version.Replace("*",cleanBranchName + "-" + buildNumber);; buildVersion = newVer; } } else{ Information("Local Build"); var cleanBranchName = "local"; buildSuffix = cleanBranchName+"-"+buildNumber; var newVer = version.Replace("*",cleanBranchName + "-" + buildNumber);; buildVersion = newVer; } Information(buildVersion); Information(buildSuffix); });

And that’s it. Assembly versioning done easy and flexibly with CakeBuild.

Task: Nuget Package

The next step to build and pack is just as easy. Check it out.

Task("Pack").Does(() => { if(buildSuffix!=""){ DotNetCorePack("project.json", new DotNetCorePackSettings{ Configuration = configuration, VersionSuffix = buildSuffix }); } else{ DotNetCorePack("project.json", new DotNetCorePackSettings{ Configuration = configuration }); } var outputdir = "bin\\"+configuration; CopyFileToDirectory("NugetPack.ps1",outputdir); var wd = DirectoryPath.FromString(outputdir); if(Bamboo.IsRunningOnBamboo) { StartProcess("powershell.exe", new ProcessSettings { Arguments = "-file NugetPack.ps1", WorkingDirectory = wd}); StartProcess("powershell.exe", new ProcessSettings {Arguments = "-file MygetPush.ps1", WorkingDirectory = wd}); } });

The DotNetCorePack script actually builds the project and the nuget package in one step. It runs a build using the .Net CLI, which means that if I’m targeting multiple frameworks, they will all be in the package, so I can reference in projects that target NETStandard, Netcoreapp, and full .Net framework. All in one simple step.

The NugetPack.ps1 file is a script that I actually created and have checked into the project. It simply checks for the existence of a nuget package (and symbols package) and then generates MygetPush.ps1 which is a script that will actually push the package to my private Myget server. It only does this for bamboo builds, which means that if I run this Cake script locally, I’m not going to end up with a bunch of superfluous packages on my build server. You could put all of this logic directly in the Cake script if you wanted to; I already had those scripts from my previous process, so I just left it as it was.

Task: Commit and Push

The last step is to commit and push the change to my project.json file.

Task("CheckinVersion").Does(() => { if(bambooRelease){ var repPath = DirectoryPath.FromString("."); var filePaths = new FilePath[]{".\\project.json"}; GitAdd(repPath, filePaths); GitCommit(repPath,"Bamboo Build Task","bamboo@stackify.com","Bamboo has detected a release build - versioning assembly"); GitPush(repPath); var repositoryDirectoryPath = DirectoryPath.FromString("."); var gitBranch = GitBranchCurrent(repositoryDirectoryPath); var remote = (gitBranch.Remotes[0].PushUrl).Split('/'); var repName = remote[remote.Count()-1]; string json = "{\\\"destination\\\": { \\\"branch\\\":{ \\\"name\\\":\\\"master\\\"}},\\\"source\\\":{\\\"branch\\\": {\\\"name\\\":\\\""+branch+"\\\"}},\\\"title\\\":\\\"Merge Bamboo Build\\\"}"; StartProcess("C:\\curl\\bin\\curl.exe", new ProcessSettings { Arguments = "-v -u [our user name] \"[git repo url]"+repName+"/pullrequests\" -H \"Content-Type: application/json\" -d \" "+ json + "\""}); } } );

Note that I have redacted some details, but again, I use the built-in scripts that Cake provides to commit and check in any file changes on my current branch (which happens to be my modified project.json with the new version number). I then use CURL to post a Pull Request to the api of my Bitbucket repo. The only part of this that was painful was the escape characters needed for the json that gets posted.

Putting the icing on top of the cake.

Sorry. Another bad cake pun. I couldn’t help it.

One thing that you’ve probably noticed in this is that I’m still using Bamboo. And that’s because Cake is simply a DSL for executing tasks. I still need an orchestration engine (like Bamboo) to kick off and execute the cake builds. But, Bamboo is now rather agnostic about the build. I’ve gone from having 10 or so complicated, hard to test Bamboo tasks to two simple tasks:

Pull repo.

Execute build.ps1

I’ve now also achieved a lot of portability. I could very easily migrate to a different CI server with a small level of effort. You’re not limited to .Net Core project either. I love this so much that I went back and implemented this same pattern for my .Net 4.5 class libraries. There are just a couple of differences, for example there are scripts to specifically work with your AssemblyInfo.cs file, i.e:

bambooRelease = true; Information("Plan is release"); var relVer = branch.Split('/')[1]; var newVer = relVer + "." + buildNumber; var newProductVersion = newVer + "-*"; CreateAssemblyInfo(assemblyPath, new AssemblyInfoSettings{ Product = assemblyProduct, Title = assemblyTitle, Company = assemblyCompany, Guid = guid, Version = newVer, FileVersion = newVer, InformationalVersion = newProductVersion, Copyright = "Stackify, LLC " + DateTime.Now.Year });

My methodology is the same for versioning, I just use a different mechanism to do it for these older projects. What I love about this, is that I previously had to do this through a custom MSBUILD task, which required a lot of finesse (and pain and alcohol) to get to work correctly on the build server and not break building locally. It was far too fragile.

If you think this can help make your life easier, check out CakeBuild. Don’t stop with just the build, either. Cake has scripts and add-ins for deployment (IIS, Azure, Docker, etc), for SQL tasks, to work with TFS work items, NUnit, etc. And if it doesn’t support something you need to do, you can simply create it yourself and publish as an add-on.

That really just leaves us with one last, horrible pun. With CakeBuild, you can have your cake and eat it too.

Have you tried cake? Comment below and tell us what you think!

The post How we use Cake to build .NET Core apps and version assemblies appeared first on Stackify.

from Stackify http://ift.tt/2jklb0F from Blogger http://ift.tt/2kmd0ys

[codeonedigest]

GitHub Commands Tutorial with Example for Beginners | GitHub Commands Ch...

 Hello friends, a new #video on #git #commands with #example is published on #codeonedigest #youtube channel. Enjoy #programming and #coding with an easy guide to #gitcommands with examples.

  #gitprojecttutorial #gitproject #gitprojectupload #gitprojectsetup #gitprojectvsrepository #gitrepsositorytutorial #gitrepository #gitcommands #gitcommandswithexamples #gitcommandstopushcodetogithub #gitcommandsinterviewquestions #gitcommandsforbeginners #gitcommandsingitbash #gitcommandline #gitclone #gitclonerepository #gitclonecommand #gitcloneandpushtorepo #gitclonelink #gitcloneprojectfromgithub #gitclonerepositorywindows #gitcloneusernamepasswordproblem #gitconfigcommand #gitconfigcommandexample #gitbranch #gitbranchcommands #gitbranchcommand #gitbranchcheckout #gitbranchingstrategy #gitbranchmergeconflict #gitcheckout #gitcheckoutremotebranch #gitcheckoutbranch #gitcheckoutnewbranch #gitcheckouttutorial #gitcheckoutremotebranchtolocal #gitcheckoutfile #gitcheckoutinintellij #gitcheckoutineclipse